Yes - since Alvaro is updating 8060bis he can add text. Simply say low order 24 bits of the 32 bit IID is used as the 24 bits IID in the data plane.
Dino
On Mar 26, 2025, at 6:27 AM, Victor Moreno <[email protected]> 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 <[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.
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.
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, 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.
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.
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]
