Early Review of draft-ietf-lisp-lcaf-14
review-ietf-lisp-lcaf-14-rtgdir-early-venaas-2016-09-13-00

Request Review of draft-ietf-lisp-lcaf
Requested rev. no specific revision (document currently at 22)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-09-13
Requested 2016-08-24
Other Reviews Genart Last Call review of -15 by Peter Yee (diff)
Genart Last Call review of -17 by Peter Yee (diff)
Secdir Last Call review of -15 by David Mandelberg (diff)
Opsdir Last Call review of -15 by Sarah Banks (diff)
Review State Completed
Reviewer Stig Venaas
Review review-ietf-lisp-lcaf-14-rtgdir-early-venaas-2016-09-13
Posted at https://www.ietf.org/mail-archive/web/rtg-dir/current/msg03117.html
Reviewed rev. 14 (document currently at 22)
Review result Has Issues
Draft last updated 2016-09-13
Review completed: 2016-09-13

Review
review-ietf-lisp-lcaf-14-rtgdir-early-venaas-2016-09-13

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about
the Routing Directorate, please see


http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-lisp-lcaf-14.txt
Reviewer: Stig Venaas
Review Date: 2016-09-07
IETF LC End Date:
Intended Status: Experimental

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

The draft is almost ready but there are several places where the text
is a bit unclear,
and where there could be potential interoperability issues if people
get it wrong. Here
are the issues I found in the order they appear in the document. They
are all mostly
minor issues, but a few of them are just nits.

In section 1 I find this sentence a bit misleading since [AFI] doesn't
talk about the formatting.

   Currently defined AFIs include IPv4 and IPv6 addresses, which are
   formatted according to code-points assigned in [AFI] as follows:

Is the formatting shown here for AFI 1 and 2 defined in another
document? It would be good to have a reference. If it is introduced
in this document, then it should not be in the introduction.

In section 2, first paragraph it says:
   There is an address family currently defined for IPv4 or IPv6
   addresses.

It would be better to say that address families are defined for IPv4
and IPv6 addresses.

In section 3 we have this paragraph:

   The Address Family AFI definitions from [AFI] only allocate code-
   points for the AFI value itself.  The length of the address or entity
   that follows is not defined and is implied based on conventional
   experience.  Where the LISP protocol uses LISP Canonical Addresses
   specifically, the address length definitions will be in this
   specification and take precedent over any other specification.

I'm not sure what conventional experience means. Please try to find a
better way to say it. Regarding the last sentence, what if a you want
to define new LCAF encodings in the future? Is it good to say that this
specification takes precedent over any other?

In section 3 we have this paragraph:

   Length:  this 16-bit field is in units of bytes and covers all of the
      LISP Canonical Address payload, starting and including the byte
      after the Length field.  So any LCAF encoded address will have a
      minimum length of 8 bytes when the Length field is 0.  The 8 bytes
      include the AFI, Flags, Type, Reserved, and Length fields.  When
      the AFI is not next to encoded address in a control message, then
      the encoded address will have a minimum length of 6 bytes when the
      Length field is 0.  The 6 bytes include the Flags, Type, Reserved,
      and Length fields.

Can you phrase this differently? First it says that any LCAF encoded
address has a minimum length of 8, but then it goes on to say how it
sometimes is only 6. I understand what you're trying to say, but there
may be a better way of stating it.

In section 3 it says:

   Rsvd2:  this 8-bit field is reserved for future use and MUST be
      transmitted as 0 and ignored on receipt.

Some of the LCAFs specified in this document are using it though. Hence
you may need to change this text, and maybe not make it reserved.

The last sentence of section 3 is:

   Therefore, when a locator-set has a mix of AFI records and
   LCAF records, all LCAF records will appear after all the AFI records.

This is not necessarily true. Isn't it possible that one at some point
in the future might use other AFI records that have AFI > 16387? IANA
has assigned several values beyond 16387.

