Can you make the change so we can try to advance the document to last call?
Dino > On Apr 27, 2016, at 1:23 PM, Anton Smirnov <[email protected]> wrote: > > we will consider this input for the next doc revision. > > Anton > > >> On 04/27/2016 07:06 PM, Dino Farinacci wrote: >> >>> 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
