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

[Ballot comment]
It's been a long haul, but revision -22 addresses all of my remaining Discuss issues. I hope the quality and utility of the document has been improved as a result.

I'll leave in place my outstanding (non-blocking Comments)

---

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

---

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

The example in 4.1 would similarly benefit.

[Ballot comment]
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.

[Ballot comment]
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.

---

Section 5.3

I agree with Wes about the N and V bits.

---

Section 5.3 LISP Nonce

      When the E-bit is clear but the N-bit is
      set, a remote ITR is either echoing a previously requested echo-
      nonce or providing a random nonce.

"is clear/set" in what?
The original message sent, or the new message received?

[Ballot discuss]
Discuss updated for revision -21 and after further discussions with authors.

---

Section 2

  One database design that is being developed
  and prototyped as part of the LISP working group work is [ALT].
  Others that have been described but not implemented include [CONS],
  [EMACS], [RPMD], [NERD].

Is the LISP working group undertaking controlled prototyping?

My point here is that prototyping does not seem to be in the WG charter. Suggestion is to remove "and prototyped"


Similarly, what does it mean to say "have been described but not
implemented"? I guessed "At the time of writing, the authors are unaware
of any implementations of..."

The authors say that what they intended was that the suggestion of the authors is to not implement the others mechanisms, but this is not what is written and doesn't have WG buy-in. In fact, they can't know (for sure) whether the other solutions have been implemented.

Suggest to just strike "but not implemented"

[Ballot comment]
Added, relative to -21, to replace my previous Discuss on -19:

This text is included in the definition of EID:

      An EID used on the public Internet
      must have the same properties as any other IP address used in that
      manner; this means, among other things, that it must be globally
      unique.

It would be good to clarify what it means to be "used on the public
Internet."  My understanding is that an EID is assigned within a LISP
site and does not appear as a destination address in traffic between
RLOCs.  Therefore, it wasn't quite clear to me whether an EID needs to
be globally unique within all IP addresses used throughout the
Internet, or globally unique among other EIDs within LISP sites, or
perhaps some other scoping for global uniqueness.

What are the "other things" that derive those "same properties"?

Elsewhere in the LISP spec, RFC 1918 addresses ae mentioned, which are
clearly not globally unique.  How does the use of RFC 1918 addresses
relate to this stated requirement for gloabl 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.

[Ballot comment]
(cleared all of my DISCUSS points except one below that is converted into a COMMENT)

If both the N bit and V bit MUST NOT be set in the same packet, I believe it's correct to DROP any packets that arrive this way, as they are certainly errors, and definitely should not be forwarded onwards.

[Ballot discuss]
I have updated my Discuss to remove a major point resolved in the
-20 revision. I will return to look at the other points separately.

Thanks to the authors for addressing my concern.

---

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. That is, the allocation scheme for RLOCs could be run such
that RLOCs are aggregatable, but could equally be run such that it is
hard to aggregate.

Maybe the points here are that:
- network attachment points are not (currently) mobile
- network attachment points are defined by the networks they attach to
- network attachment points, by definition, impose an aggregation of
  end points.

A way to solve this, if you wrote what you intended to write, would be a
forward pointer to the section in the document that describes
aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.

---

Section 2

  One database design that is being developed
  and prototyped as part of the LISP working group work is [ALT].
  Others that have been described but not implemented include [CONS],
  [EMACS], [RPMD], [NERD].

Is the LISP working group undertaking controlled prototyping?
Is the intention to state that "there are known protocotype
implementations of [ALT]."

Similarly, what does it mean to say "have been described but not
implemented"? I guess: "At the time of writing, the authors are unaware
of any implementations of..."

---

Section 3

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

What is this "care"?
What about loops caused by transient conditions (or errors) in a single
LISP mapping database?
Shouldn't the payload TTL at least be decremented by one for each
tunnel?

Note that reencapsulation is not the same as nested encapsulation.
You are clear about avoiding the latter (although some form of DPI
may be required to achieve it).

---

Step 7 of Section 4.1 doesn't make it clear what has happened to the
first packet in the flow. I had assumed that it was buffered pending
the Map-Reply, but I now suspect it was discarded as soon as the
Map-Request was constructed. Can you add a clarification.

[Ballot comment]
"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?

[Ballot discuss]
Having re-read the document and having reviewed some of the other LISP documents I am updating my discuss.

The fundamental problem is understanding the LISP as presented in this base specification is that there is an implicit rather than explicit architecture. Understanding the architecture is important in understanding how the experiment is (or is not working) and understanding how to modify/correct/extend the protocol. Either this documents needs an architectural description up front showing how all the components fit together and which precedes the protocol definitions, or an architectural of framework document needs to be published first.

In addition the definitions section really needs be split into a definitions section (with care being taken over the
generic definition of terms vs the unicast specific  definition), and a section describing the protocol
operations associated with those terms.

The document needs to be clearer on what happens when the traffic is a high volume UDP source that only transmits occasionally. Say (but not limited to)  some form of remote IPFIX collector that is occasionally triggered.

My concern is

a) Do we see a large chunk of the flow dropped on the floor until the mapping is learned - the conflict is between DOS attack and degradation of service WRT the "legacy Internet".

b) Do we see a miss ordering of packets during as the system swaps from probe to normal operation

c) Do we see a repeat of this as a result of cache aging.

========

I am also moving the following up to Discuss since it is related
to the need for a clear description of the impact of the cache
vs the existing behavior of the Internet.

5.4.2.  A Stateful Solution to MTU Handling

SB> It looks like there needs to be some discussion about
SB> the state lifetime, and the issue of holding a stale
SB> MTU vs transienting a flow by flushing the cache.

Note that in both cases I am not requesting a change to the protocol,
just a clear explanation of the expected behavior.

[Ballot comment]
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,

[Ballot discuss]
.

Success Criteria
============
Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.

The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.

Experiment Scoping
===============
Joel points out that the DISCUSS item below is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending resolution of Adrian's.

{Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).}

IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.

[Ballot discuss]
Fifth item delete......

Success Criteria
============
Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.

The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.

Experiment Scoping
===============
Joel points out that the DISCUSS item below is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending resolution of Adrian's.

{Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).}

IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.

Traffic Engineering
=============
The LISP protocol appears to lack machinery required to pass traffic engineering information from inside LISP to the global routing system. The problem is illustrated by example, below:

Assume that there are two LISP sites, one in Australia and the other in the United States. The Australian LISP site numbers its resources from one /24 and the American LISP site numbers its resources from another /24.

Assume also that there are two PITRs. One PITR is located in Australia and the other in the United States. Both PITRs need to advertise both /24s to the global Internet. However, the American PITR's advertisement for the American site should be more attractive that the Australian PITRs advertisement for that same site. Likewise, the Australian PITR's advertisement for the Australian site should be more attractive that the American PITRs advertisement for that same site. This could be achieved by varying the BGP AS Path length as it is advertised into the global Internet.

However, it is not clear how the PITR does this? If the PITR also serves as an XTR to both LISP sites, it might evaluate the cost of traversing the tunnel and pad the BGP AS path appropriately. However, it the PITR does not also serve as XTR to both LISP site, some additional protocol mechanism is needed.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
Updated to refer to rev -19

EIDs are defined to be "not routable on the public
Internet."  What are the global uniqueness properties
required for EIDs, both among EIDs and between
EIDs and globally routable IP addresses?  How
are EIDs with the appropriate properties chosen
and coordinated among LISP sites?

[Ballot discuss]
Updated again, adding a fifth point.

Success Criteria
============
Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.

The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.

Experiment Scoping
===============
Joel points out that the DISCUSS item below is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending resolution of Adrian's.

{Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).}

IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.

Traffic Engineering
=============
The LISP protocol appears to lack machinery required to pass traffic engineering information from inside LISP to the global routing system. The problem is illustrated by example, below:

Assume that there are two LISP sites, one in Australia and the other in the United States. The Australian LISP site numbers its resources from one /24 and the American LISP site numbers its resources from another /24.

Assume also that there are two PITRs. One PITR is located in Australia and the other in the United States. Both PITRs need to advertise both /24s to the global Internet. However, the American PITR's advertisement for the American site should be more attractive that the Australian PITRs advertisement for that same site. Likewise, the Australian PITR's advertisement for the Australian site should be more attractive that the American PITRs advertisement for that same site. This could be achieved by varying the BGP AS Path length as it is advertised into the global Internet.

However, it is not clear how the PITR does this? If the PITR also serves as an XTR to both LISP sites, it might evaluate the cost of traversing the tunnel and pad the BGP AS path appropriately. However, it the PITR does not also serve as XTR to both LISP site, some additional protocol mechanism is needed.

Initial Packet Loss
=============
You may want to add a bullet to Section 15 indicating that some applications will not perform well in LISP sites unless the cache-mappings that they require are either statically configured or protected from expiration. One such application is SNMPv2. Others have yet to be identified.

[Ballot discuss]
Updated again, adding a fourth point.

Success Criteria
============
Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.

The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.

Experiment Scoping
===============
Joel points out that the DISCUSS item below is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending resolution of Adrian's.

{Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).}

IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.

Traffic Engineering
=============
The LISP protocol appears to lack machinery required to pass traffic engineering information from inside LISP to the global routing system. The problem is illustrated by example, below:

Assume that there are two LISP sites, one in Australia and the other in the United States. The Australian LISP site numbers its resources from one /24 and the American LISP site numbers its resources from another /24.

Assume also that there are two PITRs. One PITR is located in Australia and the other in the United States. Both PITRs need to advertise both /24s to the global Internet. However, the American PITR's advertisement for the American site should be more attractive that the Australian PITRs advertisement for that same site. Likewise, the Australian PITR's advertisement for the Australian site should be more attractive that the American PITRs advertisement for that same site. This could be achieved by varying the BGP AS Path length as it is advertised into the global Internet.

However, it is not clear how the PITR does this? If the PITR also serves as an XTR to both LISP sites, it might evaluate the cost of traversing the tunnel and pad the BGP AS path appropriately. However, it the PITR does not also serve as XTR to both LISP site, some additional protocol mechanism is needed.

[Ballot discuss]
Joel points out that the second part of my DISCUSS is redundant with Adrian's. So, I will withdraw that part of the DISCUSS pending resolution of Adrian's.

Success Criteria
============
Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.

The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.

Experiment Scoping
===============
Joel points out that the DISCUSS item below is redundant with Adrian's. So, I will withdraw this part of the DISCUSS pending resolution of Adrian's.

{Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).}

IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.

[Ballot comment]
This was a discuss, but on the basis that the lisp WG re-chartering
will address the issue, I'm clearing.

#12, It looks from 6.1.6 like a Map-Register can be replayed. That's
not a good thing. There may be a similar replay
issue with Map-Notify messages.

[Ballot discuss]
The following is an updated DISCUSS

Success Criteria
============
Please be specific about success criteria for this experiment. What outcome must an experimenter observe in order to consider the experiment a success? Clearly, the experimenter must observe no significant decrease in network performance or availability. However, that alone is not enough to motivate the experiment.

The Introduction suggests that the experiment is motivated by a desire to enhance the scaling characteristics of the global Internet. Having completed the experiment, how will you determine whether you have achieved that goal? One possibility is to make some predictions regarding the size of the global routing tables versus the size of the routing tables carried in LISP ALT at various points in the experiment (i.e., when only a few sites participate in LISP, when half of the Internet participates in LISP, when most of the Internet participates in LISP). The experiment could compare projected results to observations.

Experiment Scoping
===============
Please scope the experiment. How many sites or prefixes must be carried by LISP in order to yield meaningful results? Given the remote possibility that LISP machinery may scale to a certain point and then fail dramatically, should the document provide any guidelines regarding experiment participation (e.g., non-mission critical).

IPv4 vs IPv6
=========
Please comment on how LISP will enhance the scaling capabilities of the IPv4 routing system, in which it is impossible to allocate a contiguous address block for EID use.

[Ballot discuss]
I have updated my Discuss to remove the issues resolved in the -19
revision.

---

I'm inclined to agree with Russ that this is well-enough specified for
an experimental status document, but I have some concerns.

---

I don't see any statement of the scope of the experiment or how it will
be judged. Traditionally, experiments are not released into the Internet
but are operated in a controlled way in walled gardens. It appears that
the intention with this experiment is that it should be conducted in the
Internet, and that makes it important to examine the risks and
uncertaintes.

As part of the Discuss resolution on other LISP documents, and in
accordance with the LISP WG charter, we had agreed that this
specification would countain an upfront and clear statement of the
issues and concerns. To remind you, the charter says:

At this time, these proposals are at an early stage. All proposals
(including LISP) have potentially harmful side-effects to Internet
traffic carried by the involved routers, have parts where deployment
incentives may be lacking, and are NOT RECOMMENDED for deployment beyond
experimental situations at this stage. Many of the proposals have
components (such as the identifier to locator mapping system) where it
is not yet known what kind of design alternative is the best one among
many.

and

The LISP WG is NOT chartered to develop the final
or standard solution for solving the routing scalability problem. Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic. In addition, as these issues are understood, the
working group will analyze and document the implications of LISP on
Internet traffic, applications, routers, and security. This analysis
will explain what role LISP can play in scalable routing. The analysis
should also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on

