Subject: [RAM] Terminology: ID/Locator split

From: RJ Atkinson <[email-masked]>
Date: Thu, 1 Mar 2007 13:39:03 -0500

In some off-list conversations, it seems that there
are varying definitions for the phrase "ID-Locator split".
I suspect the variance in definitions for that phrase is
causing some confusion in discussions on this list.

	To my mind, when one talks about an "ID/Locator split",
an essential property is that one has both:

1) a "Locator" which is ONLY used for packet forwarding
         and is NEVER visible above the network-layer
         (e.g. no name ever used for network-layer packet forwarding
          is ever visible to TCP)
&&

2) an "Identifier" that is used by the transport-layer
   (e.g. in TCP session state, such as TCP pseudo-header checksum),
   might be used above the transport-layer, and
   is NEVER used for network-layer packet forwarding.

If other folks have CRISP and CLEAR alternative definitions
for "ID-Locator split", then it might be interesting to know
precisely what those alternative definitions are...

Ran

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Scott W Brim <[email-masked]>
Date: Thu, 01 Mar 2007 14:29:52 -0500

>   is NEVER used for network-layer packet forwarding.

I don't get to stop by this party very often, but have you agreed that
there a requirement that there be a single "identifier" down in the
transport layer?  The last line of (2) is certainly true.  I'm
wondering about the 2nd line.

Scott

---

From: <[email-masked]>
Date: Fri, 2 Mar 2007 10:51:10 +0200

Scott W Brim wrote:
>I don't get to stop by this party very often, but have you 
>agreed that there a requirement that there be a single 
>"identifier" down in the transport layer?  The last line of 
>(2) is certainly true.  I'm wondering about the 2nd line.
>

I'd like to question this certainty that you have on the NEVER in 2). We
have good evidence on usability of flat routing on e.g. campus level
(Ethernet, rbridges). Currently IP address is used as a flat identifier
for last hop forwarding within a subnet. It seems conceivable that the
"network layer" actually ends at the last hop router, as the topology
information in the IP address is exhausted, as the last hop forwarding
is done on the destination interface identifier. 

Regards,

	Jarno

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 2 Mar 2007 10:55:53 +0200

Ran,

> causing some confusion in discussions on this list.

I agree with the differences in the use of the term is causing  
confusion.

>   is NEVER used for network-layer packet forwarding.

According to my analysis, there are three "flavours" of the id/loc  
split, as outlined in Section 2 of http://www.ietf.org/internet- 
drafts/draft-nikander-ram-ilse-00.txt:

>       A.  The separation may be implemented above the current  
> transport
>           layer, mainly TCP and UDP.  In practise, many  
> applications do
>           implement a primitive kind of the separation already
>           themselves.  In theory, a library could implement the
>           separation, giving legacy applications the illustration of
>           them being still connected to stable IP locators while in
>           practise using some sort of identifiers.
>
>       B.  The separation may be implemented at or below the transport
>           (i.e. below the socket API) but above the routing part of  
> the
>           IP layer.  There are a plenty of proposals in this space,
>           including SCTP extensions [10], the Host Identity Protocol
>           (HIP) [3], and the SHIM6 protocol [6].
>
>       C.  The separation may be implemented below the host-part of the
>           IP layer.  Again, there are a number of proposals in this
>           space, of which the [9] has recently gained some attention.

Of these, the middle one (B) is closest to the traditional use of the  
term [Chiappa].  And there, only some of the proposed solutions, like  
HIP and SHIM6, really match with the original idea.  At least those  
that do match seem to comply with your definition, but perhaps also  
others.

--Pekka Nikander

[Chiappa]  Chiappa, J., "Endpoints and Endpoint Names: A Proposed
          Enhancement to the Internet Architecture",
          URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Mar 2007 09:59:04 +0100

I've already expressed my concern that the word "split"
is wrong in itself for many of the solutions being
considered. What we have in reality today are context-
dependent locators, which in some contexts are used as
identifiers for transport, security, applications or network
management. The question really is whether we embrace
this architecturally (which shim6 and lisp both do)
or whether we try to change it by abolishing the
context dependency (which is what a true split would
do).

     Brian

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Mar 2007 08:51:25 -0500

On  2 Mar 2007, at 03:51, <[email-masked]> wrote:
> I'd like to question this certainty that you have on the NEVER in 2).
> We have good evidence on usability of flat routing on e.g. campus  
> level
> for last hop forwarding within a subnet.

Ethernet is not at the "network-layer", which was an important
and deliberate part of my original statement.

The question I posed, however, is not whether "flat routing works",
or whether one wants layers above the network-layer entangled
in IP routing, but what one means by various terms.

As a matter of definition, a SPLIT between Identifier and Locator
should mean that the Identifier used above the network-layer
is NOT used for routing, since the Locator is used for routing.

Not splitting them is a legitimate architectural choice.  We have
that today (e.g. TCP session state includes the IPv4 address used
for routing packets).  Clearly, within some limits, the current
approach has worked suitably well for some years.

> It seems conceivable that the

