Identifier-Locator Network Protocol (ILNP) Architectural Description
draft-irtf-rrg-ilnp-arch-06
Yes
(Ron Bonica)
No Objection
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Stephen Farrell)
Note: This ballot was opened for revision 03 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2012-05-23 for -03)
Unknown
The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text. This is particularly important in this document as it is the cornerstone of the ILNP project. I believe it would also be really good to do more analysis in this document of what type of further experimentation is welcomed, and how it should be carried out. Without that, this document is little more than a hostoric record. --- A reference in the Introduction to RFC 6115 would be highly appropriate.
Ron Bonica Former IESG member
(was No Objection)
Yes
Yes
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -03)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -03)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2012-05-22 for -03)
Unknown
I am fine with either 5742 IESG note, but if we go with the latter one about LISP and HIP, it should probably apply to all of the documents. I don't know what Lars would do differently based on the IESG note, so it is probably moot.
Ralph Droms Former IESG member
No Objection
No Objection
(for -03)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -03)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -03)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2012-05-24 for -03)
Unknown
SB> This document should provide the reader with greater context by the inclusion of a reference to RFC6115. SB> The authors are requested to review the document to make that the reader is not given the impression that the IETF is actively enhancing the functionality of IPv4. be mapped and then tunnelled through the inter-domain core of the Internet. Another class being considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evolutionary approaches. SB> Given that LISP is an IETF WG which seems to be operating in SB> this area, why is there no reference to this work? when designing the TCP/IP protocol suite. Unfortunately, that separation did not occur, so the deployed IPv4 and IPv6 Internet entangles upper-layer protocols (e.g. TCP, UDP) with network-layer routing and topology information (e.g. IP addresses) [IEN1] [RFC768] [RFC793]. SB> You can have ID/Loc splitting below the transport layer and there are many ways to design it. The key idea proposed for ILNP is to directly and specifically change the overloaded semantics of the IP address. The Internet community has indicated explicitly, several times, that this use of overloaded semantics is a significant problem with the use of the Internet protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984]. SB> Please be aware that there are a number of competing proposal to encode information in an IPv6 address. Layer | IP | ILNP ---------------+----------------------+--------------- Application | FQDN or IP address | FQDN Transport | IP address | Identifier Network | IP address | Locator Physical i/f | IP address | MAC address ---------------+----------------------+--------------- SB> What if the physical interface is not a LAN? SB> Surely IP resolves an IP address to a physical interface or indeed a virtual interface. This is particularly SB> necessary with an unnumbered interface. SB> SB> You might consider borrowing the notation used by the Transport Network(sic) engineers and use a client SB> server model when you go below IP. SB> SB> Hopefully you later consider recursive newtwork designs. Where, today, IP packets have: - source IP address, destination IP address instead ILNP packets have: - source I-LV, destination I-LV However, it must be emphasised that the I-LV and the IP address are *not* equivalent. With these naming enhancements, we will improve the Internet architecture by adding explicit harmonised support for many functions, such as multi-homing, mobility and IP Security. SB> This is a view of the network based on the concept of a SB> classic global IP layer. SB> There are many new applications emerging that don't think that SB> way and want multiple instances. In other words they have SB> addresses that exist outside the network - sort of Godel addresses. Specifically in response to [RFC4984], ILNP improves routing scalability by helping multi-homed sites operate effectively with provider-aggregatable (PA) address prefixes. Many multi-homed sites today request provider-independent (PI) address prefixes so they can provide session survivability despite the failure of one or more access links or Internet Service Providers (ISPs). ILNP provides this session survivability by having a provider-independent node Identifier value that is free of any topological semantics. This I value can be bound dynamically to a provider-aggregatable L value, the latter being a topological SB> I may have missed it, but I do not see a definition or "I" or "L" 3. ARCHITECTURAL CHANGES INTRODUCED BY ILNP 3.1 Identifiers In normal operation, a node will not change its set of valid Identifier values frequently. However, a node MAY change its set SB>You do not define frequently. of valid Identifier values over time, for example in an effort to provide identity obfuscation, while remaining subject to the architectural rule of the preceding paragraph. SB> Surely there are less arcane reasons to change identity besides SB> security by obscurity, for example there are business reasons SB> such as restructuring the business or re-purposing of the SB> equipment. 3.1.2 Syntax ILNP Identifiers have the same syntax as IPv6 Interface Identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI], which helps with backwards compatibility. SB> IFF the requirement is to solve the problem with a single SB> layer of encapsulation. There is no semantic equivalent to an ILNP Identifier in IPv4 or IPv6 today. SB> Is this true? You could regard the problem as solved SB> by updating DNS, thus the issue is not semantics SB> but performance in today's networks. The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6 Interface Identifiers contains a bit indicating whether the value has global-scope or local-scope [IEEE-EUI] [RFC4219]. ILNP Identifiers have either global-scope or local-scope. If they have global scope, they SHOULD be globally unique. SB> Why are global (and you need to define global) identifiers SB> not REQUIRED to be unique? Regardless of whether an Identifier is global-scope or local-scope, an Identifier MUST be unique within the scope of a given Locator value to which it is bound for a given session or packet flow. SB> For that network instance. As an example, with ILNPv6, the ordinary IPv6 Neighbour Discovery (ND) processes ensure that this is true, just as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork have the same IPv6 address at the same time. SB> Is that true, or do mean that no more than two are concurrently SB> operational in that network instance? 3.4 Notation 3.5 Transport-layer state and transport pseudo-headers In ILNP, protocols above the network-layer do not use the Locator values. Thus, the transport-layer uses only the I values for the transport-layer state (e.g. TCP checksum, UDP checksum), as is shown, for example, in expression (6) above. SB> I have not seen you note to the reader that the code to calculate the SB> transport checksums needs to change. SB> SB> Also surely NATs need to change as a result of this? 3.7 ILNP Multicasting Multicast forwarding and routing are unchanged, in order to avoid requiring changes in deployed IP routers and routing protocols. ILNPv4 multicasting is the same as IETF standards-track IPv4 multicasting. SB> What does this mean? SB> You used the IPv4 address as a locator, so either ILNP does SB> not support IPv4 m/c or you only support m/c to the loc. 5.1 Host Multi-Homing (H-MH) At present, host multi-homing is not common in the deployed Internet. SB> Ah, what about all of the laptops that are connected SB> to both Ethernet and WiFi? A number of these have SB> one or more virtual network connections in addition. 8. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT ILNPv4 is backwards compatible with existing IPv4. As the IPv4 address fields are used as 32-bit Locators, using only the address prefix bits of the the 32-bit space, IPv4 routers also would not require changes. An IPv4 router would be unaware whether the packet being forwarded were classic IPv4 or the proposed enhancement in ILNPv4 [ILNP-V4OPTS]. SB> Most IPv4 routers are aware that they are being presented SB> with IPv4 packets carrying options
Wesley Eddy Former IESG member
No Objection
No Objection
(2012-05-21 for -03)
Unknown
I found one typo: Section 3.3: "thought it" -> "though it" In section 5.2, MP-TCP is actually being defined by the MPTCP working group (not TCPM). You could cite RFC 6182 for the MPTCP architecture.