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 -----
--
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
