> On 29 Apr 2016, at 23:18, Dino Farinacci <farina...@gmail.com> wrote: > > So how about this as a proposal. The DDT doc refers to 32-bits for the > control-plane and RFC 6830 refers to 24-bits in the data-plane and the LCAF > document explains how to map the 32 into 24 and what the benefit is? > > So I’m asking and offering to update the LCAF document to reflect this. Agree? >
Sounds good to me. I just would like to see a ref to LCAF in the DDT document, so that we have a pointer toward were the 32 to 24 bits conversion is described. ciao L. > Dino > >> The change was consequence of the following comment that I made to the >> authors as shepherd: >> >>>> Instance ID: >>>> ———————— >>>> >>>> This document define the IID as a 32 bit field, how does it work with the >>>> 24 bit IID defined in RFC6830? >>>> I would suggest that either you provide discussion on the above point or >>>> you refine the IID as 24 bit. >>> >> >> The main point being: how do we shrink the 32bits IID in the 24bits field of >> the LISP header? >> >> As for the explanation of Dino in this thread, the best thing is to leave 32 >> as value, but I would like to see an explicit explanation on how to go from >> 32bits to 24 bits, referencing the LCAF document. It is just a >> clarification sentence to add. >> >> ciao >> >> L. >> >> >> >> >> >> >> >>> On 27 Apr 2016, at 22:47, jmh.direct <jmh.dir...@joelhalpern.com> wrote: >>> >>> Authors, was there a working group request for, or review of, this change? >>> >>> Yours, >>> Joel >>> >>> >>> >>> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone >>> -------- Original message -------- >>> From: Dino Farinacci <farina...@gmail.com> >>> Date: 4/27/2016 4:44 PM (GMT-05:00) >>> To: "Joel M. Halpern" <j...@joelhalpern.com> >>> Cc: Anton Smirnov <asmir...@cisco.com>, lisp@ietf.org >>> Subject: Re: [lisp] I-D Action: draft-ietf-lisp-ddt-05.txt >>> >>> On Apr 27, 2016, at 1:36 PM, Joel M. Halpern <j...@joelhalpern.com> wrote: >>>> >>>> I am a bit confused. I suspect other working group members are as well. >>>> The DDT document completed WG last call some time ago, and was waiting for >>>> some final edits, which were I believe just done. >>>> The LCAF document has completed last call. >>> >>> Well I lost track of the DDT document status. >>> >>>> Dino, which document are you requesting be modified? What modification >>>> are you asking for? >>> >>> I am requesting a single change (in 2 places, see below). A change back >>> from 24-bits to 32-bits describing the instance-ID. I don’t know why the >>> change was done during this late stage in the draft. To me, that is a huge >>> change. >>> >>>> Or have I got it backwards, and Anton is asking for a modification? As I >>>> said, I got lost. >>> >>> I reviewed the changes in -05 and noticed this: >>> >>> >>> >>> >>> >>> >>> And the change should not have happened since our intention at the very >>> begninning was to have 2**32 VPNs. >>> >>> There was no justification for this change and it happened very late in the >>> process. >>> >>> Dino >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 4/27/16 4:25 PM, Dino Farinacci wrote: >>>>> 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 <asmir...@cisco.com> 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 >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
