> 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.
If that is the case, why is the length included in the text then? I disagree though, the length is critically important because it conveys the maximum number of VPNs, per mapping system, that can be supported. > 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. Right, because that is the only way to fit 32-bits into 24. ;-) > 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. No, this is not true. And you might not have the history of DDT. But we put 32-bits in the DDT document and then had the encoding in the LCAF document reflect that. > 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. The LCAF draft just ended last call and is going to IESG. > 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”. You can’t remove it. You have to make it 32-bits otherwise you created an inconsistency that is (1) not needed and (2) for no good reason. I suggest you leave that text alone and keep it at 32-bits. Dino > > 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
