Hi Dino,
since XEID prefix is not seen anywhere on the wire these words
should not be viewed as normative; more like guidance for implementers.
For DDT specification itself it is not important if IID is 24-bit,
32-bit or any other bit length. DDT relies on other control plane
specifications (notably LCAF draft) to specify how IID looks like and
how it is propagated in control messages.
LCAF draft currently depicts 32-bit space to store IID on the figure
but then goes on saying:
> Instance ID: the low-order 24-bits that can go into a LISP data
> header when the I-bit is set. See [RFC6830] for details.
So IMO the ambiguity comes from the LCAF document.
draft-ietf-lisp-lcaf should be more specific on IID length. Furthermore,
if LCAF draft explicitly defined IID to be 32-bits then it should
discuss what to do with excess bits in case of LISP encapsulation.
If DDT draft progresses before LCAF draft then it is more correct to
be compatible with existing RFCs in saying that IID is a 24-bit value.
DDT doc does not look like a proper place to redefine IID length from
24-bit to 32-bits.
If you strongly disagree with above then to unblock DDT spec from
LCAF ambiguity we may remove explicit mention of IID bit length from DDT
spec and put something like "IID as defined by the LCAF draft".
Anton
On 04/25/2016 09:49 PM, Dino Farinacci wrote:
Authors, this change:
Is actually incorrect (change change is from 32 to 24). We have 32-bit
Instance-ID encodings in the LCAF Instance ID Type and want to support
that length in the control-plane EVEN THOUGH the data-plane can only
hold 24-bits.
Meaning, if you use different mapping systems, you can actually reuse
instance-IDs. This reuse was part of our initial intention.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
