The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-24

I have updated my Comment for revision -21 and after further discussions with the authors.

---

Section 2

   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation)

I don't see that RLOCs are any more amenable to aggregation than today's
IP addresses. 

There is nothing factually incorrect in what the text says, but it is implied that RLOCs are somehow special or good. They are no better or worse than pre-LISP IP addresses in respect of aggregation.

If you wanted to fix the Comment, then you might try:

   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore as amenable to aggregation as
   other IP addresses used for routing).

---

Section 3

      When using multiple mapping database
      systems, care must be taken to not create reencapsulation loops.

Would you consider...

...care must be taken to not create reencapsulation loops through
misconfiguration.

---

The architectural overview in Section 4 would be enhanced by a picture.

The example in 4.1 would similarly benefit.

1. I support Pete's COMMENT and Adrian's DISCUSS about the need to make more clear the goals of the experiment, the criteria of success and the limits of deployment while the document stays Experimental. 

2. It would be more clear to split 14.1. into two sub-sections, especially as IANA is required to create a registry for LISP ACT if I understand correctly, while no action is required from IANA for the Flag Fields

3. I support Stewart's DISCUSS. One of the sources of UDP traffic that transmit occasionally may be SNMP agents in the core. When sending unaknowledged notifications (a.k.a. traps) these could be dropped on the floor and then if the cache is flushed they will be lost forever. Altough traps are not supposed to be used in critical applications, systematic loss in what would not be a meltdown situation could badly impact the manageability of the routing environment, 

LISP sounds like a serious protocol experiment. I would have liked there to be more discussion in either the document or in the writeup about how that experiment is going to conclude. That is, though I see the things in section 15 that indicate what it would take to really move this to the standards track, it would be nice to see some discussion about how interoperability is going to be measured as the experiment progresses.