I'm not quite sure what you mean.

If you mean that an Identifier might be part of a last-hop ND/ARP
cache lookup, that would not conflict with my original definition
above.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Mar 2007 08:57:53 -0500

On  2 Mar 2007, at 03:55, Pekka Nikander wrote:
>>           (i.e. below the socket API) but above the routing part  
>> of the
> Of these, the middle one (B) is closest to the traditional use of  
> the term [Chiappa].

I think the term originally comes from JNC.  I first heard it from him
in person.  To be honest, I don't think that either A or C strictly
comply with his definition.

And I don't think that having a Locator/Identifier split is a
necessity to address the issues on this list.  There are a continuum
of approaches that might be useful to consider.  It would actually
HELP the discussion -- and likely help some of the non-ID/Locator
Split proposals if we did not mis-use JNC's original (clearer)
terminology, IMHO.  Some folks seem to think that an idea won't
be seriously entertained unless it is "called" an ID/Locator split.
I think it would be helpful if folks believed that all serious
proposals would be considered, regardless of what technical approach
the proposal undertook (and regardless of what class of approach
it happens to fall into).

:-)

> And there, only some of the proposed solutions, like HIP and SHIM6,  
> really match with the original idea.  At least those that do match  
> seem to comply with your definition, but perhaps also others.

I would agree that HIP complies.  I am doubtful about SHIM6,
since one has a single namespace that is overloaded for both
routing and identity.  SHIM6 seems to be "NAT inside the host"
-- again that's not necessarily bad, just trying to be a clear
description of the proposal.

Cheers,

Ran

PS:  You get bonus points for citing JNC's online paper. :-)

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Mar 2007 09:01:36 -0500

On  2 Mar 2007, at 03:59, Brian E Carpenter wrote:
> considered.

Agreed.

> What we have in reality today are context-
> management.

Agreed.

> The question really is whether we embrace

I don't think LISP does.  As near as I can tell,
LISP separates the routing space into 2 distinct
pieces -- so to me LISP looks like a "Multiple Locator"
solution rather than a "Identifier/Locator Split".

In particular, with LISP the transport session state
still includes location information (albeit not all
of the location information), which seems to disqualify
it from the "ID/Locator Split" category.

As I've said in other notes, I don't think that the solution
necessarily requires a strict "ID/Locator Split".  I do
think that clear conversation is assisted by being crisp
and clear in how one describes various proposals' architectural
approach.

Thanks,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Mar 2007 16:28:33 +0100

We agree completely.

     Brian

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 2 Mar 2007 17:27:38 +0200

>>>           layer, mainly TCP and UDP.
>>>
>>>           IP layer.
>>>           IP layer.
> I think the term originally comes from JNC.  I first heard it from  
> him in person.  To be honest, I don't think that either A or C  
> strictly comply with his definition.

I agree.  I think this all boils down to the difference between  
"separation" vs. "split", as Brian pointed out.  I plead guilty to  
carelessness in my use of terms.

> It would actually HELP the discussion -- and likely help some of  
> the non-ID/Locator Split proposals -- if we did not mis-use JNC's  
> original (clearer) terminology, IMHO.

I agree.