I do not consider that this draft has adhered to the WG charter, and I
consider the active encouragement of "early deployments" to be both
against the spirit and the letter of the charter. If you believe that
the experiment needs to be conducted "in the wild" you need to spend a
bit more text explaining why this is safe and how the experiment is
contained.

I have proposed text on the LISP mailing list to address this part of my Discuss.

---

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. That is, the allocation scheme for RLOCs could be run such
that RLOCs are aggregatable, but could equally be run such that it is
hard to aggregate.

Maybe the points here are that:
- network attachment points are not (currently) mobile
- network attachment points are defined by the networks they attach to
- network attachment points, by definition, impose an aggregation of
  end points.

A way to solve this, if you wrote what you intended to write, would be a
forward pointer to the section in the document that describes
aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.

---

Section 2

  One database design that is being developed
  and prototyped as part of the LISP working group work is [ALT].
  Others that have been described but not implemented include [CONS],
  [EMACS], [RPMD], [NERD].

Is the LISP working group undertaking controlled prototyping?
Is the intention to state that "there are known protocotype
implementations of [ALT]."

Similarly, what does it mean to say "have been described but not
implemented"? I guess: "At the time of writing, the authors are unaware
of any implementations of..."

---

Section 3

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

What is this "care"?
What about loops caused by transient conditions (or errors) in a single
LISP mapping database?
Shouldn't the payload TTL at least be decremented by one for each
tunnel?

Note that reencapsulation is not the same as nested encapsulation.
You are clear about avoiding the latter (although some form of DPI
may be required to achieve it).

---

Step 7 of Section 4.1 doesn't make it clear what has happened to the
first packet in the flow. I had assumed that it was buffered pending
the Map-Reply, but I now suspect it was discarded as soon as the
Map-Request was constructed. Can you add a clarification.

[Ballot comment]
I have updated my Comment to remove those points that you have addressed
in revision -19 (thanks).

---

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

The example in 4.1 would similarly benefit.

---
Section 5.3

I agree with Wes about the N and V bits.

---

Section 5.3 LISP Nonce

      When the E-bit is clear but the N-bit is
      set, a remote ITR is either echoing a previously requested echo-
      nonce or providing a random nonce.

"is clear/set" in what?
The original message sent, or the new message received?

[Ballot discuss]
I have updated my Discuss to remove the issues resolved in the -19
revision.

---

I'm inclined to agree with Russ that this is well-enough specified for
an experimental status document, but I have some concerns.

I don't see any statement of the scope of the experiment or how it will
be judged. Traditionally, experiments are not released into the Internet
but are operated in a controlled way in walled gardens. It appears that
the intention with this experiment is that it should be conducted in the
Internet, and that makes it important to examine te risks and
uncertaintes.

As part of the Discuss resolution on other LISP documents, and in
accordance with the LISP WG charter, we had agreed that this
specification would countain an upfront and clear statement of the
issues and concerns. To remind you, the charter says:

At this time, these proposals are at an early stage. All proposals
(including LISP) have potentially harmful side-effects to Internet
traffic carried by the involved routers, have parts where deployment
incentives may be lacking, and are NOT RECOMMENDED for deployment beyond
experimental situations at this stage. Many of the proposals have
components (such as the identifier to locator mapping system) where it
is not yet known what kind of design alternative is the best one among
many.

and

The LISP WG is NOT chartered to develop the final
or standard solution for solving the routing scalability problem. Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic. In addition, as these issues are understood, the
working group will analyze and document the implications of LISP on
Internet traffic, applications, routers, and security. This analysis
will explain what role LISP can play in scalable routing. The analysis
should also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on

I do not consider that this draft has adhered to the WG charter, and I
consider the active encouragement of "early deployments" to be both
against the spirit and the letter of the charter. If you believe that
the experiment needs to be conducted "in the wild" you need to spend a
bit more text explaining why this is safe and how the experiment is
contained.

---

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. That is, the allocation scheme for RLOCs could be run such
that RLOCs are aggregatable, but could equally be run such that it is
hard to aggregate.

Maybe the points here are that:
- network attachment points are not (currently) mobile
- network attachment points are defined by the networks they attach to
- network attachment points, by definition, impose an aggregation of
  end points.

A way to solve this, if you wrote what you intended to write, would be a
forward pointer to the section in the document that describes
aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.

---

Section 2

  One database design that is being developed
  and prototyped as part of the LISP working group work is [ALT].
  Others that have been described but not implemented include [CONS],
  [EMACS], [RPMD], [NERD].

Is the LISP working group undertaking controlled prototyping?
Is the intention to state that "there are known protocotype
implementations of [ALT]."

Similarly, what does it mean to say "have been described but not
implemented"? I guess: "At the time of writing, the authors are unaware
of any implementations of..."

---

Section 3

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

What is this "care"?
What about loops caused by transient conditions (or errors) in a single
LISP mapping database?
Shouldn't the payload TTL at least be decremented by one for each
tunnel?

Note that reencapsulation is not the same as nested encapsulation.
You are clear about avoiding the latter (although some form of DPI
may be required to achieve it).

---

Step 7 of Section 4.1 doesn't make it clear what has happened to the
first packet in the flow. I had assumed that it was buffered pending
the Map-Reply, but I now suspect it was discarded as soon as the
Map-Request was constructed. Can you add a clarification.

[Ballot discuss]
While this was a lot of discuss points, its now just one which is
really the same as my discuss point on lisp-ms (not yet clear what
fix where might best resolve this).

#12, It looks from 6.1.6 like a Map-Register can be replayed. That's
not a good thing. What prevents/detects such replays which should be
a nice DoS if a site changes its config? Maybe that nonce ought not
be zero and maybe there should be a Map-Server or ETR defined window
during which nonces MUST be kept? (I may need to check [LISP-MS]
again to see what's what there.) There may be a similar replay
issue with Map-Notify messages, not sure. -17 seems to be the same
here so I think there's more to discuss.

[Ballot comment]
(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."

[Ballot discuss]
While this was a lot of discuss points, its now a lot fewer:-)
           
#1 cleared

#2, How does an ITR know or when to use the underlying routing system
or the ALT? Is that just config or packet-by-packet? (4.1 4th
bullet.) -17 still doesn't answer that for me sorry - there are two clear
ways to send a map request but how is one selected?

#3, cleared

#4, cleared, moved this to comment (A) once it was explained to me.

#5, cleared

#6, cleared

#7 cleared. (But as a comment it might be good to more fully explain the actual status
of [CONS] when its first referenced?)

#8, 6.1.3 talks about a destination IP address being a
destination-EID.  That's odd. There's no field in 6.1.2 named that so
you must mean the destination IP address of the UDP packet containing
the Map-Request, but then you're sending a UDP packet to the Internet
with an EID as its destination IP address which I thought was the
main thing LISP wanted to avoid. I don't understand how that works
since it seems to mean that all EIDs MUST be globally routable.
Reading to the next paragraph perhaps you mean that such a request
MUST be LISP encapsulated and sent to a Map-Resovler but then how
would the ITR know which Map-Resolver RLOC to use for the EID in
question? -17 has no change here

#9, Last para of 6.1.3. I think you need to say that an ETR MUST NOT
add such a mapping to its map-cache until after it has been
successfully verified. Its currently a "may" I think. If an
implementation did add the mapping whilst verification was pending,
then sending two Map-Requests with the mapping might work for an
attacker if they can respond sooner than the mapping DB. If the ETR
just added the mapping with no verification then I think the attack
is clear - any ITR (or maybe any host?) can conincve any ETR that its
the place to send stuff for any EID previously unknown to that ETR.
Section 6.2 says that gleaned map-cache entries can be stored for "a
few seconds" so this race may be a real issue. Probably easiest is to
say something in 6.1.3 about such map-cache entries when they're in
the "pending" state. -17 has no change and I think this still needs
discussing.

#10, cleared

#11, cleared

#12, It looks from 6.1.6 like a Map-Register can be replayed. That's
not a good thing. What prevents/detects such replays which should be
a nice DoS if a site changes its config? Maybe that nonce ought not
be zero and maybe there should be a Map-Server or ETR defined window
during which nonces MUST be kept? (I may need to check [LISP-MS]
again to see what's what there.) There may be a similar replay
issue with Map-Notify messages, not sure. -17 seems to be the same
here so I think there's more to discuss.

#13, cleared

[Ballot discuss]
Experimental Status (Was Issue 1)
=================================
In the Introduction, please add text that describes what you expect to learn from the experiment. The following potential discoveries should be discussed:

- Benefits derived from LISP
- LISP operational characteristics

Regarding benefits, you might want to say that you expect to demonstrate a reduction in the size of the global routing table, traffic engineering, multi-homing, etc.

Regarding operational characteristics, you might to say that LISP introduces several new mechanisms (e.g., ITR map-caching) with which we have little operational experience. The experiment will reveal these mechanism's scaling, performance and security characteristics. The experiment will also reveal the degree of effort required to diagnose LISP network problems. This section might want to include a pointer to Section 15.

Experimental Status Redux (Was Issue 2 and 3)
=============================================
When the experiment is performed in an IPv4 network, is it likely to yield the same results as it will in an IPv6 network? When answering this question, recall that a large, contiguous block of IPv6 address space will be allocated for EIDs. In IPv4, such an allocation is not possible.

Mapping Registration (Was Issue 9)
==========================
All ETRs serving a particular prefix must maintain synchronization with each other, at least regarding that prefix. The LISP document suite offers no mechanism for keeping ETRs in sync. Also, if ETRs become out of sync, temporary or persistent packet loss may result.

Given these restrictions, is it reasonable to say that  all ETRs servicing a prefix MUST be under the same configuration authority, so that updates can be coordinated?


Forwarding Plane Encapsulation (Was Issue 7)
============================================
- Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1.

- The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say?

[Ballot discuss]
Experimental Status (Was Issue 1)
=================================
In the Introduction, please add text that describes what you expect to learn from the experiment. The following potential discoveries should be discussed:

- Benefits derived from LISP
- LISP operational characteristics

Regarding benefits, you might want to say that you expect to demonstrate a reduction in the size of the global routing table, traffic engineering, multi-homing, etc.

Regarding operational characteristics, you might to say that LISP introduces several new mechanisms (e.g., ITR map-caching) with which we have little operational experience. The experiment will reveal these mechanism's scaling, performance and security characteristics. The experiment will also reveal the degree of effort required to diagnose LISP network problems. This section might want to include a pointer to Section 15.

Experimental Status Redux (Was Issue 2 and 3)
=============================================
When the experiment is performed in an IPv4 network, is it likely to yield the same results as it will in an IPv6 network? When answering this question, recall that a large, contiguous block of IPv6 address space will be allocated for EIDs. In IPv4, such an allocation is not possible.

Mapping Registration (Was Issue 9)
==========================
All ETRs serving a particular prefix must maintain synchronization with each other, at least regarding that prefix. The LISP document suite offers no mechanism for keeping ETRs in sync. Also, if ETRs become out of sync, temporary or persistent packet loss may result.

Given these restrictions, is it reasonable to say that  all ETRs service a prefix MUST be under the same configuration authority, so that updates can be coordinated?


Forwarding Plane Encapsulation (Was Issue 7)
============================================
- Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1.

- The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say?

[Ballot discuss]
Experimental Status (Was Issue 1)
=================================
In the Introduction, please add text that describes what you expect to learn from the experiment. The following potential discoveries should be discussed:

- Benefits derived from LISP
- LISP operational characteristics

Regarding benefits, you might want to say that you expect to demonstrate a reduction in the size of the global routing table, traffic engineering, multi-homing, etc.

Regarding operational characteristics, you might to say that LISP introduces several new mechanisms (e.g., ITR map-caching) with which we have little operational experience. The experiment will reveal these mechanism's scaling, performance and security characteristics. Then experiment will also reveal the degree of effort required to diagnose LISP network problems. This section might want to include a pointer to Section 15.

Experimental Status Redux (Was Issue 2 and 3)
=============================================
When the experiment is performed in an IPv4 network, is it likely to yield the same results as it will in an IPv6 network? When answering this question, recall that a large, contiguous block of IPv6 address space will be allocated for EIDs. In IPv4, such an allocation is not possible.

Mapping Registration (Was Issue 9)
==========================
All ETRs serving a particular prefix must maintain synchronization with each other, at least regarding that prefix. The LISP document suite offers no mechanism for keeping ETRs in sync. Also, if ETRs become out of sync, temporary or persistent packet loss may result.

Given these restrictions, is it reasonable to say that  all ETRs service a prefix MUST be under the same configuration authority, so that updates can be coordinated?


Forwarding Plane Encapsulation (Was Issue 7)
============================================
- Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1.

- The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say?

[Ballot discuss]
Updated based on -17.  #2 I cleared, but I am still curious about #1.

#1) s5.3: LISP Nonce: Trying to figure out why you'd resend the same nonce.  It seems like you're using it for reachability purposes? Why wouldn't you just use a new value each time?  Are you send the same set of packets multiple times (i.e., retransmitting)?

#2) cleared

[Ballot discuss]
While this was a lot of discuss points, its now a lot fewer:-)
           