In 4.1 it says:
   AFI = x:  x can be any AFI value from [AFI].

Is 16387 always or sometimes allowed? Might be good to clarify that.
This also applies
to all the other LCAF types with similar language.

Section 4.4:

   RTR RLOC Address:  this is an encapsulation address used by an ITR or
      PITR which resides behind a NAT device.  This address is known to
      have state in a NAT device so packets can flow from it to the LISP
      ETR behind the NAT.  There can be one or more NAT Tunnel Router
      (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these
      set of fields.  The number of NTRs encoded is determined by the
      LCAF length field.  When there are no NTRs supplied, the NTR
      fields can be omitted and reflected by the LCAF length field or an
      AFI of 0 can be used to indicate zero NTRs encoded.

It is not quite clear to me if the NTR fields here are the RTR RLOC
addresses. Does no NTR fields mean that there are no RTR RLOC addresses?
If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length
0), and that would have AFI 0?

Section 4.5 first paragraph:

   Multicast group information can be published in the mapping database.
   So a lookup on an group address EID can return a replication list of
   RLOC group addresses or RLOC unicast addresses.

Can you have a mix of group addresses and unicast addresses? It's also
not so clear from the format what source prefixes are. Are the source
prefixes the same as the unicast RLOCs mentioned above? Can you have
both multiple source addresses and then multiple group addresses? Can
they be in arbitrarty order, or all sources followed by all groups?
It seems one will need to inspect the address itself to tell whether it
is a unicast or multicast address. This is probably fine.

Section 4.6
Add description of Rsvd3.

Section 4.7
Add description of Rsvd3 and Rsvd4.

Section 4.10
In this section there are several examples of using the AFI List Type,
but I miss a general definition. It appears that there can be a variable
number of AFIs in the list. Any number > 0? It might be useful to have
a length field associated with each AFI, or is it OK that parsing fails if
an AFI is unknown, so that the address length is not known?

Section 4.10.3
Isn't it unusual to include the 0 termination? Since you know the
length it is not really needed. When parsing one will need to check
the length either way, what should one do it the string accidentally
is not 0-terminated?

Section 4.10.4
I'm assuming that the recursion is more generic than this example?
It might be worth trying to explain the more generic concept and
format, and make sure that this is described as just an example.

Section 4.10.5
This also appears to be just an example.

Section 5.2
   Key Field Num:  the number of fields (minus 1) the key can be broken
      up into.  The width of the fields are fixed length.  So for a key
      size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2
      bytes in length.  Allowing for a reasonable number of 16 field
      separators, valid values range from 0 to 15.

It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates
5 fields?

   Key Wildcard Fields:  describes which fields in the key are not used
      as part of the key lookup.  This wildcard encoding is a bitfield.
      Each bit is a don't-care bit for a corresponding field in the key.
      Bit 0 (the low-order bit) in this bitfield corresponds the first
      field, right-justified in the key, bit 1 the second field, and so
      on.  When a bit is set in the bitfield it is a don't-care bit and

What does right-justified mean? Does it mean that the first field is the
"low order" one? Basically at the end of the message? And the highest
order bit corresponds to the part of the key right after the wilcards?
I think this need to be explained better to ensure interoperability.

   Key:  the variable length key used to do a LISP Database Mapping
      lookup.  The length of the key is the value n (shown above) minus
      3.

Isn't it exactly the value n, since the length is n + 3?

Section 5.4
   Length value n:  length in bytes of fields that follow.
This is a bit confusing. I think 2+n is the length in bytes that follow
the lenght field. While n is the number of bytes after the JSON length.

Section 5.5

It says "AFI = x" twice in the diagram. Based on this and the way it
is described it might seem that the two AFI values must be the same
value x, but they can differ, right? I this applies to several other
messages types as well.

Section 7
It looks like the table in the IANA considerations doesn't include all
the types defined in this document.

I'm happy to discuss my comments if needed, and also review any
updates to this draft.

Stig