Identifier-Locator Network Protocol (ILNP) Architectural Description
draft-irtf-rrg-ilnp-arch-06

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.

  
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

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.