Subject: [lisp] I-D Action: draft-ietf-lisp-ddt-05.txt

From: [email-masked]
Date: Mon, 25 Apr 2016 12:43:36 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol of the IETF.

        Title           : LISP Delegated Database Tree
        Authors         : Vince Fuller
                          Darrel Lewis
                          Vina Ermagan
                          Amit Jain
                          Anton Smirnov
	Filename        : draft-ietf-lisp-ddt-05.txt
	Pages           : 36
	Date            : 2016-04-25

Abstract:
   This draft describes the LISP Delegated Database Tree (LISP-DDT), a
   hierarchical, distributed database which embodies the delegation of
   authority to provide mappings from LISP Endpoint Identifiers (EIDs)
   to Routing Locators (RLOCs).  It is a statically-defined distribution
   of the EID namespace among a set of LISP-speaking servers, called DDT
   nodes.  Each DDT node is configured as "authoritative" for one or
   more EID-prefixes, along with the set of RLOCs for Map Servers or
   "child" DDT nodes to which more-specific EID-prefixes are delegated.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-lisp-ddt-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-ddt-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Apr 2016 12:49:33 -0700

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

> On Apr 25, 2016, at 12:43 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 27 Apr 2016 17:31:17 +0200

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
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 Apr 2016 10:06:01 -0700

>   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:
> 

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

---

From: Anton Smirnov <[email-masked]>
Date: Wed, 27 Apr 2016 22:23:26 +0200

we will consider this input for the next doc revision.

Anton

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 Apr 2016 13:25:45 -0700

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-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Apr 2016 16:36:21 -0400

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 Apr 2016 13:44:15 -0700

On Apr 27, 2016, at 1:36 PM, Joel M. Halpern <[email-masked]> wrote:
> The DDT document completed WG last call some time ago, and was waiting for some final edits, which were I believe just done.

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