The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-24
Yes
(Jari Arkko)
No Objection
(Gonzalo Camarillo)
(Ron Bonica)
(Sean Turner)
Note: This ballot was opened for revision 22 and is now closed.
Jari Arkko Former IESG member
(was Discuss, Yes)
Yes
Yes
(for -23)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2012-02-10 for -23)
Unknown
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 IESG member
No Objection
No Objection
(2012-01-18)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2011-11-29)
Unknown
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 IESG member
No Objection
No Objection
(2011-11-30)
Unknown
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 IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2012-01-17 for -23)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2011-11-29 for -23)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(for -23)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-11-29)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2011-12-13 for -23)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2012-01-05 for -23)
Unknown
(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 IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2012-01-19 for -23)
Unknown
"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 IESG member
(was Discuss)
No Objection
No Objection
(2011-11-29 for -23)
Unknown
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"?