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]> 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]> 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]> wrote: >>>>> >>>>> Hi Dino, >>>>> >>>>> >>>>> >>>>>> On 18 Mar 2025, at 22:04, Dino Farinacci <[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] >>>>>> To unsubscribe send an email to [email protected] >> _______________________________________________ >> lisp mailing list -- [email protected] >> To unsubscribe send an email to [email protected] _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