The question remains how should we define id/loc *separation* [Re:  
Brian's message and your reply to that.]

>> And there, only some of the proposed solutions, like HIP and  
>> SHIM6, really match with the original idea.  At least those that  
>> do match seem to comply with your definition, but perhaps also  
>> others.
>
> I would agree that HIP complies.  I am doubtful about SHIM6, since  
> one has a single namespace that is overloaded for both routing and  
> identity.  SHIM6 seems to be "NAT inside the host" -- again that's  
> not necessarily bad, just trying to be a clear description of the  
> proposal.

Oh, I'd agree with you if I were to stuck to the current SHIM6  
specs.  But, perhaps unfortunately, I tend to think about SHIM6 in  
broader terms than the WG appears to.  Architecturally, I think it  
has potential to much more than what the WG charter or the current  
protocols really make possible.

--Pekka Nikander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 Mar 2007 15:56:16 -0500

Reading the various notes, and trying to state what the distinction I 
have understood is, I end up with:

One value is globally routable.
The other value is globally unique and is used by the host stack to 
identify itself / its communicating partner.  It is not globally routable.

Whether that is a "split" a "separation" or something else probably 
depends upon how it is done.
It certainly gets harder to explain when for good (mostly evolution) 
reasons we use the same structure of bits to fulfill both functions.
It gets really confused when as further transition we actually use 
globally routable bit strings for the identifier.
At that point, I do have to agree that we don't have much of a 
"split" any more. (Of course, the agreement of an approach with a 
specific word is NOT the condition for it being or not being useful 
to consider.)

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Mar 2007 14:26:36 -0800

> It certainly gets harder to explain when for good (mostly  
> evolution) reasons we use the same structure of bits to fulfill  
> both functions.

Would you say if IDs were from PI space and not injected into the  
routing system, we then have a true split?

Dino

P.S. Modulo site-based routing on the ID.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 Mar 2007 17:35:01 -0500

>routing system, we then have a true split?

My personal take is that the example you reference is a "true split" 
in that the ID. Since it (and any meaningful prefix of it) is not 
injected in the global routing table, it is not globally routable.  I 
don't think that the fact that in some conceivable alternate universe 
the ID could have been routable makes it not an ID.  Even if the 
alternate universe is one we have all lived in before this gets done right

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 Mar 2007 17:59:41 -0500

(Spenser noted that I got the words twisted around.)
My point was that the fact that it could have been injected (into the 
global table) does NOT turn an ID into a LOC.  Injecting it would 
turn it into a LOC.

Joel

At 05:35 PM 3/2/2007, Joel M. Halpern wrote:
>injected in the global routing table, it is not globally 
>routable.  I don't think that the fact that in some conceivable 
>alternate universe the ID could have been routable makes it not an 
>ID.  Even if the alternate universe is one we have all lived in 
>before this gets done right
>
>
>>Dino
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Mar 2007 22:28:55 +0100

El 02/03/2007, a las 14:57, RJ Atkinson escribió:
>  SHIM6 seems to be "NAT inside the host"
>

this is not the case because shim6 restores the original addresses 
before delivering the packet to the transport layer (which NAT does 
not)

Regards, marcelo

---

From: JFC Morfin <[email-masked]>
Date: Sun, 04 Mar 2007 05:38:52 +0100

Dear Joel,
your clear approach helps to make a complete synthesis.

At 21:56 02/03/2007, Joel M. Halpern wrote:
>Reading the various notes, and trying to state what the distinction 
>I have understood is, I end up with:
>

I add:
One value being structured to globally identify the kind of function. 
(currently: a port)
One value being structured to globally define the same virtual 
indexing for that function (currently: IPv6: Interface ID).

>depends upon how it is done.

Agreed. It looks like a progressive understanding from a default 
situation at the location.
1. there is the separation of the kind of targeted function through 
the port number.
2. there is the separation of the virtual address used by the 
function. Ex: http.1.1 where names are used for virtual hosts..

>reasons we use the same structure of bits to fulfill both functions.

LISP does not use the same structure (an IPv4 encapsulation can 
support an IPv6 datagram). It uses the same kind of numeric 
containers. I proposed to use the IPv6 header to support that 4 
addressing orthogonal elements in splitting the IPv6 address. This 
required an IPv6 /3 block to be dedicated to that approach to keep it clean.

At the expense of more space, LISP permits to pile these 4 
informations, and any number of their extensions.
- location and identification can use 4 (IPv4) or 16 (IPv6) bytes container,
- virtual addressing a DNS label or a 4 to 16 bytes container, with 
the possibility of unlimited sub-virtual addressing with DNS labels 
or 4 to 16 bytes containers
- function identification through a 2 bytes port or an unlimited pile 
of 4 to 16 bytes containers.

The information is not _split_, it is orderly _concatenated_.

However this requires a way to know the information to pile-in and 
when to peel it off.

A simple rule could be to remove the top-of-the-pile-header and to 
put it at the end of the datagram, when it is the number of the 
reached "node" (including hosts, functions, and virtual index).

- we then actually have a mix of addressing and a routing 
information. Each note knows it must forward the datagram towards the 
new top-of-the-pile node fixed for the network path, mobile (actual 
or possible mobility) for the host identification, virtual for the 
application indexing, and  port for the function if supported through 
a 4 to 16 byte number). It can be the next neighbor or a very remote 
one. If something fails the packet can then come backward (putting 
the last the end information on the top of the header pile) until it 
can get forward again.

This means that the "end to virtual end itinerary" has to be piled-up 
by the originating end. This is the function I call supervision which 
consists in knowing some of the corresponding elements on the nodes 
of the path and to pile the LISP header accordingly.

>globally routable bit strings for the identifier.

The considered information is only the indicator of the next node to 
reach. That indicator can be local, from any numbering system, or 
global the direct neighbor or a remote node. There is no impact on 
the LISP header as long as there is no conflict of indicator at any given node.

If we are in a multi-topology environment there may be different ways 
to reach another node at different costs or classes of services. I 
suggest that it takes the least costing permitted path, or only the 
virtual adjencies of its own class of service.

>specific word is NOT the condition for it being or not being useful 

We have a concatenation of location, identification, function, 
application index indicators and of their extensions.

>>context dependency (which is what a true split would

See above. We are in a "protocol on a dumb wire" environment. The 
node to node chaining only considers indicators claimed by its 
neighbors. As long as there is no conflict they can be global or contextual.

This, however, requires an important addition: supervisors must 
receive the information of the nodes, or through a predetermined 
topology description. When a nodes transmits its information one 
knows the information and that the node is LISP compatible. When a 
node does not transmit its information one knows that it is not LISP 
interoperable.

IMHO, the LISP operating modules could be installed as OPES 
transmitting their data under OCP. It could then be assisted by OCP 
related call-out routing/access/reporting hosts forming a routing 
services network overlay [rfc 4037]. Routers could be operated 
through OPESed files.

jfc