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> 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 > To unsubscribe send an email to lisp-le...@ietf.org
_______________________________________________ lisp mailing list -- lisp@ietf.org To unsubscribe send an email to lisp-le...@ietf.org
