Last Call Review of draft-ietf-lisp-
review-ietf-lisp-genart-lc-davies-2011-11-30-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-lisp-genart-lc-davies-2011-11-30

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 -----


--