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]
