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]> 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=
> [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]> 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]> 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]> <[email protected]>
>> *Date: *Tuesday, March 25, 2025 at 8:19 AM
>> *To: *Luigi Iannone <[email protected]> <[email protected]>
>> *Cc: *LISP mailing list list <[email protected]> <[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]>
>> <[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]>
>> <[email protected]> wrote:
>>
>>
>>
>> It is documented in RFC8060:
>>
>> <PastedGraphic-1.png>
>>
>> Dino
>>
>>
>> On Mar 24, 2025, at 2:54 PM, Joel Halpern <[email protected]>
>> <[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]>
>> <[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]>
>> <[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]>
>> <[email protected]> wrote:
>>
>> Hi Dino,
>>
>>
>>
>>
>> On 18 Mar 2025, at 22:04, Dino Farinacci <[email protected]>
>> <[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]
>>
>> _______________________________________________
>> lisp mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
> <PastedGraphic-1.png><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]
