The Locator/ID Separation Protocol (LISP)
RFC 6830
Yes
No Objection
Note: This ballot was opened for revision 22 and is now closed.
(Jari Arkko; former steering group member) (was Discuss, Yes) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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.
(Dan Romascanu; former steering group member) No Objection
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,
(Gonzalo Camarillo; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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.
(Peter Saint-Andre; former steering group member) No Objection
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).
(Ralph Droms; former steering group member) (was Discuss, No Objection) No Objection
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.
(Robert Sparks; former steering group member) (was Discuss) No Objection
Consider tightening the 3 steps listed in section 5.4.1. Step 2 is really the place you calculated L based on S and H.
(Ron Bonica; former steering group member) (was Discuss) No Objection
(Russ Housley; former steering group member) No Objection
This is going for experimental, and I think it clears the bar for experimental. However, I think Section 6 could be much more clear.
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
(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."
(Stewart Bryant; former steering group member) (was Discuss, No Objection) No Objection
"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?
(Wesley Eddy; former steering group member) (was Discuss) No Objection
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"?