Re: [Gen-art] Gen-art telechat review - draft-ietf-lisp-19.txt

[Dino Farinacci <[e-mail]>]

> 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 wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-lisp-19.txt
> Reviewer: Elwyn Davies
> Review Date: 20120115
> IETF LC End Date: 20111130
> IESG Telechat date: 20120119
> 
> Summary: This is an updated version of the review I did for Version 16.
> The status is STILL 'almost ready'. I noticed one additional minor issue
> (s3, ITRs). I did not receive any explicit reponses to the comments in
> the previous review although some of the comments have been addressed
> and I have removed those comments. So...
> 
> 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.

This is good to know. Thanks for your comments Elwyn. See responses below. I have a new -20 diff file enclosed to make sure I reflected your comments. Please have a look and comment as soon as you can. Thanks.

> Minor issues:
> s3, Ingress Tunnel Router (ITR): "An ITR is a router which accepts an IP
> packet with a single IP header": Technically this rules out a site
> attached to an ITR using any form of IP tunneling (such as VPNs or IP
> mobility or 6-in-4 tunnels) through the ITR because a tunneled packet
> would already have more than one IP header. In practice, I think the
> qualifying statement in brackets immediately after the quoted statement
> clarifies the situation but this should be rewrittten to avoid
> ambiguity.

Fixed.

> s3, EID: "EIDs MUST NOT be used as RLOCs":  But the remainder of the
> definition goes on to talk about what must/must not happen when they are
> numerically equivalent. This is still somewhat confusing.

When they are numerically equivaldent does not mean they are the same definition. Remember there are two namespaces so 10.1.1.1 in one namespace serves a different purpose than 10.1.1.1 in the other namespace.

I made no change here because we revised this definition dozens of times to make the working group happy. So this definition is rough concensus.

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

I added to the definition that when Data Probes are used, the underlying routing system must advertise EIDs. This is not desirable but there are rare cases, it may be used.

> s4.1, item 4:  ETR "processes as a control message"... does this imply 
> anything about prioritization in the rest of the network?

No different than anything else and doesn't deserve a mention in my opinion.

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

A possible replay attack if a man-in-the-middle can guess a 24-bit or 128-bit nonce.

> 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 (still) 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?
> Does this mean when only one of the ports is 4342? (but the previous
> comments still stands).

An ITR could be behind a NAT. And when it is its "local RLOC" is a private address. When the packet traverses a NAT, the source address will be changed to a global address. The outside world believes the source of the packet is the source RLOC which is globally reachable and advertised in the underlying routing system.

NATs also translate/change the source port of the outer header. So the if a LISP control packet is returning a reply to a request that had 4342 in the destination port, then the source port would be translated and the requester would not know the packet is a LISP control packet. So if the source port of the request is 4342, the replier can return that in the destination port of the reply without a NAT touching the port (while it is touching the other port).

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

We said should because we were being practical. Some implementations cannot copy the TTL and set it statically. We want those implementations to not violate the spec.

We use MUST later for the Type of Service field. When the TOS is copied, then the sub-parts MUST follow what the text says.

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

I will fix this text. Thanks for finding this.

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

This was commented on quite a bit and was used for CONS. Since the commenters won the argument to remove references to CONS, we will remove the Mapping Protocol Data part, which actually is not used by any implementations.

> s6.1.4: M priority/weight:  Multicast suddenly makes an appearance.  Not 
> sure why?

Because we have to encode multicast priorities. And to get a mapping for an ETR to join an ITR, we use a Map-Request/Map-Reply exchange. I will add a reference to LISP-multicast for each reference to M priority and M weight.

> s10.3: How is a "route-returnability check" performed in LISP?

I added another sentence to the defintion of "Route-returnability".

> Nits/editorial comments:
> General: s/bytes/octets/

Changed throughout.

> General: Figures all need titles and numbers.

There are section titles for the figures. There are no figure numbers just like RFC 2460. I don't see the point since there is no text that back references the figures. And I think we wrote the text to sufficiently introduce the figures that are about to come up.

> s3: s/PA addresses are an an address/PA addresses are an address/
> 
> s3, RLOC: Link to IPv4/v6 specifications needed.
> 
> s3, EID-to-RLOC Database: "This has no negative implications." 
> Justification?
> 
> s3, Negative Mapping Entry: Needs cross-reference for Negative Map-Reply.

Changed all the above.

> s3, Data Probe: needs cross-reference(s)

I don't think it does because it is being defined here for the first time.

> s3, PITR: The alternative term PTR is now not used at all and can be
> removed.

Fixed.

> s4.1, item 7: Needs cross references.

Can you be more specific please. Are you asking for a reference for DNS names or for the Map-Reply or for something else?

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

We did this in a later update. We put the references in 5.3 where we describe such fields.

> s5.3: This section should also refer to the various abbreviations used 
> in the figures (e.g., OH for Outer Header, etc).

It is expanded in the "Packet header descriptions:" part.

> s5.3, LSB: First mention of anycast addresses here.  Needs a cross 
> reference or earlier introduction.

I have added a definition for anycast address in the Definition of Terms section.

> s6.x: Encodings of numeric fields not specified.

All fixed. New text enclosed. Please acknowledge. The -20 has not been posted. This is a work in progress -20 waiting Adrian's comments as well.

Dino