Experiments are good. Although I share Pete's and Adrian's concerns about the scope of the experiment and the parameters for evaluating its success, I agree with Russ that the document is specified clearly enough to be implemented in an experimental fashion (modulo Ralph's question about global uniqueness).

Updated to refer to rev -19

I'd like to see a mention of the complementary observation that
using a single ID-LOC avoids the necessity of a separate step to
bind an identifier to its location and a database to manage those
bindings.  A mention of the scale of the binding database would be
appropriate, too.

As I understand LISP, the EIDs are still ID-LOCs, not pure
identifiers, within a LISP site.  Outside any LISP site, an EID is a
pure identifier.  Which begs the question: exactly what is LISP
providing, since it isn't providing a pure ID/LOC separation.  E.g., a
node can't move within a site without changing its ID, nor can it move
between sites without changing its ID.  Of course, this hybrid ID/LOC
architecture helps with the scaling of the ID/LOC binding database. 

In section 4: first bullet of "basic rules": is it the case that
end-systems are aware of LISP at all?

I would write the first phrase of the third paragraph of section 5 as
"Because EIDs and RLOCs can be either IPv4 or IPv6 addresses, ..."

I don't understand the deployment method described in section 5.5.  I
think I understand the scenario, but I don't understand how RFC 1918
prefixes can be used as EID prefixes.  How is an EID that has an RFC
1918 prefix disambiguated to do the EID-RLOC mapping?  This
question is related to the Discuss issue asking for clarification
of the global uniqueness requirements for EIDs.

In section 6.3, how does an ITR determine the original destination of
an encapsulated datagram that triggers an ICMP Network or Host
Unreachable message, so it can construct a meaningful ICMP Unreachable
message to send to the original source of the datagram?

In section 10.2, I understand how LISP can help avoid site
renumbering, as described in RFC 4192, but I don't understand how it
helps with renumbering a single node that moves
within or between sites.  What is the impact of host renumbering on
LISP forwarding?  What is the citation of RFC 4984 at the end of
section 10.2 in reference to?

I see that Jari has a Discuss waiting for IANA review.  I think
section 14 needs clarification - e.g., while section 14 includes
the text "There are two name spaces in LISP that require registration,"
there appear to be four registries requested in section 14.


How is the statement from the definition of EID-prefix:

   A globally routed
   address block MAY be used by its assignee as an EID block.

compatible from this statement from sections 2 and 4, respectively:

   [...] (EIDs), which are assigned independently from
   the network topology, [...]

   [...] an EID is only routable within the scope of a site.

I think the issue is that some additional caveats are required if "a
globally routed address block [is] used [...] as an EID block";
spec. those addresses from the globally routed address block used as
EIDs must not be allowed to be actually routed directly over the
Internet.  Well, maybe, as we'll need to see how the transition
mechanisms provide interoperability between LISP and
non-LISP systems.

Consider tightening the 3 steps listed in section 5.4.1. Step 2 is really the place you calculated L based on S and H.

  This is going for experimental, and I think it clears the bar for
  experimental.  However, I think Section 6 could be much more clear.

(A) (was discuss #4) 5.4.1 says that reassembly (if needed) happens at the destination
and not the ETR, but then later says that setting DF=1 in the
encapsulated packet avoids "ETR fragment reassembly." Those seem to
be in conflict. -17 has no change and I still think those conflict.

After a bit of back and forth, I now get it. If the spec added the following
to 5.4.1 it would have avoided my confusion but since in the end it has to
work this way this is no longer a discuss point.

The suggested addition is: "Note that reassembly can happen at the
ETR if the packet was fragmented at or after the ITR."

"Tunnel Router".  - should he in the definitions section as a generic type since you say it is a fundamental component.

==========


5.1.  LISP IPv4-in-IPv4 Header Format

SB> It would be helpful to the reader to put a forward ref to
SB> the definition of terms in 5.3 - same in 5.2.

==========


   UDP Checksum:  The UDP checksum field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
      [UDP-TUNNELS].  When a packet with a zero UDP checksum is received

SB> UDP-TUNNELS seems to be a normative reference to an expired
SB> individual draft. That seems to risk this (LISP) document going
SB> into limbo. The following text suggests that the reference 
SB> should be changed to informative anyway.

      .... The handling of UDP
      checksums for all tunneling protocols, including LISP, is under
      active discussion within the IETF.  When that discussion
      concludes, any necessary changes will be made to align LISP with
      the outcome of the broader discussion.

=========

     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SB> I cannot see a definition in this section of the terms 
SB> Source Map-Version and Dest Map-Version

   I: The I bit is the Instance ID bit.  See Section 5.5 for more
      details.  When this bit is set to 1, the Locator Status Bits field
      is reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmitted as zero and ignored on receipt.  The format of the
      LISP header would look like:


     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SB> s/LISP header would look like:/LISP header in this case is:/
SB> More importantly it is slightly confusing putting the 0 case
SB> rider before the format, since at first glance it looks like
SB> the format is only like this when L = 0.



=========

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

SB> Given that you have separated the host domain from the 
SB> ISP domain, I am not sure why this is a SHOULD.

==========

   When doing ETR/PETR decapsulation:

   o  The inner header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the outer header Time to Live
      field, when the Time to Live field of the outer header is less
      than the Time to Live of the inner header.  Failing to perform
      this check can cause the Time to Live of the inner header to
      increment across encapsulation/decapsulation cycle.  This check is
      also performed when doing initial encapsulation when a packet
      comes to an ITR or PITR destined for a LISP site.


SB> What LISP is doing is very similar in many respects to
SB> MPLS does, and MPLS found that it needed both copy TTL and
SB> not copy TTL. I am surprised that you did not follow that model.



========


6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following UDP packet formats are used by the LISP control-plane.

SB> They are not UDP pkt formats, they are UDP/IP packet formats.

========

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

SB> Surely the section *is* the authoritative source?
SB> Are you sure you do not need a registry for this?

=======


9.2.  IPv4 Traceroute

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR. 

SB> This sounds like quite a complicated mechanism. Did the authors
SB> consider having the ITR do proxy traceroute?

In Section 5.3, UDP Checksum discussion, the reference to draft-eubanks-chimento-6man should probably be to draft-ietf-6man-udpzero instead.

In section 5.4.1, what is "an architectural constant"?  Should this just say "a constant"?