#1 cleared

#2, How does an ITR know or when to use the underlying routing system
or the ALT? Is that just config or packet-by-packet? (4.1 4th
bullet.) -17 still doesn't answer that for me sorry - there are two clear
ways to send a map request but how is one selected?

#3, cleared

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

#5, cleared

#6, cleared

#7 cleared. (But as a comment it might be good to more fully explain the actual status
of [CONS] when its first referenced?)

#8, 6.1.3 talks about a destination IP address being a
destination-EID.  That's odd. There's no field in 6.1.2 named that so
you must mean the destination IP address of the UDP packet containing
the Map-Request, but then you're sending a UDP packet to the Internet
with an EID as its destination IP address which I thought was the
main thing LISP wanted to avoid. I don't understand how that works
since it seems to mean that all EIDs MUST be globally routable.
Reading to the next paragraph perhaps you mean that such a request
MUST be LISP encapsulated and sent to a Map-Resovler but then how
would the ITR know which Map-Resolver RLOC to use for the EID in
question? -17 has no change here

#9, Last para of 6.1.3. I think you need to say that an ETR MUST NOT
add such a mapping to its map-cache until after it has been
successfully verified. Its currently a "may" I think. If an
implementation did add the mapping whilst verification was pending,
then sending two Map-Requests with the mapping might work for an
attacker if they can respond sooner than the mapping DB. If the ETR
just added the mapping with no verification then I think the attack
is clear - any ITR (or maybe any host?) can conincve any ETR that its
the place to send stuff for any EID previously unknown to that ETR.
Section 6.2 says that gleaned map-cache entries can be stored for "a
few seconds" so this race may be a real issue. Probably easiest is to
say something in 6.1.3 about such map-cache entries when they're in
the "pending" state. -17 has no change and I think this still needs
discussing.

#10, cleared

#11, cleared

