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