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.
Dino, which document are you requesting be modified? What modification
are you asking for?
Or have I got it backwards, and Anton is asking for a modification? As
I said, I got lost.
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 <[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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