#12, It looks from 6.1.6 like a Map-Register can be replayed. That's
not a good thing. What prevents/detects such replays which should be
a nice DoS if a site changes its config? Maybe that nonce ought not
be zero and maybe there should be a Map-Server or ETR defined window
during which nonces MUST be kept? (I may need to check [LISP-MS]
again to see what's what there.) There may be a similar replay
issue with Map-Notify messages, not sure. -17 seems to be the same
here so I think there's more to discuss.

#13, cleared

[Ballot comment]
- intro: says "non-routable EIDs" - are there no cases where EIDs are
routed? There are - you say they may be used for routing within the
site (subnetting) in the definition of EID in section 3.  Maybe say
"non globally-routable EIDs"?

- intro: "an Internet"? maybe "the Internet"

- intro: maybe s/along administrative boundaries/along administrative
boundaries meaningful to device owners/ the topology also works along
administrative boundaries, just different (ISP) ones.

- intro: "xTRs" used before being defined (end of 2nd last para), you
could just say mapping modules or something generic here I guess.

- section 3, typo, s/a address block/an address block/ in defn of PA
addresses

- s3, EID definition says " An EID is allocated to a host from an
EID-prefix block associated with the site where the host is located."
Doesn't that sound more like a PA address? Maybe s/is located/at
home/ or something would be better? 

- s3, EID defn: "As the architecture is realized," is vague and maybe
a bit misleading, I think you mean "At present," ? (And maybe s/must
refer/ MUST refer/ in that same place?)

- on 2119 language generally, are you assuming upper and lower case
2119 terms are both the same? If so I think its useful to say so.  If
not then there are a bunch of lower case 2119 terms that may need
checking. (E.g. "may be used" in definition of EID-prefix is the next
one I saw. I've no idea how many of those there are.)

- s3, EID prefix defn: The term "smaller EID prefix" is a bit
confusing maybe. I guess smaller here refers to the block size and
not the number of bits in the prefix. Might help to say that just for
clarity.

- s3, EID prefix defn: typo "as a globally prefix"

- s3, Recursive tunneling defn: typo, s/never are they/they are
never/ same in defn of reencapsulating tunnels.

- s3, Route-returnability defn: type, s/limits/this limits/

- s4, 3rd para typo:  s/and strip/and strips/

- 4.1, step2 typo: s/EID destination/destination EID/

- 4.1, step3, is it a good idea to have 2119 language within an
example like this? Probably best to repeat it later in any case.

- 5.3, UDP header: typo s/a ITR/an ITR/

- 5.3, N bit: saying "Both N amd V bits MUST NOT be set..." is a bit
ambiguous, I think you mean "at the same time" but it could be read
to mean something different.

- 5.3, decapsulation TTL handling: I wonder why you said SHOULD copy
for the TTL field - while there is a condition, that could still be
"MUST copy except when " I'd have thought. If there's a reason
(other than ) why you might do something else, it'd be good to
say what that might be. Similar comment for the SHOULD copy on the
ToS/traffic class.

- 6.1.2 - What does the "A" bit actually mean? You don't say. And
when is that set to 1?

- 6.1.2 - IRC descrption, I think s/must/MUST/ in "must be encoded"
would be better.

- 6.1.2 - This reads oddly and could be cleared I think: "Source EID
Address:  This is the EID of the source host which originated the
packet which is invoking this Map-Request." It reads oddly since EIDs
are not supposed to be addresses really. I think it could be clearer
if you say that this is almost always not an EID for an ITR (assuming
that's right).  Maybe just s/is invoking/caused/ would help too.

- 6.1.3 - s/recommended/RECOMMENDED/ when talking about
rate-limiting?  and s/may optionally/MAY/

- 6.1.4- the TTL in 6.1.4 is specified in minutes with 32 bits
available.  That means a max of more than 8000 *years* is possible.
Sheesh! That seems a bit optimistic. A 24 bit value would allow for
45 days which sounds more reasonable. Or, a 32 bit value in seconds
would allow for 132 years which seems more than enough to me.
Basically, this is just oddly done. I'd also argue that better would
be to say that implementations MUST include some control over the max
value here. (No need to say how to manage that, but it'd be good to
make sure it can be managed.) Given that its probably late to
change this, I guess some text recommending implementations do
some sanity checking on this TTL would be good.

- 6.1.4 ACT bits - I think this is saying these MUST be zero'd in
any mapping data accompanying a Map-Request - is that right? If so,
it'd be good to state that and that a receiver of a Map-Request
MUST NOT act on them, e.g. by storing a negative cache entry or
whatever (which might cause some security concerns, hard to tell
though).

- 6.1.5, should 10/8 addresses be used in these examples? Better
to use the specfic example ranges I'd have thought. I think those
are in RFC 5737.

- 6.1.5, some forward reference to things like map-cache
expiration time would be useful here.

- 6.1.5.1, its probably more accurate to say that shared keys
mean that its easier to detect misbehaviour or to hold someone
to account for that, rather than say that its more difficult
to misbehave.

- 6.1.6, details of the P bit's usage "will be provided in a
future version of this draft" has to be wrong at this point.

- 6.1.6, might be good to say that the nonce is ok to be zero
because the message is authenticated.

- 6.1.8, I think it'd be better to say that [MLISP] message
might, in future, be allowed. As-is, one could argue that
[MLISP] needs to be a normative reference.

- 6.3 uses the term CE-based ITRs but doesn't explain it and
its not in section 3, nor is PE.

- 6.2 references [LOC-ID-ARCH] from 2009. Is that still
live? If not, is the reference useful?

- section 12, The I in PKI already means infrastructure.

[Ballot discuss]
While this is a lot of discuss points, most should be easily
resolved especially since this is just going for experimental.

#1 cleared

#2, How does an ITR know or when to use the underlying routing system
or the ALT? Is that just config or packet-by-packet? (4.1 4th
bullet.) -17 still doesn't answer that for me sorry - there are two clear
ways to send a map request but how is one selected?

#3, cleared

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

#5, cleared

#6, Can a bad ITR cheat on an ETR by including Map-Reply Records in a
Map-Request message? I think this is ok in the end, but just want to
check.

#7, [CONS] is needed to understand the Map-Request message format, so
does [CONS] need to be a normative reference? What if an ETR gets a
Map-Request but does not support [CONS]? Does it ignore the extra
bytes in the message or ignore the message? If you said one of those
then [CONS] could be an informative reference, but as-is I need to
read [CONS] to know what to do with those bytes. [CONS] also seems to
be needed to understand how TCP might be handled in 6.1.4 (in the
discussion of the A bit), I'd say maybe just deleting the mention of
[CONS] should be ok there.

#8, 6.1.3 talks about a destination IP address being a
destination-EID.  That's odd. There's no field in 6.1.2 named that so
you must mean the destination IP address of the UDP packet containing
the Map-Request, but then you're sending a UDP packet to the Internet
with an EID as its destination IP address which I thought was the
main thing LISP wanted to avoid. I don't understand how that works
since it seems to mean that all EIDs MUST be globally routable.
Reading to the next paragraph perhaps you mean that such a request
MUST be LISP encapsulated and sent to a Map-Resovler but then how
would the ITR know which Map-Resolver RLOC to use for the EID in
question?

#9, Last para of 6.1.3. I think you need to say that an ETR MUST NOT
add such a mapping to its map-cache until after it has been
successfully verified. Its currently a "may" I think. If an
implementation did add the mapping whilst verification was pending,
then sending two Map-Requests with the mapping might work for an
attacker if they can respond sooner than the mapping DB. If the ETR
just added the mapping with no verification then I think the attack
is clear - any ITR (or maybe any host?) can conincve any ETR that its
the place to send stuff for any EID previously unknown to that ETR.
Section 6.2 says that gleaned map-cache entries can be stored for "a
few seconds" so this race may be a real issue. Probably easiest is to
say something in 6.1.3 about such map-cache entries when they're in
the "pending" state.

#10, 6.1.4 defn of "S" bit: there is no field following the Mapping
Protocol Data field in the diagram at the start of the section. I
realise this may be a change resulting from an earlier comment of
mine about [LISP-SEC] being normative at that point, but I think
you'd be better off just saying that this bit is going to be used for
some security stuff in future and leaving it at that and so deleting
the figure at the top of page 33. (That should be enough to ensure
that no other spec assumed that that bit is like the other reserved
bits, which is all that ought be needed for now I think.) Section
6.1.8 has the same issue.

#11, In the case where a 24-bit nonce is included in the 64 bit nonce
field how are those bits encoded (LSB, MSB?) or if only 24 bits are
provided then are the offsets in the figure at the start of 6.1.4 not
used? Either would be ok but it needs to be stated or different
implementers might do different things.

#12, It looks from 6.1.6 like a Map-Register can be replayed. That's
not a good thing. What prevents/detects such replays which should be
a nice DoS if a site changes its config? Maybe that nonce ought not
be zero and maybe there should be a Map-Server or ETR defined window
during which nonces MUST be kept? (I may need to check [LISP-MS]
again to see what's what there.) There may be a similar replay
issue with Map-Notify messages, not sure.

#13, What does "MUST be verified" mean exactly in 6.6.2? Do you
mean via the mapping DB (I guess so) or something else? Just
checking.

IANA has questions about the IANA actions in this document. IANA
understands that, upon approval of this document, there are four actions
which IANA must complete.

First, IANA will create the "LISP ACT value" registry. New
values in this registry will be added through IETF Review or IESG Approval.

IANA Question: The IANA Considerations section of this document uses
6.1.5 as the reference for the initial values in this registry. IANA
wonders if the suthors meant the definition in the Map-Reply Message
Format section of the document (Section 6.1.4)? If so, the initial
values of this registry will be:

Value Action Description
----- ----- --------------------------------------------------
0 No-Action The map-cache is kept alive and no packet encapsulation
occurs
1 Natively-Forward The packet is not encapsulated or dropped but natively
forwarded
2 Send-Map-Request The packet invokes sending a Map-Request
3 Drop A packet that matches this map-cache entry is dropped.
An ICMP Unreachable message SHOULD be sent.

Second, a new registry called "LISP Address Type Codes" will be created.
LISP Address [LCAF] type codes have a range from 0 to 255. New type
codes are to be allocated consecutively starting at 0. Type Codes 0 -
127 are to be assigned by IETF Review or IESG Approval. Type Codes 128 -
255 are available on a First Come First Served basis.

This registry is initially empty.

IANA Question --> what fields will this registry have when it is populated?

Third, IANA has already completed the registration of a pair of port
numbers in the Service Name and Transport Protocol Port Number Registry.
The allocated port numbers are 4341 and 4342 for LISP data-plane and
control-plane operation, respectively. The references will be updated.

Fourth, the document references a registry called LISP Key ID Numbers.

IANA Question -> Is this to be a new registry with its own set of
registration rules? In the document the following description is provided:

14.4. LISP Key ID Numbers

The following Key ID values are defined by this specification as used in
any packet type that references a Key ID field.

Name Number Defined in
-----------------------------------------------
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC6234]

IANA understands that these four actions are the only ones required to
be completed upon approval of this document.

[Ballot discuss]
Issues 5, 8 have been dropped from the Discuss.

Experimental Status (Was Issue 1)
=================================
Near the top of the document, please add text that describes what you expect to learn from the experiment. IMO, the experiment will answer the following questions:

- What benefits are actually derived from LISP?
- What are the operational characteristics of the implementation?

In the first section, you can talk about routing table reduction, traffic engineering, multihoming and mobility. In the second section, enumerate the unconventional aspects of your draft, such as fib-caching and interaction between the control and data planes, whose behavior is worth observing.

It shouldn't take more than two or three paragraphs to address this aspect of the discuss. The pointer to Section 15 might want to live in these paragraphs, too.

Experimental Status Redux (Was Issue 2 and 3)
=============================================
When the experiment is performed in an IPv4 network, is it likely to yield the same results as it will in an IPv6 network? When answering this question, recall that a large, contiguous block of IPv6 address space will be allocated for EIDs. In IPv4, such an allocation is not possible.

Mapping Registration (Was Issue 9)
==================================
The map-versioning document says, "Indeed, ETRs belonging to the same LISP site must return for a specific EID- prefix the same mapping". This document should mention something about that. Also, it should explain how ETRs are kept in sync and what happens when they get out of sync.


Forwarding Plane Encapsulation (Was Issue 7)
============================================
- Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1.

- The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say?


Please reword the third bullet in Section 15 as follows (Was issue 6 and some new stuff) 
==================================================================
Further experience is needed to determine whether current caching methods are practical or in need of further development.  In particular, the performance, scaling and security characteristics of the map-cache will be discovered as part of this experiment. Performance metrics to be observed are packet reordering associated with the LISP data probe and loss of the first packet in a flow associated with map-caching. The impact of these upon TCP will be observed. See Section 12 for additional thoughts and considerations.

Please add the following bullet to Section 15 (Was Issue 4)
============================================================
In order to maintain security and stability, Internet Protocols typically isolate the control and data planes. Therefore, user activity cannot cause control plane state to be created or destroyed. LISP does not maintain this separation. The degree to which the loss of separation impacts security and stability is a topic for experimental observation.

[Ballot comment]
I'm clearing, trusting the shepherd and responsible AD to ensure that the informative references point to to appropriate places. In particular, please verify that it's possible to obtain [RPMD].

[Ballot comment]
s5: r/It is recommended in IPv4/It is RECOMMENDED in IPv4 ?

s5.3: LISP Nonce: I looked in s6.3.1 for the obligatory reference to RFC4086 and didn't see it.  There's one in 6.1.2 - just add another one in either s5.3 or s6.3.1 to provide the pointer to RFC4086 for the the LISP nonce generation recommendations.

s6.1.3: This seems like this ought to be 2119ed:

r/It is recommended that a Map-Request for the same EID-prefix be sent no more than once per second/It is RECOMMENDED that a Map-Request for the same EID-prefix be sent no more than once per second

s6.1.6: r/and support for HMAC-SHA-256-128 [RFC6234]
      is recommended./and support for HMAC-SHA-256-128 [RFC6234]
      is RECOMMENDED.

[Ballot discuss]
#1) s5.3: LISP Nonce: Trying to figure out why you'd resend the same nonce.  It seems like you're using it for reachability purposes? Why wouldn't you just use a new value each time?  Are you send the same set of packets multiple times (i.e., retransmitting)?

#2) s6.1.2 and s6.1.4: Nonces and Probes. This might be a typo but s6.1.4 (map-reply) includes:

Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
  from the Map-Request is echoed in this Nonce field of the Map-
  Reply.

I see in 6.1.2 you can set the P bit to indicate it's a probe and include the nonce in the request, but it says:

P: This is the probe-bit which indicates that a Map-Request SHOULD be
    treated as a locator reachability probe.  The receiver SHOULD
    respond with a Map-Reply with the probe-bit set, indicating the
    Map-Reply is a locator reachability probe reply, with the nonce
    copied from the Map-Request.  See Section 6.3.2 for more details.

now if we look at the Nonce in 6.1.2 (map-request), it says:

Nonce:  An 8-byte random value created by the sender of the Map-
    Request.  This nonce will be returned in the Map-Reply.  The
    security of the LISP mapping protocol depends critically on the
    strength of the nonce in the Map-Request message.  The nonce
    SHOULD be generated by a properly seeded pseudo-random (or strong
    random) source.  See [RFC4086] for advice on generating security-
    sensitive random data.

so which bits of the 64-bit nonce in the reply do you take to make the 24-bit reply for the probe?  There's a 24-bit nonce but that's in the encapsulation header. Is this just a typo?

[Ballot comment]
- intro: says "non-routable EIDs" - are there no cases where EIDs are
routed? There are - you say they may be used for routing within the
site (subnetting) in the definition of EID in section 3.  Maybe say
"non globally-routable EIDs"?

- intro: "an Internet"? maybe "the Internet"

- intro: maybe s/along administrative boundaries/along administrative
boundaries meaningful to device owners/ the topology also works along
administrative boundaries, just different (ISP) ones.

- intro: "xTRs" used before being defined (end of 2nd last para), you
could just say mapping modules or something generic here I guess.

- section 3, typo, s/a address block/an address block/ in defn of PA
addresses

- s3, EID definition says " An EID is allocated to a host from an
EID-prefix block associated with the site where the host is located."
Doesn't that sound more like a PA address? Maybe s/is located/at
home/ or something would be better? 

- s3, EID defn: "As the architecture is realized," is vague and maybe
a bit misleading, I think you mean "At present," ? (And maybe s/must
refer/ MUST refer/ in that same place?)

- on 2119 language generally, are you assuming upper and lower case
2119 terms are both the same? If so I think its useful to say so.  If
not then there are a bunch of lower case 2119 terms that may need
checking. (E.g. "may be used" in definition of EID-prefix is the next
one I saw. I've no idea how many of those there are.)

- s3, EID prefix defn: The term "smaller EID prefix" is a bit
confusing maybe. I guess smaller here refers to the block size and
not the number of bits in the prefix. Might help to say that just for
clarity.

- s3, EID prefix defn: typo "as a globally prefix"

- s3, Recursive tunneling defn: typo, s/never are they/they are
never/ same in defn of reencapsulating tunnels.

- s3, Route-returnability defn: type, s/limits/this limits/

- s4, 3rd para typo:  s/and strip/and strips/

- 4.1, step2 typo: s/EID destination/destination EID/

- 4.1, step3, is it a good idea to have 2119 language within an
example like this? Probably best to repeat it later in any case.

- 5.3, UDP header: typo s/a ITR/an ITR/

- 5.3, N bit: saying "Both N amd V bits MUST NOT be set..." is a bit
ambiguous, I think you mean "at the same time" but it could be read
to mean something different.

- 5.3, decapsulation TTL handling: I wonder why you said SHOULD copy
for the TTL field - while there is a condition, that could still be
"MUST copy except when " I'd have thought. If there's a reason
(other than ) why you might do something else, it'd be good to
say what that might be. Similar comment for the SHOULD copy on the
ToS/traffic class.

- 6.1.2 - What does the "A" bit actually mean? You don't say. And
when is that set to 1?

- 6.1.2 - IRC descrption, I think s/must/MUST/ in "must be encoded"
would be better.

- 6.1.2 - This reads oddly and could be cleared I think: "Source EID
Address:  This is the EID of the source host which originated the
packet which is invoking this Map-Request." It reads oddly since EIDs
are not supposed to be addresses really. I think it could be clearer
if you say that this is almost always not an EID for an ITR (assuming
that's right).  Maybe just s/is invoking/caused/ would help too.

- 6.1.3 - s/recommended/RECOMMENDED/ when talking about
rate-limiting?  and s/may optionally/MAY/

- 6.1.4- the TTL in 6.1.4 is specified in minutes with 32 bits
available.  That means a max of more than 8000 *years* is possible.
Sheesh! That seems a bit optimistic. A 24 bit value would allow for
45 days which sounds more reasonable. Or, a 32 bit value in seconds
would allow for 132 years which seems more than enough to me.
Basically, this is just oddly done. I'd also argue that better would
be to say that implementations MUST include some control over the max
value here. (No need to say how to manage that, but it'd be good to
make sure it can be managed.) Given that its probably late to
change this, I guess some text recommending implementations do
some sanity checking on this TTL would be good.

- 6.1.4 ACT bits - I think this is saying these MUST be zero'd in
any mapping data accompanying a Map-Request - is that right? If so,
it'd be good to state that and that a receiver of a Map-Request
MUST NOT act on them, e.g. by storing a negative cache entry or
whatever (which might cause some security concerns, hard to tell
though).

- 6.1.5, should 10/8 addresses be used in these examples? Better
to use the specfic example ranges I'd have thought. I think those
are in RFC 5737.

- 6.1.5, some forward reference to things like map-cache
expiration time would be useful here.

- 6.1.5.1, its probably more accurate to say that shared keys
mean that its easier to detect misbehaviour or to hold someone
to account for that, rather than say that its more difficult
to misbehave.

- 6.1.6, details of the P bit's usage "will be provided in a
future version of this draft" has to be wrong at this point.

- 6.1.6, might be good to say that the nonce is ok to be zero
because the message is authenticated.

- 6.1.8, I think it'd be better to say that [MLISP] message
might, in future, be allowed. As-is, one could argue that
[MLISP] needs to be a normative reference.

- 6.3 uses the term CE-based ITRs but doesn't explain it and
its not in section 3, nor is PE.

- 6.2 references [LOC-ID-ARCH] from 2009. Is that still
live? If not, is the reference useful?

- section 12, The I in PKI already means infrastructure.

[Ballot discuss]
While this is a lot of discuss points, most should be easily
resolved especially since this is just going for experimental.

#1 EID-to-RLOC database - the definition in s3 says "The" database,
but there are in principle many. What happens if their security
properties differ? I think this might be one to note in section
15 at least.

#2, How does an ITR know or when to use the underlying routing system
or the ALT? Is that just config or packet-by-packet? (4.1 4th
bullet.)

#3, Is ALT or an equivalent mandatory to implement or use really? If
an ITR has no ALT or equivalent, then how would the Map-Request end
up at the right ETR?

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

#5, Just checking - is there a missing "not" in this sentence from
6.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."

#6, Can a bad ITR cheat on an ETR by including Map-Reply Records in a
Map-Request message? I think this is ok in the end, but just want to
check.

#7, [CONS] is needed to understand the Map-Request message format, so
does [CONS] need to be a normative reference? What if an ETR gets a
Map-Request but does not support [CONS]? Does it ignore the extra
bytes in the message or ignore the message? If you said one of those
then [CONS] could be an informative reference, but as-is I need to
read [CONS] to know what to do with those bytes. [CONS] also seems to
be needed to understand how TCP might be handled in 6.1.4 (in the
discussion of the A bit), I'd say maybe just deleting the mention of
[CONS] should be ok there.

#8, 6.1.3 talks about a destination IP address being a
destination-EID.  That's odd. There's no field in 6.1.2 named that so
you must mean the destination IP address of the UDP packet containing
the Map-Request, but then you're sending a UDP packet to the Internet
with an EID as its destination IP address which I thought was the
main thing LISP wanted to avoid. I don't understand how that works
since it seems to mean that all EIDs MUST be globally routable.
Reading to the next paragraph perhaps you mean that such a request
MUST be LISP encapsulated and sent to a Map-Resovler but then how
would the ITR know which Map-Resolver RLOC to use for the EID in
question?

#9, Last para of 6.1.3. I think you need to say that an ETR MUST NOT
add such a mapping to its map-cache until after it has been
successfully verified. Its currently a "may" I think. If an
implementation did add the mapping whilst verification was pending,
then sending two Map-Requests with the mapping might work for an
attacker if they can respond sooner than the mapping DB. If the ETR
just added the mapping with no verification then I think the attack
is clear - any ITR (or maybe any host?) can conincve any ETR that its
the place to send stuff for any EID previously unknown to that ETR.
Section 6.2 says that gleaned map-cache entries can be stored for "a
few seconds" so this race may be a real issue. Probably easiest is to
say something in 6.1.3 about such map-cache entries when they're in
the "pending" state.

#10, 6.1.4 defn of "S" bit: there is no field following the Mapping
Protocol Data field in the diagram at the start of the section. I
realise this may be a change resulting from an earlier comment of
mine about [LISP-SEC] being normative at that point, but I think
you'd be better off just saying that this bit is going to be used for
some security stuff in future and leaving it at that and so deleting
the figure at the top of page 33. (That should be enough to ensure
that no other spec assumed that that bit is like the other reserved
bits, which is all that ought be needed for now I think.) Section
6.1.8 has the same issue.

#11, In the case where a 24-bit nonce is included in the 64 bit nonce
field how are those bits encoded (LSB, MSB?) or if only 24 bits are
provided then are the offsets in the figure at the start of 6.1.4 not
used? Either would be ok but it needs to be stated or different
implementers might do different things.

#12, It looks from 6.1.6 like a Map-Register can be replayed. That's
not a good thing. What prevents/detects such replays which should be
a nice DoS if a site changes its config? Maybe that nonce ought not
be zero and maybe there should be a Map-Server or ETR defined window
during which nonces MUST be kept? (I may need to check [LISP-MS]
again to see what's what there.) There may be a similar replay
issue with Map-Notify messages, not sure.

#13, What does "MUST be verified" mean exactly in 6.6.2? Do you
mean via the mapping DB (I guess so) or something else? Just
checking.

[Ballot comment]
o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.  The procedure a host uses to send
      IP packets does not change.

SB> Hosts don't assume packets get to LISP routers they assume they get SB> to other hosts - they don't know about LISP routers

==========


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?

[Ballot discuss]
The document needs to be clearer on what happens when the traffic is a high volume UDP source that only transmits occasionally. Say (but not limited to)  some form of remote IPFIX collector that is occasionally triggered.

My concern is

a) Do we see a large chunk of the flow dropped on the floor until the mapping is learned - the conflict is between DOS attack and degradation of service WRT the "legacy Internet".

b) Do we see a miss ordering of packets during as the system swaps from probe to normal operation

c) Do we see a repeat of this as a result of cache aging.

========

I am also moving the following up to Discuss since it is related
to the need for a clear description of the impact of the cache
vs the existing behavior of the Internet.

5.4.2.  A Stateful Solution to MTU Handling

SB> It looks like there needs to be some discussion about
SB> the state lifetime, and the issue of holding a stale
SB> MTU vs transienting a flow by flushing the cache.

Note that in both cases I am not requesting a change to the protocol,
just a clear explanation of the expected behavior.

[Ballot discuss]
Experimental Status
===================
What are the success criteria for this experiment? Is the experiment successful if LISP is deployed at a non-trivial number of sites and nothing breaks? Are achievement of LISP's goals to be included in the success criteria? For example, must the experiment cause a reduction in the size of the global routing tables to be considered a success?

Experimental Scope
==================
Considering the current state of LISP research, should the scope of the LISP experiment be constrained in any way?

For example, would it be reasonable for a large enterprise to make all of its sites LISP sites? What benefits would the enterprise realize? To what risks would it be exposed? Would it be reasonable for that enterprise to share a LISP control plane with another enterprise? Again, what are the risks and benefits? Finally would it be reasonable for a major ISP to adopt LISP? To share a LISP control plane with another ISP?

In answering this question, keep in mind that each of the open issues enumerated in Section 15 translate to operational risk. Operational risk is also introduced by issues that are not mentioned in Section 15. For example, little is known regarding the scaling characteristics of the cache-management system and control plane. Also, site partitioning may lead to more severe consequences than those described in Section 8.5

Routing Table Reduction
=======================
During the transition period, when some sites have not yet deployed LISP, will LISP reduce the size of the global routing table? How? When answering this question, assume that connectivity is required between LISP and non-LISP sites.

Architecture
============
Typically, Internet Protocols maintain a strict separation between the forwarding and control planes. Because of this separation, there is nothing that a user can do on the forwarding plane that would cause control plane state to be created or destroyed. This separation is fundamental to the stability of the Internet.

To the best of my knowledge, the only Internet Protocol that violates this separation is PIM, which for many reasons, is not natively deployed in most large carrier networks. LISP, like PIM, intermixes the control and forwarding planes. Explain why this should not be viewed as a problem?

Terminology
==========
The definition of EID needs clarification. Assume that a IPv4-only host is contained by a LISP site. Assume also that the host requires connectivity to both LISP and non-LISP endpoints. Must that host be represented by two distinct 32-bit strings, an EID and a plain-old IPv4 address? Or can the same 32-bit string be used as both EID and the IPv4 address?

Having answered that question, consider the following two statements:

"host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com.  It does a DNS lookup on host2.xyz.example.com.  An A/AAAA record is returned."

"EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication"

If the answer to the first question is yes, the first statement is problematic. If the answer to the second question is yes the second statement is confusing.


TCP Friendliness
================
In section 4.1 you say, "Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR".

What happens to the initial packet? If it is discarded, how will user experience of TCP connections be impacted?

Forwarding Plane Encapsulation
===============================
- Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1.

- The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say?

EID-to-RLOC UDP Map-Request Message
===================================
You say, "A Map-Request is sent from an ITR when it needs a mapping for an EID wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration.  For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure."

How did the ITR learn a route to this address? What device advertised it? Where will the packet arrive?


Mapping Registration
====================
The map-versioning document says, "Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping". This document should mention something about that. Also, it should explain how ETRs are kept in sync and what happens when they get out of sync.

Interworking
=========
The viability of LISP depends on the success of the Interworking model, which we have not seen yet.

[Ballot discuss]
Experimental Status
===================
What are the success criteria for this experiment? Is the experiment successful if LISP is deployed at a non-trivial number of sites and nothing breaks? Are achievement of LISP's goals to be included in the success criteria? For example, must the experiment cause a reduction in the size of the global routing tables to be considered a success?

Experimental Scope
==================
Considering the current state of LISP research, should the scope of the LISP experiment be constrained in any way?

For example, would it be reasonable for a large enterprise to make all of its sites LISP sites? What benefits would the enterprise realize? To what risks would it be exposed? Would it be reasonable for that enterprise to share a LISP control plane with another enterprise? Again, what are the risks and benefits? Finally would it be reasonable for a major ISP to adopt LISP? To share a LISP control plane with another ISP?

In answering this question, keep in mind that each of the open issues enumerated in Section 15 translate to operational risk. Operational risk is also introduced by issues that are not mentioned in Section 15. For example, little is known regarding the scaling characteristics of the cache-management system and control plane. Also, site partitioning may lead to more severe consequences than those described in Section 8.5

Routing Table Reduction
=======================
During the transition period, when some sites have not yet deployed LISP, will LISP reduce the size of the global routing table? How? When answering this question, assume that connectivity is required between LISP and non-LISP sites.

Architecture
============
Typically, Internet Protocols maintain a strict separation between the forwarding and control planes. Because of this separation, there is nothing that a user can do on the forwarding plane that would cause control plane state to be created or destroyed. This separation is fundamental to the stability of the Internet.

To the best of my knowledge, the only Internet Protocol that violates this separation is PIM, which for many reasons, is not natively deployed in most large carrier networks. LISP, like PIM, intermixes the control and forwarding planes. Explain why this should not be viewed as a problem?

Terminology
==========
The definition of EID needs clarification. Assume that a IPv4-only host is contained by a LISP site. Assume also that the host requires connectivity to both LISP and non-LISP endpoints. Must that host be represented by two distinct 32-bit strings, an EID and a plain-old IPv4 address? Or can the same 32-bit string be used as both EID and the IPv4 address?

Having answered that question, consider the following two statements:

"host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com.  It does a DNS lookup on host2.xyz.example.com.  An A/AAAA record is returned."

"EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication"

If the answer to the first question is yes, the first statement is problematic. If the answer to the second question is yes the second statement is confusing.


TCP Friendliness
================
In section 4.1 you say, "Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR".

What happens to the initial packet? If it is discarded, how will user experience of TCP connections be impacted?

Forwarding Plane Encapsulation
===============================
- Regarding the outer header, you say, "The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used." You contradict this statement in the last paragraph of Section 5.4.1.

- The diagram associated with the I flag suggests that the LSB bits will be set even if the I flag is set to 1 and the L flag is set to 0. Is that what you meant to say?

EID-to-RLOC UDP Map-Request Message
===================================
You say, "A Map-Request is sent from an ITR when it needs a mapping for an EID wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration.  For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure."

How did the ITR learn a route to this address? What device advertised it? Where will the packet arrive?


Mapping Registration
====================
The map-versioning document says, "Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping". This document should mention something about that. Also, it should explain how ETRs are kept in sync and what happens when they get out of sync.

[Ballot comment]
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).

[Ballot comment]
My apologies for the changes to the Comments.  Reading
draft-ietf-lisp-alt raised a couple of new questions about
this doc.

I'll take this opportunity to get on a soapbox for a moment and ask
for two bits of "truth in advertising" in the Introduction.

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

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

OK, I'm back down off my soapbox.  I feel better now.

Continuing...

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?

How is the numbering of RLOCs described in section 6.3, which maps
RLOCs to bit positions in the Locator Status Bits field, determined?
How is the numbering affected by RLOCs leaving and joining the set of
RLOCs at a LISP site?

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?

Typo in section 6.5: s/will be yield/will yield/

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?

For clarity in section 14.1, is this document asking IANA to
create and maintain a registry of ACT values?  Related
typo: s/6.1.5/6.1.4/

[Ballot comment]
I made a minor, non-substantive edit to these Comments
on 11/30.

I'll take this opportunity to get on a soapbox for a moment and ask
for two bits of "truth in advertising" in the Introduction.

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

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

OK, I'm back down off my soapbox.  I feel better now.

Continuing...

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?

How is the numbering of RLOCs described in section 6.3, which maps
RLOCs to bit positions in the Locator Status Bits field, determined?
How is the numbering affected by RLOCs leaving and joining the set of
RLOCs at a LISP site?

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?

Typo in section 6.5: s/will be yield/will yield/

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?

[Ballot discuss]
I added this Discuss and changed my position to
Discuss on 11/30.

In reading draft-ietf-lisp-alt, I discovered I have a
technical question about draft-ietf-lisp that needs
to be answered before it can be correctly deployed.

EIDs are defined to be "not routable on the public
Internet."  What are the global uniqueness properties
required for EIDs, both among EIDs and between
EIDs and globally routable IP addresses?  How
are EIDs with the appropriate properties chosen
and coordinated among LISP sites?

[Ballot comment]
o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.  The procedure a host uses to send
      IP packets does not change.

SB> Hosts don't assume packets get to LISP routers they assume they get SB> to other hosts - they don't know about LISP routers

==========


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.

========



5.4.2.  A Stateful Solution to MTU Handling

SB> It looks like there needs to be some discussion about
SB> the state lifetime, and the issue of holding a stale
SB> MTU vs transienting a flow by flushing the cache.

========


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?

[Ballot comment]
o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.  The procedure a host uses to send
      IP packets does not change.

SB> Hosts don't assume packets get to LISP routers they assume they get SB> to other hosts - they don't know about LISP routers

==========


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.

========



5.4.2.  A Stateful Solution to MTU Handling

SB> It looks like there needs to be some discussion about
SB> the state lifetime, and the issue of holding a stale
SB> MTU vs transienting a flow by flushing the cache.

========


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?

[Ballot comment]
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

[Ballot comment]
1. I support Pete and Adrian's DISCUSSes 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. intp 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

[Ballot comment]
Abstract

What is a "network-based protocol"?

---

Please expand acronyms on first use. For example, xTRs.

---                                       

Please decide "an EID" or "a EID" and apply consistently.

---

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

The example in 4.1 would similarly benefit.

---

Section 5

  It is recommended in IPv4 that packets do not get
  fragmented as they are encapsulated by the ITR.  Instead, the packet
  is dropped and an ICMP Too Big message is returned to the source.

Is that REOMMENDED?

---
Section 5.3

I agree with Wes about the N and V bits.

---

Section 5.3 LISP Nonce

      When the E-bit is clear but the N-bit is
      set, a remote ITR is either echoing a previously requested echo-
      nonce or providing a random nonce.

"is clear/set" in what?
The original message sent, or the new message received?

---

Section 5.3 LISP Locator Status Bits

Please say "(LSB)" in the text to match the figure.

[Ballot discuss]
I'm inclined to agree with Russ that this is well-enough specified for
an experimental status document, but I have some concerns.

I don't see any statement of the scope of the experiment or how it will
be judged. Traditionally, experiments are not released into the Internet
but are operated in a controlled way in walled gardens. It appears that
the intention with this experiment is that it should be conducted in the
Internet, and that makes it important to examine te risks and
uncertaintes.

As part of the Discuss resolution on other LISP documents, and in
accordance with the LISP WG charter, we had agreed that this
specification would countain an upfront and clear statement of the
issues and concerns. To remind you, the charter says:

At this time, these proposals are at an early stage. All proposals
(including LISP) have potentially harmful side-effects to Internet
traffic carried by the involved routers, have parts where deployment
incentives may be lacking, and are NOT RECOMMENDED for deployment beyond
experimental situations at this stage. Many of the proposals have
components (such as the identifier to locator mapping system) where it
is not yet known what kind of design alternative is the best one among
many.

and

The LISP WG is NOT chartered to develop the final
or standard solution for solving the routing scalability problem. Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic. In addition, as these issues are understood, the
working group will analyze and document the implications of LISP on 
Internet traffic, applications, routers, and security. This analysis
will explain what role LISP can play in scalable routing. The analysis
should also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on

I do not consider that this draft has adhered to the WG charter, and I
consider the active encouragement of "early deployments" to be both
against the spirit and the letter of the charter. If you believe that
the experiment needs to be conducted "in the wild" you need to spend a
bit more text explaining why this is safe and how the experiment is
contained.

---

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. That is, the allocation scheme for RLOCs could be run such
that RLOCs are aggregatable, but could equally be run such that it is
hard to aggregate.

Maybe the points here are that:
- network attachment points are not (currently) mobile
- network attachment points are defined by the networks they attach to
- network attachment points, by definition, impose an aggregation of
  end points.

A way to solve this, if you wrote what you intended to write, would be a
forward pointer to the section in the document that describes
aggregation of RLOCs. Otherwise, perhaps just drop the parentheses.

---

Section 2

  One database design that is being developed
  and prototyped as part of the LISP working group work is [ALT].
  Others that have been described but not implemented include [CONS],
  [EMACS], [RPMD], [NERD].

Is the LISP working group undertaking controlled prototyping?
Is the intention to state that "there are known protocotype
implementations of [ALT]."

Similarly, what does it mean to say "have been described but not
implemented"? I guess: "At the time of writing, the authors are unaware
of any implementations of..."

---

Section 3

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

What is this "care"?
What about loops caused by transient conditions (or errors) in a single
LISP mapping database?
Shouldn't the payload TTL at least be decremented by one for each
tunnel?

Note that reencapsulation is not the same as nested encapsulation.
You are clear about avoiding the latter (although some form of DPI
may be required to achieve it).
                                                             
---


Step 7 of Section 4.1 doesn't make it clear what has happened to the
first packet in the flow. I had assumed that it was buffered pending
the Map-Reply, but I now suspect it was discarded as soon as the
Map-Request was constructed. Can you add a clarification.

---


Section 5

  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.

This recommendation is presumably upper case, but should be made clear
in the pre-amble to section 5.4.

---


Section 5.3

  E: The E bit is the echo-nonce-request bit.  When this bit is set to
      1, the N bit MUST be 1.  This bit SHOULD be ignored and has no
      meaning when the N bit is set to 0.  See Section 6.3.1 for
      details.

Confused. I think you need:

  E: The E bit is the echo-nonce-request bit.  This bit MUST be ignored
      and has no meaning when the N bit is set to 0.  When the N bit is
      set to 1 and this bit is set to 1, this means blah.  See Section
      6.3.1 for details.

[Ballot comment]
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"?

[Ballot discuss]
If both the N bit and V bit MUST NOT be set in the same packet, then why would there be any rule defined for processing such a packet rather than to DROP it?  It seems wrong to pretent that's okay and just treat it as if the V bit wasn't set.  What is the advantage of this, and is there any risk?

Section 5.4.1 is not clearly written, and seems fairly critical to proper performance.  For instance, what does it mean when it says S is the maximum size of a packet that an ITR "would like to receive"?  Is it the maximum that it *can* receive, the maximum that it can send on a next hop without fragmenting, etc.?  From the description in the 2nd paragraph, the size would only be S/2 + H if the incoming packet were size S, in which case after adding H, it would be size L, NOT greater than L as the first sentence says.  The definitions here really need to be tightened up and clarified.

I believe the stateful solution in 5.4.2 is preferable to the stateless one which seems like it could have very bad effects if it really sets DF=1 and isn't keeping any state about whether smaller fragments need to be sent for a particular destination.  The 5.4.1 algorithm doesn't solve this at all, and seems inadequate for providing a robust infrastructure.

RLOC probing has an impact on the network capacity in-use and there is no way to sense when the overall rate of probing may simply be too great for some bottleneck to handle (due to some combination of the number of RLOCs being probed or the rate of probing).  Losses can occur either of the probes or the map-replies.  Even in cases where it isn't a significant source of congestion, the probing has to be implemented to avoid having bad things happen like accidentally causing synchronization of sending the probes such that this control traffic spikes periodically.  Overall, unless the RLOC probing is better specified so that the risks and necessary precautions are well understood, this seems like a feature that could cause unexpected impact to data flows under some conditions.

[Ballot comment]
I'll take this opportunity to get on a soapbox for a moment and ask
for two bits of "truth in advertising" in the Introduction.

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

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

OK, I'm back down off my soapbox.  I feel better now.

Continuing...

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?

How is the numbering of RLOCs described in section 6.3, which maps
RLOCs to bit positions in the Locator Status Bits field, determined?
How is the numbering affected by RLOCs leaving and joining the set of
RLOCs at a LISP site?

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?

Typo in section 6.5: s/will be yield/will yield/

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 (why "endpoint"?) that moves
within or between sites.  What is the impact of host renumbering on
LISP forwarding?

[Ballot comment]
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.

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

[Ballot discuss]
This document is almost ready for publication as Experimental, but I would like to ask about the status of some of the Informative references before approving it.

[CHIAPPA] points to a personal webserver (that redirects to a university server) - what's the expected stability of that reference.

Where can I find the document pointed to by [RPMD]?

[CONS] appears to be abandoned (the last update was in 2008) - are there plans to advance it?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Locator/ID Separation Protocol (LISP)) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'Locator/ID Separation Protocol (LISP)'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft describes a network-based protocol that enables separation
  of IP addresses into two new numbering spaces: Endpoint Identifiers
  (EIDs) and Routing Locators (RLOCs).  No changes are required to
  either host protocol stacks or to the "core" of the Internet
  infrastructure.  LISP can be incrementally deployed, without a "flag
  day", and offers traffic engineering, multi-homing, and mobility
  benefits to early adopters, even when there are relatively few LISP-
  capable sites.

  Design and development of LISP was largely motivated by the problem
  statement produced by the October 2006 IAB Routing and Addressing
  Workshop.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp/


No IPR declarations have been submitted directly on this I-D.

I have now completed my review.

In general, I'm quite happy with the document. There were of course a number of issues, even some technical ones such as explaining the areas where experimentation is needed in Section 1, expanding the security considerations section, when you do return routability checks, pointing to normal ECN functionality, advice for ICMP treatment, the scope of the mobility section, better acknowledgment of cache management difficulties in the router performance section, contents of the IANA section, normative/non-normative reference split, and so on. But on the whole I did not see any showstoppers. We should be able to make the modifications quickly and last call the document. I can see that Dino has already done a lot of that; thanks. In some cases further discussion is needed. I will respond on the mail thread on each specific mail.

One additional follow-up on my own earlier note:

>> An ITR that is configured with mapping database information (i.e. it
>> is also an ETR) may optionally include those mappings in a Map-
>> Request.  When an ETR configured to accept and verify such
>> "piggybacked" mapping data receives such a Map-Request and it does
>> not have this mapping in the map-cache, it may originate a "verifying
>> Map-Request", addressed to the map-requesting ITR.  If the ETR has a
>> map-cache entry that matches the "piggybacked" EID and the RLOC is in
>> the locator-set for the entry, then it may send the "verifying Map-
>> Request" directly to the originating Map-Request source.  If the RLOC
>> is not in the locator-set, then the ETR MUST send the "verifying Map-
>> Request" to the "piggybacked" EID.  Doing this forces the "verifying
>> Map-Request" to go through the mapping database system to reach the
>> authoritative source of information about that EID, guarding against
>> RLOC-spoofing in in the "piggybacked" mapping data.
>
> I want to understand this better and I guess reading to the end of the document will answer some of my questions. But as a general rule, I think we should not trust other nodes in the network to claim alternative addresses for themselves, unless we can somehow verify (via return routability or via mapping data base) that they appear to really be at that address. So I am wondering if the "may originate" should become "originates". But I'm reading on.

I think the right thing here is already specified in your text for the case when the map-cache entry exists. But I think you need to change the "may originate" in the to "MUST originate" when there is no map-cache entry. Otherwise, you are believing a locator claim from a random packet sent to you. It is too easy to misuse this, and the remedy is simple: just require the same check as you already do when the cache entry exists but the locator is new.

Jari

This is the last part of my review, as far as the actual document contents go. I will send another summary e-mail.

Technical:

> 14.1.  LISP Address Type Codes
>
>    Instance ID type codes have a range from 0 to 15, of which 0 and 1
>    have been allocated [LCAF].  New Type Codes MUST be allocated
>    starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
>    Type Codes 11 - 15 are available on a First Come First Served policy.
>
>    The following codes have been allocated:
>
>    Type 0:  Null Body Type
>
>    Type 1:  AFI List Type
>
>    See [LCAF] for details for other possible unapproved address
>    encodings.  The unapproved LCAF encodings are an area for further
>    study and experimentation.

To begin with, I did not understand this definition. I'm trying to understand where the LCAF draft actually makes the instance ID allocations, and I can't see it. In addition, the "Null Body Type" string only appears twice in this and the LCAF draft, and neither occurrence explains what it is. I think something is missing here.

Finally, I do not understand why this section is in -lisp to begin with. The string "LISP Address Type Code" does not appear in the rest of the document AFAICT. The allocations in the LCAF draft seem to be inside a format defined in that draft.  Shouldn't the IANA allocations and the creation of the registry be in that draft as well? This seems particularly important, given that the list of types in -lisp does not match the list in -lcaf.

Suggested edit: delete this section.

>
>
>    o  The following policies are used here with the meanings defined in
>      BCP 26: "Specification Required", "IETF Consensus", "Experimental
>      Use", "First Come First Served".

None of these terms are used in the rest of the document.

> 14.  IANA Considerations

This sections makes the right allocations from other, already existing registries (like UDP port numbers). But it should also define what the policies are for allocating new values with the various new number spaces that Lisp introduces:

- flags
- type
- reserved
- act
- unused flags
- ...

>    [BGP-SEC]  Lepinski, M., "An Overview of BGPSEC",
>              draft-lepinski-bgpsec-overview-00.txt (work in progress),
>              March 2011.
>
>    [KARP]    Lebovitz, G. and M. Bhatia, "Keying and Authentication for
>              Routing Protocols (KARP)Design Guidelines",
>              draft-ietf-karp-design-guide-02.txt (work in progress),
>              March 2011.
>    [RPKI]    Lepinski, M., "An Infrastructure to Support Secure
>              Internet Routing", draft-ietf-sidr-arch-13.txt (work in
>              progress), February 2011.


