[lisp] I-D Action: draft-ietf-lisp-lcaf-18.txt

[internet-drafts]

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 Canonical Address Format (LCAF)
Authors : Dino Farinacci
  Dave Meyer
  Job Snijders
Filename: draft-ietf-lisp-lcaf-18.txt
Pages   : 44
Date: 2016-10-16

Abstract:
   This draft defines a canonical address format encoding used in LISP
   control messages and in the encoding of lookup keys for the LISP
   Mapping Database System.



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

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

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


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/

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-lisp-ddt-08
> Reviewer: Dale R. Worley
> Review Date: 2016-10-09
> IETF LC End Date: 2016-10-17
> IESG Telechat date: 2016-10-27
> 
> Summary: This draft is on the right track but has open issues,
> described in the review.

Thanks for the review Dale. Your comments are outstanding! And your suggestions 
even better.  ;-)

I am not an author but was involved in the LISP-DDT design early on so I would 
like to respond to some of your comments. Where I think text should change, I 
will suggest that to help the authors. To clarify understanding, I will comment 
inline.

One of the authors will make the changes.

> * In regard to XEIDs:  The concept of XEID unifies the treatment of
> DBID, IID, AFI, and EID.  Essentially all of the processing in the
> draft is simplified by expressing processing in terms of XEIDs.  For
> instance, delegation based on DBID, IID, or AF becomes just a special
> case of delegation based on XEID-prefix.  However, it's not clear to
> me whether this concept is followed in the text.  For example:

Yes, you interpreted the defintion of an extended-EID correctly. It is a 
multi-tuple entity that has hierarchy so we can delegate any tuple, as well as 
the tuple itself, downward on the tree.

> In section 3, definition "XEID-prefix" seems to assume that an
> XEID-prefix will always contain a complete DBID, IID, and AFI.

For a lookup yes. For a delegation, it can be any part of it as I explained 
above.

> In section 4.2.1:
> 
>   The root DDT node is the logical "top" of the database hierarchy:
>   DBID=0, IID=0, AFI=0, EID-prefix=0/0.
> 
> But really, the condition of a root node is that it's authoritative
> for the *empty* XEID-prefix.

Well it is authoriative for everything, by default, but a Map-Referral return 
code will tell you exactly what it is authoritative for if configured for 
specficy XEIDs.

> There is also the suggestion here that an AFI of 0 is somehow a
> wildcard match for any AFI value.  That is a special case that can be
> eliminated by considering the entire XEID to be prefixable.

Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), 
it would be the delegation represents all prefixes in all address families.

We should clarify that in the text.

> On the other hand, this text in 7.3.1 suggests that there is a "null
> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
> 
>   the "referral XEID-prefix" is also initialized to the null value
>   since no referral has yet been received.

I think we don’t need to say how its initialized IMO. We should change text 
here.

> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
> those need to be described in a way that doesn't leave loose ends, by
> either describing how they are expected to be used or referring to a
> document that does so.  In this document, a lot of that information is
> bundled into the definitions of "Extended EID (XEID)" and
> "XEID-prefix" in section 3.  It would be best if this information
> appeared in its own paragraphs.

Agree. We should make this change.

> It appears to me that it is expected that DBID will always be zero
> (see definition "XEID-prefix"), but the machinery is defined so that
> other values can be used.

Experience has showed us that running parallel mapping databases will be 
useful. They really don’t need to be numbered or identified because there will 
be distinct roots and xTRs can connect to one or multiple of them.

And right now, we do not have an encoding for a DBID that can be sent in a 
Map-Register or Map-Request. So I am agreeing with you.

> IID is presumably expected to be zero except when VPNs are used.  (see
> definition "Extended EID (XEID)")  
> 
> Note that definition "Extended EID (XEID)" says "optionally extended
> with a non-zero Instance ID".  Read literally, that means that zero
> IIDs aren't included in the XEID, which would be insanity.  The text
> needs to clarify that IID is always present in the XEID, but is
> normally zero.

Well no, not insane, if we required IID for every register and request, then 
the XEID would have the same set of tuples for all lookups. Supplying an IID=0 
is not wrong or bad semantically and just cost 32-bits in message space.

> AFI is taken from http://www.iana.org/numbers.html, but you have to go
> through the link to draft-ietf-lisp-lcaf to discover that; it should
> be stated in this draft.

True. Authors use the reference I put in the latest LCAF draft. That was an 
IESG comment. So we should get it right.

> * For any given delegated prefix, there can be more than one "peer"
> DDT nodes