Hi Victor, I was looking for some text that defines the mapping the other way around. I.e. If I receive a 24-bits value which is not unique how do I much it to a 32-bit value that is unique?
L. > On 26 Mar 2025, at 14:27, Victor Moreno <vimor...@google.com> 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 <g...@gigix.net > <mailto:g...@gigix.net>> 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 >>> <vimoreno=40google....@dmarc.ietf.org <mailto:40google....@dmarc.ietf.org>> >>> 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 <farina...@gmail.com >>> <mailto:farina...@gmail.com>> 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 <j...@joelhalpern.com >>>>> <mailto:j...@joelhalpern.com>> 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 <farina...@gmail.com> <mailto:farina...@gmail.com> >>>>>> Date: Tuesday, March 25, 2025 at 8:19 AM >>>>>> To: Luigi Iannone <g...@gigix.net> <mailto:g...@gigix.net> >>>>>> Cc: LISP mailing list list <lisp@ietf.org> <mailto:lisp@ietf.org> >>>>>> 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 <g...@gigix.net> >>>>>> <mailto:g...@gigix.net> 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 <farina...@gmail.com> >>>>>> <mailto:farina...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> It is documented in RFC8060: >>>>>> >>>>>> <PastedGraphic-1.png> >>>>>> >>>>>> Dino >>>>>> >>>>>> >>>>>> >>>>>> On Mar 24, 2025, at 2:54 PM, Joel Halpern <j...@joelhalpern.com> >>>>>> <mailto:j...@joelhalpern.com> 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 <j...@joelhalpern.com> >>>>>> <mailto:j...@joelhalpern.com> 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 <farina...@gmail.com> >>>>>> <mailto:farina...@gmail.com> 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 <g...@gigix.net> >>>>>> <mailto:g...@gigix.net> wrote: >>>>>> >>>>>> Hi Dino, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 18 Mar 2025, at 22:04, Dino Farinacci<farina...@gmail.com> >>>>>> <mailto:farina...@gmail.com>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 --lisp@ietf.org <mailto:lisp@ietf.org> >>>>>> To unsubscribe send an email tolisp-le...@ietf.org >>>>>> <mailto:lisp-le...@ietf.org> >>>>>> _______________________________________________ >>>>>> lisp mailing list -- lisp@ietf.org <mailto:lisp@ietf.org> >>>>>> To unsubscribe send an email to lisp-le...@ietf.org >>>>>> <mailto:lisp-le...@ietf.org> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> lisp mailing list -- lisp@ietf.org <mailto:lisp@ietf.org> >>>>>> To unsubscribe send an email to lisp-le...@ietf.org >>>>>> <mailto:lisp-le...@ietf.org> >>>> _______________________________________________ >>>> lisp mailing list -- lisp@ietf.org <mailto:lisp@ietf.org> >>>> To unsubscribe send an email to lisp-le...@ietf.org >>>> <mailto:lisp-le...@ietf.org> >>> <PastedGraphic-1.png><PastedGraphic-1.png>_______________________________________________ >>> lisp mailing list -- lisp@ietf.org <mailto:lisp@ietf.org> >>> To unsubscribe send an email to lisp-le...@ietf.org >>> <mailto:lisp-le...@ietf.org> >>
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
