Last Call Review of draft-ietf-lisp-
review-ietf-lisp-genart-lc-davies-2011-11-30-00
Request | Review of | draft-ietf-lisp |
---|---|---|
Requested revision | No specific revision (document currently at 24) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2011-11-29 | |
Requested | 2011-11-15 | |
Authors | Dino Farinacci , Vince Fuller , David Meyer , Darrel Lewis | |
I-D last updated | 2011-11-30 | |
Completed reviews |
Genart Last Call review of -??
by Elwyn B. Davies
Genart Telechat review of -?? by Elwyn B. Davies |
|
Assignment | Reviewer | Elwyn B. Davies |
State | Completed | |
Request | Last Call review on draft-ietf-lisp by General Area Review Team (Gen-ART) Assigned | |
Completed | 2011-11-30 |
review-ietf-lisp-genart-lc-davies-2011-11-30-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lisp-16.txt Reviewer: Elwyn Davies Review Date: 20111129 IETF LC End Date: 20111130 IESG Telechat date: 20111201 Summary: Almost ready. Given that this document is experimental, there don't appear to be any showstopping issues. However, I found that having the functionality spread over several documents without a really clear overview did not make it easy to follow. There are a number of areas where topics appear unannounced in ways that are not immediately meaningful, and may or may not be clarified later in the document (especially the topics of multicast and anycast). There are areas of the detailed format description that are very dense and difficult to follow, and the split of functionality between this document and ALT does not help. I got the distinct feeling that extra bits of functionality had been shoe horned into this section over time without really thinking through the system aspects. However given that we are considering an experimental protocol this is not a major issue, provided that it is cleaned up before becoming a real standard. Major issues: None Minor issues: s3, EID: "EIDs must not be used as RLOCs": This is confusing.. I assume it does not imply that the same number cannot be used as an EID *and* an RLOC. Maybe it does.. but this needs to be clarified. s3, Data Probe: Some clarification/explanation is needed regarding the fact that a Data Probe uses an EID as its destination address in the core, but EIDs are specifically described as not routable in the core earlier in the document. I understand that ALT puts caveats on the usability of Data Probes, but still potentially offers routability of the EID over the alternative topology. I think some reflection of this discussion would be helpful here. s4.1, item 4: ETR "processes as a control message"... does this imply anything about prioritization in the rest of the network? s5.3, LISP Nonce: What are the consequences of using the same nonce for 'too long'.. and how can an implementor decide what is too long? s6.1: "Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values." I don't understand this. My understanding was that these UDP packets are generated in the ITR with globally routable RLOCs in the headers. Why are they going through NATs? s5.3: Copying of TTL/Hop Count fields and Type of service fields: This discussion is somewhat confusing. Initially these are described as SHOULD mostly without any description of why one would not. A couple of paragraphs later they become MUSTs with some minor and explicit exceptions. This should be clarified. s10.3: How is a "route-returnability check" performed in LISP? s6.1, last para: "This main LISP specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages." So what spec is authoritative for Map-Register and Map-Notify? It is later stated that this spec defines the message format of these messages (first paras of s6.1.6/6.1.7). This seems pretty authoritative. I suspect that this para could be dropped wlog. s6.1.4: S bit: How do I find out how big the Mapping Protocol Data is in order to determine where the extra security fields are located? s6.1.2: A bit: When is it ever set to 1? s6.1.4: M priority/weight: Multicast suddenly makes an appearance. Not sure why? Nits/editorial comments: General: s/bytes/octets/ General: Figures all need titles and numbers. s2, next to last para:xTRs - needs to be expanded and/or given a link to definitions. s3, RLOC: Link to IPv4/v6 specifications needed. s3, EID prefix: "may not use that EID-prefix as a globally prefix". s/prefix/routed prefix/ s3, EID-to-RLOC Database: "This has no negative implications." Justification? s3, Recursive tunneling: "never are they statically configured." s/never are they/they are never/ s3, Reencapsulating tunnels: ditto. s3, Negative Mapping Entry: Needs cross-reference for Negative Map-Reply. s3, Data Probe: needs cross-reference(s) s3, PITR: For the sake of a few extra 'I''s the use of the alternative term PTR seems gratuitous and confusing. I observe that it is not used in the Internetworking draft, where PITR is preferred. s2/s3: Technically the term LISP router is not defined making the term LISP site rather vague. s4, bullet 4: expand CIDR s4.1, item 7: Needs cross references. s5, para 2: "This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4.": srecommends/RECOMMENDS/, s/support/provide support/, s/These two existing/Two possible/ s5.1 and s5.2 Need references to base IP specifications and notes about the items that are defined in those specifications, and the equivalences between source/destination IP addresses and EIDs/RLOCs. (also applies to s6.1) s5.3: This section should also refer to the various abbreviations used in the figures (e.g., OH for Outer Header, etc). ss5.1, 5.2, 5.3: The abbreviation for LISP Locator Status Bits (LSB) needs to be defined. This is maybe slightly unfortunate having a clash with Least Significant Bit. s5.3, LSB: First mention of anycast addresses here. Needs a cross reference or earlier introduction. s5.4.1, last para: s/recommends/RECOMMENDS/ s6.x: Encodings of numeric fields not specified. s6.1.5:"Negative Map-Replies convey special actions by the sender to the ITR or PTR which have solicited the Map-Reply. " s/PTR/PITR/ ?? s9, 1st para after 'figure': "For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal matter as they are today." s/matter/manner/ ----- End forwarded message ----- --