I will try to respond tomorrow. Thanks for your comments Stig. Dino
> On Sep 7, 2016, at 2:14 PM, Joel M. Halpern <[email protected]> wrote: > > Thanks Stig. This looks very useful. > > Authors, can you please respond? > Yours, > Joel > > On 9/7/16 4:41 PM, Stig Venaas wrote: >> 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 >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