I have a hard time seeing why these should be normative references. They are just mentioned as work that is in progress in securing the routing system. You do not need to read these to implement LISP as specified in this document, or even to understand what Lisp is or its impacts.

>    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>              STD 13, RFC 1034, November 1987.

If you look at the way this is referenced from the text, it is clear that this should be a non-normative reference.

      The host obtains
      a destination EID the same way it obtains an destination address
      today, for example through a Domain Name System (DNS) [RFC1034]
      lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.

>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>              A., Peterson, J., Sparks, R., Handley, M., and E.
>              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>              June 2002.

Same as above.

>    [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
>              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
>              March 2000.

If you look at the way this is referenced from the text, I think this should be a non-normative reference.

  o  On an ITR, prepending a new IP header consists of adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Routers that support GRE
      tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
      support this action.

GRE is here use as an example, not as normative behavior.

>    [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
>              via IPv4 Clouds", RFC 3056, February 2001.

Same as above.

>
>    [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
>              Optimization for Mobile IPv6", RFC 4866, May 2007.

I think this one can be non-normative or even be removed, depending on how the mobility section rewrite goes.

>
>    [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
>              Workshop on Routing and Addressing", RFC 4984,
>              September 2007.

Background. Non-normative.

>    [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>              NUMBERS
>              http://www.iana.org/assignments/address-family-numbers.
>
>    [AFI-REGISTRY]
>              IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
>              NUMBER registry http://www.iana.org/assignments/
>              address-family-numbers/
>              address-family-numbers.xml#address-family-numbers-1.

Is there really no better reference for this, an RFC perhaps?

I wish there were... and that RFC could be put in to the normative-reference section. If there is no suitable RFC I'm fine with the current two references as-is.

>    [INTERWORK]
>              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
>              "Interworking LISP with IPv4 and IPv6",
>              draft-ietf-lisp-interworking-02.txt (work in progress).

I think this one should be normative. This is such a key piece of work to understanding Lisp, and the text seems to treat it as if it is a normative part. For instance:

  Proxy ITR (PITR):  A PITR is also known as a PTR is defined and
      described in [INTERWORK], a PITR acts like an ITR but does so on
      behalf of non-LISP sites which send packets to destinations at
      LISP sites.

>    [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
>              draft-ietf-lisp-ms-09.txt (work in progress).

Isn't this normative as well? Here's an example of how the text refers to it:

  Map-Requests can also be LISP encapsulated using UDP destination port
  4342 with a LISP type value set to "Encapsulated Control Message",
  when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
  LISP encapsulated the same way from a Map-Server to an ETR.  Details
  on encapsulated Map-Requests and Map-Resolvers can be found in
  [LISP-MS].

>
>
>    [VERSIONING]
>              Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
>              Versioning", draft-ietf-lisp-map-versioning-01.txt (work
>              in progress).

I suspect this is normative, too. See Section 6.6.3.

Jari

I'm still continuing my review. I've now read halfway through Section 11, and hope to complete the review by Friday.

Technical:

> 6.3.  Routing Locator Reachability

I think Lisp supports only bidirectional reachability (unless it relies on underlying BGP information), but I was unable to tell for sure from the document. Nonces and probes appear to work only when the same locator pairs are used for both directions of traffic. Could you say something about this in the document?

> 6.5.  Routing Locator Hashing

It may be useful to point to http://tools.ietf.org/html/draft-ietf-6man-flow-ecmp-05 as well.

>    1.  Either a source and destination address hash can be used or the
>        traditional 5-tuple hash which includes the source and
>        destination addresses, source and destination TCP, UDP, or SCTP
>        port numbers and the IP protocol number field or IPv6 next-
>        protocol fields of a packet a host originates from within a LISP
>        site.  When a packet is not a TCP, UDP, or SCTP packet, the
>        source and destination addresses only from the header are used to
>        compute the hash.

There is a complication that fragments, and in general, IPv6 extension headers make the 5-tuple approach impractical on some systems. I wonder if this should affect the recommendation somehow. I can see the danger that people implement the 5-tuple check incompletely, causing fragmented packets to potentially go to a different path. But this is obviously a general issue, not Lisp specific. I can't remember other recommendations than the 6man document above about this matter. Does someone else remember?

> 6.6.2. Solicit-Map-Request (SMR)

The various rate limit mechanisms should either be specified or you should state that the right parameters are still under experimentation (I'd prefer the latter).

>    Since the ETRs don't keep track of remote ITRs that have cached their
>    mappings, they do not know which ITRs need to have their mappings
>    updated.  As a result, an ETR will solicit Map-Requests (called an
>    SMR message) from those sites to which it has been sending
>    encapsulated data to for the last minute.  In particular, an ETR will
>    send an SMR an ITR to which it has recently sent encapsulated data.

More time factors that we do not yet know if they work well.

But more importantly, what happens with ITRs who are not currently sending data but had cached a map entry? If the previous cache entry still contains working locators, we are fine, but what if not? Doesn't this point to a limitation that locator sets cannot (completely) change except on time scales longer than map entry cache lifetimes? Or am I missing something?

>    o  When a tunnel encapsulated packet is received by an ETR, the outer
>      destination address may not be the address of the router.

This seems like a basic thing, but I must have missed this. Which Lisp tunnel packets do not use the address of an ETR as the destination?

> 7.  Router Performance Considerations

I expected this section to also talk about the effects of caching-based designs. What happens when you suddenly are getting a flood of new destinations to find a mapping to, etc.

> 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.  The
> ITR will use a circular buffer for caching the IPv4 and UDP headers
> of traceroute packets.

All IPv4 UDP packets? Uh oh... perhaps you should include some of the implications either here or Section 7. This means inspecting every packet, for instance... Are you sure there are no other solutions to doing this?

> The signature of a traceroute packet comes in two forms.  The first
> form is encoded as a UDP message where the destination port is
> inspected for a range of values.  The second form is encoded as an
> ICMP message where the IP identification field is inspected for a
> well-known value.

This is not much fun, either. Traceroute implementations generally allow quite liberal specification of which packets should be used for the probing: ICMP echo, UDP, TCP SYN, port selections, etc. At the very least you should document what the implications are, i.e., that only limited traceroute functionality can be supported. I don't think you can rely on configuration of port ranges and other things, because even if the administrator would know what traceroute types are used in his own network, traceroute should also work from the outside in the other direction, initiated by other people.

> 10.  Mobility Considerations

We've talked about this in the past. I don't think mobility-as-a-feature-of-lisp belongs in this document, it belongs in the possible future document on Lisp mobility. We should not speculate what could be done.

The impacts of Lisp to mobility protocols are, however, in scope. But I at least found the text somewhat unclear. First, I think you have decide what kind of scenarios you'd like to support. The text talks about changing EIDs, and I think that is something that you wouldn't necessarily need to cover; it is pretty alien to the current mobility protocols. But it would be a very reasonable question to ask if mobile nodes can move in and out of Lisp networks, and what the effects are? As far as I can tell, this can subdivided into the following aspects:

1) Pure mobile nodes (like most of today's laptops and PDAs) that do not support mobility protocols. When such a node arrives in a Lisp site, it will cause cache activity as it continues to do what it wants to do and re-establish connections to the sites that it wants to communicate with.

2) Mobile nodes that support a mobility protocol (MIP4, MIP6, HIP, etc). If all parties in the communication are in Lisp sites, these should not be affected beyond the usual cache effects. Lisp as is should be able to support this.

3) As above but using interworking between the Lisp and the Non-Lisp Internets. These bring NAT-like effects, I think, which may work with MIP4 but may have issues with MIP6.

4) Home agents and other forwarding agents. Can these exist in a Lisp site? I think the considerations are very similar to those in items 2 and 3.

Here's a suggested quick rewrite:

10.  Mobility Considerations

  There are several kinds of mobility of which only some might be of
  concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

  A site wishes to change its attachment points to the Internet, and
  its LISP Tunnel Routers will have new RLOCs when it changes upstream
  providers.  Changes in EID-RLOC mappings for sites are expected to be
  handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

  An individual endpoint wishes to move, but is not concerned about
  maintaining session continuity.  Renumbering is involved.  LISP can
  help with the issues surrounding renumbering [RFC4192] [LISA96] by
  decoupling the address space used by a site from the address spaces
  used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

  Fast endpoint mobility occurs when an endpoint moves relatively
  rapidly, changing its IP layer network attachment point.  Maintenance
  of session continuity is a goal.  This is where the Mobile IPv4
  [RFC5944] and Mobile IPv6 [RFC3775] [RFC4866]. Possible Lisp support for
  similar functionality remains to be addressed by future work.

10.4. Interaction with Existing Mobile Nodes

  Mobile nodes that do not support any particular protocol mechanism (such
  as Mobile IP) should appear to Lisp sites just as other hosts do. However,
  nodes that move around are likely to re-establish connections to their
  communication peers when they enter the Lisp site, and this will likely
  cause additional mapping entries to be fetched for the caches, and
  may cause some initial performance degradation.

  Mobile nodes that use a mobility protocol (Mobile IPv4, Mobile IPv6, HIP)
  but communicate entirely within Lisp-enabled sites should not experience
  any differences to their usual operations. Again, mobile node movement will
  cause new communication patterns to the relevant home agents and, in the case
  of route optimization, correspondent nodes.

  The use of mobility protocols between Lisp-enabled and non-Lisp enabled sites
  will likely cause NAT-like effects. The specific effects remain a topic for further
  work and experimentation.

Editorial:

>    There are two basic deployment trade-offs to consider: centralized
>    versus distributed caches and flat, recursive, or re-encapsulating
>    tunneling.  When deciding on centralized versus distributed caching,
>    the following issues should be considered:

Perhaps you should define what you mean by centralized caching, distributed caching, etc. It was not clear for me.

Still more parts in my review. I have now read until the beginning of Section 6.3.1. Some of these comments may change as I have read to the end of the document.

Technical:

>    When an ETR is misconfigured or compromised, it could return coarse
>    EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
>    cover EID-prefixes which are allocated to other sites redirecting
>    their traffic to the locators of the compromised site.
>
>    To solve this problem, there are two basic solutions that could be
>    used.  The first is to have Map-Servers proxy-map-reply on behalf of
>    ETRs so their registered EID-prefixes are the ones returned in Map-
>    Replies.  Since the interaction between an ETR and Map-Server is
>    secured with shared-keys, it is more difficult for an ETR to
>    misbehave.  The second solution is to have ITRs and PTRs cache EID-
>    prefixes with mask-lengths that are greater than or equal to a
>    configured prefix length.  This limits the damage to a specific width
>    of any EID-prefix advertised, but needs to be coordinated with the
>    allocation of site prefixes.  These solutions can be used
>    independently or at the same time.
>
>    At the time of this writing, other approaches are being considered
>    and researched.

There are obvious remaining issues with these solutions. Map-Servers may also be compromised, it is not clear that site prefix allocations have all equal size, ETRs may still return prefixes for someone else, etc. Have these been described in the security considerations section?

> S:  This is the Security bit.  When set to 1 the field following the
>      Reserved field will have the following format.  The detailed
>      format of the Authentication Data Content is for further study.

For further study, as in not defined by any of the LISP documents currently being published? It might be more appropriate to say "This contents of this field are reserved for future use and no current authentication data formats are defined."  And the implications should be described somewhere in security considerations section or the overall list of issues that need further work. (Or if this is actually defined somewhere, say "The detailed format of the field is described in [normative reference].")

And why is this definition different from other places where an authentication data field was included?

>    2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
>        message for an RLOC it is using.  This indicates that the RLOC is
>        likely down.

There is obviously a need to soften the impact spurious or spoofed ICMP messages. There is probably a TCP RFC somewhere where you can copy some current advise wrt. trusting ICMP error messages.

> When a bit goes from 1 to 0, the ETR will
> refrain from encapsulating packets to an RLOC that is indicated as
> down.

Some considerations might be necessary for conflicting information. For instance, what do you do if you receive a packet from a locator that is claimed to be down by another ITR?

Also, I do not fully understand what happens when you include the map version numbers in a LISP packet (V=1) and no nonce. Can off-the path attackers spoof a packet that claims to come from an ITR and which changes the locator status bits? That would open an ETR up for believe anyone in the Internet. Or am I missing something?

Editorial:

>      10.0.0.0/8
>      10.1.0.0/16
>      10.1.1.0/24
>      10.1.2.0/24
>
>    A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
>    count of 1 to be returned with a mapping record EID-prefix of
>    10.1.1.0/24.

This is just a comment, but I would personally use the IPv4 example address ranges for these sorts of examples, particularly given that both identifiers and locators are normally globally reachable addresses.

Continuing my review:

Technical:

> LISP Nonce:  The LISP nonce field is a 24-bit value that is randomly
> generated by an ITR when the N-bit is set to 1.  The nonce is also
> used when the E-bit is set to request the nonce value to be echoed
> by the other side when packets are returned.  When the E-bit is
> clear but the N-bit is set, a remote ITR is either echoing a
> previously requested echo-nonce or providing a random nonce.  See
> Section 6.3.1 for more details.

I read 6.3.1 and this text but it was still unclear to me if the nonces are generated fresh on a per-packet basis, or if one nonce value is sent on a stream of packets until you see it echoed back.

Can you clarify?

>    When doing ITR/PITR encapsulation:
>
>    o  The outer header Time to Live field (or Hop Limit field, in case
>      of IPv6) SHOULD be copied from the inner header Time to Live
>      field.

Just checking: this happens *after* you have decremented the TTL/HL as you were making a forwarding decision for the packet. So when the packet passes through an ITR, the outer IP header has a TTL that is decremented by one compared to the original packet, when looking at the packets on the wire. Right?

>    Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
>    after decapsulating, the net effect of this is that the new outer
>    header will carry the same Time to Live as the old outer header.

This seems wrong. Shouldn't the TTL be decremented even in this situation. But I'm sure you thought about this. What am I missing?

> The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
> field and the IPv6 Traffic Class field [RFC3168].  The ECN field
> requires special treatment in order to avoid discarding indications
> of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
> field from the inner header to the outer header.  Re-encapsulation
> MUST copy the 2-bit ECN field from the stripped outer header to the
> new outer header.  If the ECN field contains a congestion indication
> codepoint (the value is '11', the Congestion Experienced (CE)
> codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
> the stripped outer header to the surviving inner header that is used
> to forward the packet beyond the ETR.  These requirements preserve
> Congestion Experienced (CE) indications when a packet that uses ECN
> traverses a LISP tunnel and becomes marked with a CE indication due
> to congestion between the tunnel endpoints.

This works for routers that do not participate in ECN process themselves. I suppose it is theoretically possible that an xTR would also be doing ECN. Perhaps you could add to the end of this paragraph: "In addition, at the end of the process specified above, an ECN-capable xTR may perform its own modification of the ECN bits per [RFC3168] when it detects congestion.

> An ITR that is configured with mapping database information (i.e. it
> is also an ETR) may optionally include those mappings in a Map-
> Request.  When an ETR configured to accept and verify such
> "piggybacked" mapping data receives such a Map-Request and it does
> not have this mapping in the map-cache, it may originate a "verifying
> Map-Request", addressed to the map-requesting ITR.  If the ETR has a
> map-cache entry that matches the "piggybacked" EID and the RLOC is in
> the locator-set for the entry, then it may send the "verifying Map-
> Request" directly to the originating Map-Request source.  If the RLOC
> is not in the locator-set, then the ETR MUST send the "verifying Map-
> Request" to the "piggybacked" EID.  Doing this forces the "verifying
> Map-Request" to go through the mapping database system to reach the
> authoritative source of information about that EID, guarding against
> RLOC-spoofing in in the "piggybacked" mapping data.

I want to understand this better and I guess reading to the end of the document will answer some of my questions. But as a general rule, I think we should not trust other nodes in the network to claim alternative addresses for themselves, unless we can somehow verify (via return routability or via mapping data base) that they appear to really be at that address. So I am at least wondering if the "may originate" should become "originates". But I'm reading on.

> Weight:  when priorities are the same for multiple RLOCs, the weight
> indicates how to balance unicast traffic between them.  Weight is
> encoded as a relative weight of total unicast packets that match
> the mapping entry.  For example if there are 4 locators in a
> locator set, where the weights assigned are 30, 20, 20, and 10,
> the first locator will get 37.5% of the traffic, the 2nd and 3rd
> locators will get 25% of traffic and the 4th locator will get
> 12.5% of the traffic.  If all weights for a locator-set are equal,
> receiver of the Map-Reply will decide how to load-split traffic.

I am  surprised by the last sentence. Do you really mean that the receiver has the power to distribute, e.g., all traffic to the first locator? Or that the load-split will be equal among the locators? If you mean the former, how do I signal that I desire an equal load split? Send 49-51?

Editorial:

>    UDP Length:  The UDP length field is for an IPv4 encapsulated packet,
>      the inner header Total Length plus the UDP and LISP header lengths
>      are used.  For an IPv6 encapsulated packet, the inner header
>      Payload Length plus the size of the IPv6 header (40 bytes) plus
>      the size of the UDP and LISP headers are used.  The UDP header
>      length is 8 bytes.


I had trouble parsing this text. The first sentence seems to say that the is only for IPv4, but I think you mean that the values are calculated in different ways for IPv4 and IPv6.

Please clarify/reformulate.

> The format of the
> last 4 bytes 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      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

... format of the last 8 bytes of the LISP header ....

>    M: When set, it indicates a Map-Reply Record segment is included in
>      the Map-Request.

Unlike other bits this one has no name. Or is it the "Map-Reply Record Bit"?

>    S: This is the SMR bit.  See Section 6.6.2 for details.

Please expand SMR, as this is the first time this abbreviation appears in the document.

>    S: This is the SMR bit.  See Section 6.6.2 for details.
>
>    s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
>      sending a Map-Request in response to a received SMR-based Map-
>      Request.

The naming looks somewhat odd. Maybe SMR-request and SMR-response bits, or Solicited Map Request bit and Solicited Map Request Response bit...

> IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
> additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
> present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
> Address) pair must always be encoded.  Multiple ITR-RLOC Address
> fields are used so a Map-Replier can select which destination
> address to use for a Map-Reply.  The IRC value ranges from 0 to
> 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
> and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.

Perhaps you should explicitly say that value 0 means there are 1 ITR-RLOC addresses.

(You say only that "At least one pair must always be encoded", but does that mean that value 0 is disallowed or that it means 1 pair?)

Jari

Continuing with my review. Many of the observations below are questions. I may understand many of these better once I finish the whole document, but I wanted to send out my notes already now.

Technical:

>    o  End-systems (hosts) only send to addresses which are EIDs.  They
>      don't know addresses are EIDs versus RLOCs but assume packets get
>      to LISP routers, which in turn, deliver packets to the destination
>      the end-system has specified.

Is this always true, e.g, when some interworking mechanism between the LISP and non-LISP parts of the Internet is in use, and one of the peers employs some NAT traversal techniques? It would seem that there can be cases where the peers observe RLOC addresses and use them for some purpose.

This might be something to mention in the limitations/things to test section, for instance, or discussed in in the interworking document (and maybe it already is, I did not check).


>
>  A server host can be the endpoint
>      of a LISP tunnel as well.
...
>    o  RLOCs are always IP addresses assigned to routers

Isn't this an inconsistency? Or is a server that terminates a tunnel called a router?

>    o  When a router originates packets it may use as a source address
>      either an EID or RLOC.

You should state somewhere what the manageability requirements are for making this happen, or if hardcoded policies are sufficient (e.g., iBGP vs. eBGP use of addresses). Does this require additional functionality for RFC 3484 style source address selection, or can you cope with existing functionality?

Note: I'm not asking for any new functionality, just a statement about the expectations.

>    In order to avoid excessive packet overhead as well as possible
>    encapsulation loops, this document mandates that a maximum of two
>    LISP headers can be prepended to a packet.

This seems hard to mandate in any real sense. Perhaps you want to say "recommends" instead of "mandates"?
>    2.  The LISP ITR must be able to map the EID destination to an RLOC
>        of one of the ETRs at the destination site.  The specific method
>        used to do this is not described in this example.  See [ALT] or
>        [CONS] for possible solutions.
>
>    3.  The ITR will send a LISP Map-Request.  Map-Requests SHOULD be
>        rate-limited.
>
>    4.  When an alternate mapping system is not in use, the Map-Request
>        packet is routed through the underlying routing system.
>        Otherwise, the Map-Request packet is routed on an alternate
>        logical topology.  In either case, when the Map-Request arrives
>        at one of the ETRs at the destination site, it will process the
>        packet as a control message.

First, the the "alternate mapping system" appears here for the first time. Maybe you should indicate it refers to [ALT].

Second, parts of step 4 go pretty deep in what the specific mapping methods are. I'm wondering if this alternative text would fit better:

"4.  The Map-Request packet is delivered to the right ETR with the help of the mapping system. (For instance, in [ALT] this happens via an EID-based alternate routing topology.) In any case, when the Map-Request arrives ..."

> 6.  The ITR receives the Map-Reply message, parses the message (to
>    check for format validity) and stores the mapping information
>    from the packet.  This information is stored in the ITR's EID-to-
>    RLOC mapping cache.  Note that the map cache is an on-demand
>    cache.  An ITR will manage its map cache in such a way that
>    optimizes for its resource constraints.

This is just a comment, but FWIW, I am not super happy about the way the caching is an integral part of the specifications for LISP. Fundamentally, you could have used two orthogonal tools for dealing with routing scalability: 1. have only a subset of routers have to deal with EID routing (the xTRs) and 2. use caching for scaling these routers better. If we had done this, then we would have had a very easy answer to those who have criticized the caching approach over the years: it is optional and up to the implementors to use or not. The first tool would still have been a valid approach to make the Internet scale better, even if you never did any caching.

In any case, your description of the thins-to-test should probably say something about effects of caching.

>    8.  The ETR receives these packets directly (since the destination
>        address is one of its assigned IP addresses), strips the LISP
>        header and forwards the packets to the attached destination host.
>    Spoofing of inner header addresses of LISP encapsulated packets is
>    possible like with any tunneling mechanism.  ITRs MUST verify the
>    source address of a packet to be an EID that belongs to the site's
>    EID-prefix range prior to encapsulation.  An ETR must only
>    decapsulate and forward datagrams with an inner header destination
>    that matches one of its EID-prefix ranges.  If, upon receipt and
>    decapsulation, the destination EID of a datagram does not match one
>    of the ETR's configured EID-prefixes, the ETR MUST drop the
>    datragram.  If a LISP encapsulated packet arrives at an ETR, it MAY
>    compare the inner header source EID address and the outer header
>    source RLOC address with the mapping that exists in the mapping
>    database.  Then when spoofing attacks occur, the outer header source
>    RLOC address can be used to trace back the attack to the source site,
>    using existing operational tools.

First, I think Step 8 should be slightly edited to cover the fact that some additional checks are being made. E.g., "The ETR receives these packets directly (since ...), checks the validity of the addresses used in the packet, strips the LISP header and ..."

Second, I wish you would have specified the source address checks better. Are there situations where you would NOT want to make a pretty strict test, i.e., that source EID maps to  source RLOC?

> The next sub-sections illustrate packet formats for the
>    homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
>    combinations SHOULD be supported.

For interoperability, wouldn't it be cleaner to have a MUST here? How would I otherwise know if I can send an IPv4-in-IPv6 packet to a destination?

Editorial:

> Since additional tunnel headers are prepended, the packet becomes
> larger and can exceed the MTU of any link traversed from the ITR to
> the ETR.  It is recommended in IPv4 that packets do not get
> fragmented as they are encapsulated by the ITR.  Instead, the packet
> is dropped and an ICMP Too Big message is returned to the source.

This feels odd, as there is no explanation in this point about what you do with IPv6. Maybe a sentence on IPv6 should be added?

I'm sure the details on IPv6 follow later in the document, but I suspect that other readers would be wondering here in the same way as I am.

I'm reading on...

I am reviewing this draft. Here's the first part of my review. So far I like what I've seen, but there are a few small observations below. I'm at the beginning of Section 4, and will continue tomorrow with the rest.

Technical:

> 2.  Introduction

I liked how this section was written. I would like to add a little bit of information, however. The section already talks about experimentation around the mapping system, but like with the other documents it would be useful to explicitly point out the areas where some further testing is needed. I presume it is more than just the mapping system.

> Note
> that there may be transient conditions when the EID-prefix for the
> site and locator-set for each EID-prefix may not be the same on
> all ETRs.  This has no negative implications.

It is of course fine to have transient conditions like this. But I'm trying hard to convince myself that this would never have negative implications. Why would this be the case? What if we for some reason needed to quickly add or remove an EID prefix? Wouldn't there be a short negative implication if a particular ETR did not yet add a new prefix, for instance?

I guess I'm wondering why you are making such an absolute statement about the lack of implications. Maybe saying nothing or saying "This has usually no negative implications" would be better.

Editorial:

> This document describes the protocol that implements these functions.
> The database which stores the mappings between EIDs and RLOCs is
> explicitly a separate "module" to facilitate experimentation with a
> variety of approaches.  One database design that is being developed
> and prototyped as part of the LISP working group work is [ALT].
> Others that have been described but not implemented include [CONS],
> [EMACS], [RPMD], [NERD].  Finally, [LISP-MS], documents a general-
> purpose service interface for accessing a mapping database; this
> interface is intended to make the mapping database modular so that
> different approaches can be tried without the need to modify
> installed xTRs.

I think the introduction would be a good place to add some pointers to not just ALT/MS and their competing alternatives but also to -interworking and perhaps also -map-versioning and -multicast.

> LISP can be incrementally deployed, without a "flag
> day", and offers traffic engineering, multi-homing, and mobility
> benefits even to early adopters, when there are relatively few LISP-
> capable sites.

s/when/even when/ (sounds better to me, but I'm not a native speaker)

I think the mobility benefits could be left to another document, since there is nothing about this in the current set of documents. I think your message about the benefits will be stronger if you just say "traffic engineeering and multi-homing benefits".

>  == Outdated reference: A later version (-05) exists of
>      draft-ietf-karp-design-guide-02
>
>  ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275)
>
>  == Outdated reference: A later version (-09) exists of
>      draft-ietf-lisp-alt-07
>
>  == Outdated reference: A later version (-06) exists of
>      draft-ietf-lisp-lig-02
>
>  == Outdated reference: A later version (-11) exists of draft-ietf-lisp-ms-09
>
>  == Outdated reference: A later version (-08) exists of
>      draft-ietf-lisp-multicast-06
>
>  -- Unexpected draft version: The latest known version of
>      draft-iannone-openlisp-implementation is -01, but you're referring to -02.
>
>  -- No information found for draft-handley-p2ppush-unpublished-2007726 - is
>      the name correct?
>
>  == Outdated reference: A later version (-04) exists of
>      draft-ietf-lisp-map-versioning-01

These could perhaps be fixed.

>  == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the
>      document.
>    o  Source host "host1.example.abc.com" is sending a packet to
>      "host2.example.xyz.com", exactly what host1 would do if the site
>      was not using LISP.

These need to change. We should not use non-RFC2606 FQDNs. For instance, abc.com in particular is someone else's domain. Use host1.abc.example.com or example.com vs. example.net.

>      Reachability Algoriths described in Section 6.3.

typo

>    homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4

homogeneous

(1.a) Joel Halpern is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document has had adequate review. The shepherd has no concerns
regarding the reviews which have been performed.

(1.c) The document shepherd does not have concerns that the document
requires a broader review.

(1.d) No IPR disclosures have been raised. Several issues may be raised
at IETF last call (again) relating to attack surfaces of various
parts of LISP. Questions about the readability of the document
may be raised. Many reviewers concerns seemed more appropriate
for a document intended for PS publication whereas we are
looking for experimental publication.

(1.e) The WG consensus reflects active agreement among about about 10
participants, with the bulk of the WG being silent, and a few vocal
objectors.

(1.f) No threats of appeal or discontent on this document have
manifested.

(1.g) IDNITs responds with:

== There are 8 instances of lines with non-RFC2606-compliant FQDNs in the
document.

== There are 10 instances of lines with private range IPv4 addresses in
the document. If these are generic example addresses, they should be
changed to use any of the ranges defined in RFC 5735 (or successor):
192.0.2.x, 198.51.100.x or 203.0.113.x.


The authors responded with the need to call on a broader and deeper
set of example prefixes to add meaning to the document. Documentation
prefixes alone could not provide this so RFC1918 based addresses were used.


(1.h) References have been split. No downward normative references exist.
One WIP draft exists as a normative reference, however it has
already been submitted to the IESG (draft-ietf-sidr-arch)

(1.i) The document makes requests of the IANA, The IANA considerations
are consistent and well formed.

(1.j) Formal language has been verified.

(1.k)
Technical Summary

This draft describes a network-based protocol that enables separation
of IP addresses into two new numbering spaces: Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). No changes are required to
either host protocol stacks or to the "core" of the Internet
infrastructure. LISP can be incrementally deployed, without a "flag
day", and offers traffic engineering, multi-homing, and mobility
benefits even to early adopters, when there are relatively few LISP-
capable sites.

Working Group Summary

Many of the comments received during last call were complex and
difficult for the working group to understand. The working group last
call was held open for an extended time to ensure sufficient
discussion and sufficient effort to address those objections.

Document Quality

There are several implementations of LISP in existence.
Alia Atlas has done significant review and deserves
special mention.