That is not enough. L.
> On 26 Mar 2025, at 14:32, Dino Farinacci <[email protected]> wrote: > > Yes - since Alvaro is updating 8060bis he can add text. Simply say low order > 24 bits of the 32 bit IID is used as the 24 bits IID in the data plane. > > Dino > >> On Mar 26, 2025, at 6:27 AM, Victor Moreno <[email protected]> wrote: >> >> >> I pasted below the text currently in section 4.1 of 8060bis. Do you think >> this is sufficient to disambiguate the mapping? >> >> Instance ID: the low-order 24 bits that can go into a LISP data >> header when the I bit is set. See [RFC9300] for details. The >> reason for the length difference is so that the maximum number of >> instances supported per mapping system is 2^32, while conserving >> space in the LISP data header. This comes at the expense of >> limiting the maximum number of instances per xTR to 2^24. If an >> xTR is configured with multiple Instance IDs where the value in >> the high-order 8 bits is the same, then the low-order 24 bits MUST >> be unique. >> >> On Wed, Mar 26, 2025, 12:57 AM Luigi Iannone <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi, >>> >>> If text can be added to 8060bis that explains how the mapping between >>> 24-bit data-plane IID to 32-bit IID in the control plane is done that would >>> be OK. >>> >>> Ciao >>> >>> L. >>> >>>> On 26 Mar 2025, at 05:06, Victor Moreno >>>> <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Sounds like we need text in 8060bis specifying the mapping of the LSB from >>>> the control plane IID to the 24 bits in the data plane. Is that a >>>> reasonable assumption? >>>> >>>> -v >>>> >>>> On Tue, Mar 25, 2025, 5:19 PM Dino Farinacci <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> Agree. And it shouldn’t go in the DDT spec but where the instance-ID >>>>> encoding is defined. That is, the effort for 8060bis. >>>>> >>>>> Dino >>>>> >>>>>> On Mar 25, 2025, at 5:04 PM, Joel Halpern <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> If we want to do that, make sure the draft explains what is going on. >>>>>> >>>>>> Yours, >>>>>> >>>>>> Joel >>>>>> >>>>>> On 3/25/2025 7:42 PM, Marc Portoles Comeras (mportole) wrote: >>>>>>> >>>>>>> >>>>>>> Another argument supporting having the 32bit range is that recent >>>>>>> drafts/RFCs propose use-cases where having IIDs out of the data-plane >>>>>>> range may come handy. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For example, the eid-mobility draft proposes using a separate IID for >>>>>>> ARP/ND resolution, to simplify encoding and avoid overlapping with L2 >>>>>>> and L3 IIDs. >>>>>>> >>>>>>> >>>>>>> >>>>>>> <<There is a dedicated IID used for the registration of >>>>>>> the ARP/ND related mappings>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> In RFC9735 we say that: >>>>>>> >>>>>>> << It is RECOMMENDED that each use case register their >>>>>>> DNs with a unique Instance-ID>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> And I believe there are other examples that I’m forgetting now. >>>>>>> >>>>>>> >>>>>>> >>>>>>> In all these cases, since the IID may not have a direct mapping to the >>>>>>> data-plane encapsulation, it seems unnecessary to spend IIDs within the >>>>>>> 24bit range and we can use higher order 32bit IIDs to support the >>>>>>> segmentation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Marc >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Dino Farinacci <[email protected]> <mailto:[email protected]> >>>>>>> Date: Tuesday, March 25, 2025 at 8:19 AM >>>>>>> To: Luigi Iannone <[email protected]> <mailto:[email protected]> >>>>>>> Cc: LISP mailing list list <[email protected]> <mailto:[email protected]> >>>>>>> Subject: [lisp] Re: IID lengnth >>>>>>> >>>>>>> I cannot find anymore text than what I provided. I can just tell your >>>>>>> intent of the designers. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 25, 2025, at 1:14 AM, Luigi Iannone <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> Dino, >>>>>>> >>>>>>> >>>>>>> >>>>>>> the document that is authoritative on Instance ID is RFC 9300 (which is >>>>>>> standard track), in particular section 8. >>>>>>> >>>>>>> >>>>>>> >>>>>>> <PastedGraphic-1.png> >>>>>>> >>>>>>> >>>>>>> >>>>>>> LISP VPN is an experimental draft and is not authoritative on IIDs, >>>>>>> neither is RFC8060. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I understand your point about “many-to-1”, but can you find text that >>>>>>> states how to do the mapping? >>>>>>> >>>>>>> Otherwise, if that mapping if specified nowhere then interoperability >>>>>>> looks compromised to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This has been pointed out by Ben during his SECDir review 9300: >>>>>>> https://mailarchive.ietf.org/arch/msg/lisp/HTKLlXPr9hse-qxK3TIXGhQji4g/ >>>>>>> >>>>>>> and that is why 9300 only defines 24-bit IID. >>>>>>> >>>>>>> >>>>>>> >>>>>>> IMO opinion we shold align everything to 24-bit. Implementations are no >>>>>>> compromised if the spec state that 32-bit IID usage is deprecated and >>>>>>> even if the IID is store on 32-bit data field only the 24 least >>>>>>> significative bits MUST be used as IID. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ciao >>>>>>> >>>>>>> >>>>>>> >>>>>>> L. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 24 Mar 2025, at 23:01, Dino Farinacci <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is documented in RFC8060: >>>>>>> >>>>>>> <PastedGraphic-1.png> >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 24, 2025, at 2:54 PM, Joel Halpern <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> I can find reference to mapping IIDs to forwarding contexts. Upon >>>>>>> consideration, I see what that is a matter of local configuration. >>>>>>> >>>>>>> But I can't find anything in there that seems to discuss mapping 32 bit >>>>>>> IDs to 24 bit IDs, much less something that specifically says "use the >>>>>>> lower 24 bits". Can you take a look at the draft and tell me what I >>>>>>> missed? (I can well believe I missed something.) >>>>>>> >>>>>>> Yours, >>>>>>> >>>>>>> Joel >>>>>>> >>>>>>> On 3/24/2025 5:45 PM, Dino Farinacci wrote: >>>>>>> >>>>>>> >>>>>>> It should be in draft-ietf-lisp-vpn. I haven't checked recently. >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 24, 2025, at 2:40 PM, Joel Halpern <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> Dino, you seem to have responded to a different question than Luigi >>>>>>> asked. He didn't ask where the conversion was discussed, nor where it >>>>>>> was implemented. He did not ask why you want it this way. He asked >>>>>>> where the spec describes it. That does not require email archeology. >>>>>>> >>>>>>> Yours, >>>>>>> >>>>>>> Joel >>>>>>> >>>>>>> On 3/24/2025 4:35 PM, Dino Farinacci wrote: >>>>>>> >>>>>>> >>>>>>> Dino, >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 24 Mar 2025, at 14:51, Dino Farinacci <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> The low order 24 bits of the 32 bits in the control plane is used in >>>>>>> the data plane. >>>>>>> >>>>>>> Can you point me where the conversion is specified? >>>>>>> >>>>>>> No. It happened multiple times over a 10 year period. I am not going to >>>>>>> take time to look it up. And it doesn't matter, the intent was to do a >>>>>>> many-to-1 mapping between the control-plane IID (32-bits) to the >>>>>>> data-plane IID (24 bits). >>>>>>> >>>>>>> We did this at cisco so we were not limited to 2^^24 VPNs and >>>>>>> potentially have to same size problem VLANs had. So if you build a >>>>>>> collection of xTRs from the mapping system that uses the IID 32-bit >>>>>>> value 0x00000001 and other set that uses the same value the control >>>>>>> plane makes sure that the data-plane doesn't overlap among xTRs. So >>>>>>> each set can use 0x000001 (24-bits) in the data plane. >>>>>>> >>>>>>> >>>>>>> >>>>>>> It’s a feature and implemented. Do not remove this. You break >>>>>>> implementations. >>>>>>> >>>>>>> If you remeber you made the exact same argument for 9300. IETF security >>>>>>> review pointed out the inconsistency of the argument and ended up >>>>>>> defining IID as a 24-bit field. >>>>>>> >>>>>>> You will break implementations. And I am trying to perserve them. I'm >>>>>>> not going to bring this up again. If you do not include a 32-bit IID in >>>>>>> the LISP-DDT draft, I cannot accept and support it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> If I receive a data plane packet with a certain IID value on 24-bits >>>>>>> and I have in my control plane several 32-bit IIDs with the same >>>>>>> 24-bits value there is no way I can reasonably know which 32-bits IID >>>>>>> is the correct one. This can also be a security issue. >>>>>>> >>>>>>> See above. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We can agree that we have different views on this topic. Hoep the group >>>>>>> will help to make a decision ;-) >>>>>>> >>>>>>> Just don't break implementations. Or more to the point, don't make >>>>>>> 8111bis irrelevant. >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>> >>>>>>> >>>>>>> L. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This has been brought up several times before (by you) and I have made >>>>>>> the same comment. >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 24, 2025, at 6:41 AM, Luigi Iannone <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> Hi Dino, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 18 Mar 2025, at 22:04, Dino Farinacci<[email protected]> >>>>>>> <mailto:[email protected]>wrote: >>>>>>> >>>>>>> Regarding what you said here Luigi, creating a 32-bit IID was >>>>>>> intentiional so you can have more than 2^24 VPNs per instance of a >>>>>>> data-plane. That is you can duplicate IIDs if different mapping systems >>>>>>> were used for the same underlay. >>>>>>> >>>>>>> Yes, but RFC 9300 specifies IID as a 24 bits field. There is no >>>>>>> inter-operable description in how to convert a 32-bit field in a 24-bit >>>>>>> and vice versa. Hence we should just stick to 24 bits. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also there was something you said that was incorrect. You said "on the >>>>>>> wire the IID is 24-bits”. >>>>>>> >>>>>>> You are right on this. I did remeber the 8060 type 2 LCAF wrongly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Well when control plane messages are sent on the wire they are 32-bits. >>>>>>> So in data packets its 24 and in control packets its 32. >>>>>>> >>>>>>> Which is an inconsistency and we should fix this now. >>>>>>> >>>>>>> Luigi >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dino >>>>>>> >>>>>>> <PastedGraphic-1.png>_______________________________________________ >>>>>>> lisp mailing list [email protected] <mailto:[email protected]> >>>>>>> To unsubscribe send an email [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list -- [email protected] <mailto:[email protected]> >>>>>>> To unsubscribe send an email to [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lisp mailing list -- [email protected] <mailto:[email protected]> >>>>>>> To unsubscribe send an email to [email protected] >>>>>>> <mailto:[email protected]> >>>>> _______________________________________________ >>>>> lisp mailing list -- [email protected] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[email protected]> >>>> <PastedGraphic-1.png><PastedGraphic-1.png>_______________________________________________ >>>> lisp mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>>
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
