Subject: [RRG] Should the identifier be used as local locator

From: Xu Xiaohu <[email-masked]>
Date: Fri, 04 Jul 2008 11:53:32 +0800

> No, no, a thousand times no. My point was NOT that you can ignore line
> 1 until condition X. My point was that you can remove line 1 from the
> envelope -completely- and the postal routing system still delivers the
> letter correctly.
> Drawing the analogy back to it's origin, my point was that in a
> clean-slate system, node identity doesn't belong at layer 3. It
> belongs above layer 3, either in a layer 3b or in layer 4. ONLY
> network location belongs in layer 3. And network location is a
> fundamentally ephemeral thing; it changes constantly with your node's
> geographical movement and with the the ups and downs of the network's
> interconnections.

As for a clear-slate system, should the identifier be used for local
locator?

Take GSE/ILNP as an example, the so-called identifier is still used as
routing hint in the site networks, you can say this identifier is used as
local locator, or you can say it's routing on identifier. In relative fixed
networks, the identifier can still be aggregated in the local routing table.
However, in a relative mobile networks, the routing is based on the flat
identifier (just like current Ethernet switching). The scalability of the
routing on flat identifier depends on the scale of the site networks.

>From this above point of view, the line 1 "name" from the envelope can not
be removed. My doubt is whether it is preferable for the identifier to play
the role of locator in the site networks.

Xiaohu XU

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Jul 2008 06:53:55 -0400

Earlier Xu XiaoHu wrote:
% Take GSE/ILNP as an example, the so-called identifier
% is still used as routing hint in the site networks, ...

Hi,

The note referenced above does not correctly describe ILNP.
I'll leave it to others as to whether it correctly describes GSE.

- ILNP does NOT ever use the Identifier for routing/forwarding packets.
- The Identifier is only used for identity purposes in ILNP.

- ILNP *only* uses the Locator to route/forward packets,
   including when mobility or multi-homing are part of the deployment.

In any event, ILNP is different from GSE.

Cheers,

Ran

---

From: Scott Brim <[email-masked]>
Date: Fri, 04 Jul 2008 07:34:39 -0400

>   including when mobility or multi-homing are part of the deployment.

Ran, after the Locator guides the packet to a subnetwork, does the 
packet ever go through another IP router on its way to the destination 
endpoint?  If so, how is it known what the next hop should be to forward 
the packet?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Jul 2008 09:06:04 +1200

On 2008-07-04 15:53, Xu Xiaohu wrote:
...
> As for a clear-slate system, should the identifier be used for local

Not essentially, but you can't invent any solution that doesn't
include a final step of finding the local locator that corresponds
to the identifier. In other words there must be a mapping function
at the local level.

I think that we all have our brains distorted by the rigidity
of the OSI model with its strictly numbered layers, where in effect
a layer N locator is (mis)treated as an identifier by layer N+1.
We've been brainwashed into believing that there is something
fundamental in having only two layers between physical and
transport. What's interesting about LISP is that it inserts an
extra layer there, which I believe should be a recursive step.
At each recursion you need an identifier-to-locator mapping.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Fri, 04 Jul 2008 18:01:50 -0400

> At each recursion you need an identifier-to-locator mapping.

NB the difference between "layer" versus "layer network".  See the 
appendix of 
<http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.2611-200612-I!!PDF-E&type=items>

---

From: "Tony Li" <[email-masked]>
Date: Fri, 4 Jul 2008 18:10:28 -0700

|> Earlier Xu XiaoHu wrote:
|> % Take GSE/ILNP as an example, the so-called identifier
|> % is still used as routing hint in the site networks, ...
|> 
|> The note referenced above does not correctly describe ILNP.
|> I'll leave it to others as to whether it correctly describes GSE.
|> 
|> - ILNP does NOT ever use the Identifier for 
|routing/forwarding packets.
|> - The Identifier is only used for identity purposes in ILNP.
|> 
|> - ILNP *only* uses the Locator to route/forward packets,
|>   including when mobility or multi-homing are part of the deployment.
|
|Ran, after the Locator guides the packet to a subnetwork, does the 
|packet ever go through another IP router on its way to the destination 
|endpoint?  If so, how is it known what the next hop should be 
|to forward 
|the packet?

And more specifically, how does the last hop router determine the MAC
address of the final destination?  The MAC address itself is a flat
identifier (and locator on the last hop) that can be embedded in the
endpoint identifier, or the endpoint identifier can be used for a lookup to
determine the MAC address.  In either case, the endpoint identifier ends up
being used for a local routing decision.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Fri, 4 Jul 2008 21:38:42 -0400

> being used for a local routing decision.

The MAC address is strictly a locater. Depending on which interface
you approach the host from it usually has a different MAC addresses.
The routing system doesn't care. On the last hop, it uses the layer 3
locater as a key to find a layer-2 locater.

-Bill

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 05 Jul 2008 09:56:11 +0800

> being used for a local routing decision.

Hi Tony,

Let me say that in other way, the MAC address, as locator on the last hop,
can be carried together with the endpoint identifier in the packets, or the
endpoint identifier can be used for a lookup to determine the MAC address.
The reason is that embedding the MAC address in the endpoint identifier is
not a good idea if we take the multi-interface hosts and the portability
requirement of identifier into account. Of course, there is a third way,
that is the last hop router just uses the identifier (IP address) as local
locator with the MAC address set to FF-FF-FF-FF-FF-FF, which just causes a
small-scale broadcast storm in the Ethernet network of the last hop. IMO,
the importance of the MAC address in the last hop is not as important as
that in the first and the middle hops.

Xiaohu XU

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jul 2008 14:04:15 +1200

> locater as a key to find a layer-2 locater.

The way I read the Ethernet specification (or Token Ring or FDDI for
that matter), the MAC address is strictly an identifier - it's when
a station sees its own MAC address in a frame that it knows the frame
is for itself.

But you're correct too. Whether a bit string is a locator or an
identifier depends entirely on context. (That's why I've objected to
EIDs in LISP being called EIDs from the start - once they hit
the site network, they become locators instantaneously; they
are only identifiers in the global context.)

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 8 Jul 2008 01:02:28 -0700

Brian,
 
|The way I read the Ethernet specification (or Token Ring or FDDI for
|that matter), the MAC address is strictly an identifier - it's when
|a station sees its own MAC address in a frame that it knows the frame
|is for itself.

In any switched network, the MAC address is used for a lookup in the bridge
table to determine destination location.  Thus, it clearly also has some
locator functionality.

|But you're correct too. Whether a bit string is a locator or an
|identifier depends entirely on context. (That's why I've objected to
|EIDs in LISP being called EIDs from the start - once they hit
|the site network, they become locators instantaneously; they
|are only identifiers in the global context.)

Indeed.  It's pretty clear that we can still have semantic cleanliness tho,
as we can isolate a particular bit string as having L3 identifier semantics
(coupled with L2 locator and L2 identifier semantics) and distinct from L3
locator semantics.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 8 Jul 2008 08:32:06 -0400

Brian,

You're right. I had completely forgotten that Ethernet was originally
a broadcast network. Every station saw every packet. The card's job
was to filter the packets so that the CPU only saw the ones that bore
its ID or another ID of interest such as the all-stations ID.

Do they even make gig-e and ten-gig-e hubs or has that been completely
abandoned in favor of switches? The coaxial bus is, of course, long
gone in favor of hub-and-spoke technologies like twisted pair and
fiber.

At any rate, with the exception of -optional- stateless
autoconfiguration in IPv6, the layer 2 address is not used as an
identifier by anything in layer-3 or above. As a result, layer 2 -can-
use it's address strictly as a locater and change it willy-nilly if it
wishes to, without disturbing anything above it.

Regards,
Bill Herrin

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 8 Jul 2008 09:17:06 -0400

Earlier, Scott Brim wrote:
% after the Locator guides the packet to a subnetwork,
% does the packet ever go through another IP router
% on its way to the destination endpoint?

No.

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 8 Jul 2008 08:28:34 -0700

> I'll leave it to others as to whether it correctly describes GSE.

I'm afraid that XiaoHu's statement is *not* a correct description of  
GSE either.

In GSE, the IPv6 address is divided into 3 parts:

     +-------------------------+
     |   RG   | STP|    ESD    |
     +--------+----+-----------+

RG is for global routing, STP (site topology partition) is used for  
local routing (inside a site).  ESD, End System Designator, is assumed  
to be a globally unique node identifier, and is not used as routing  
hint in the site.

BTW here is what I got from other msgs on this thread, that is MAC  
address is not an ideal node ID in the strict sense, as it is  
associated with a specific interface, while hosts are increasingly  
multihomed today.

There are really two issues:
1/ the need for a unique node ID
2/ an engineering judgment call of whether one could borrow MAC address
    to serve the above purpose.
    (this is similar to the existing TCP design of borrowing IP
     address as part of TCP's connection ID)

2/ represents an engineering tradeoff because the borrowing saves the  
trouble of managing another new ID space.

Lixia

---

From: "Tony Li" <[email-masked]>
Date: Tue, 8 Jul 2008 09:59:35 -0700

|2/ an engineering judgment call of whether one could borrow MAC address
|    to serve the above purpose.
|    (this is similar to the existing TCP design of borrowing IP
|     address as part of TCP's connection ID)
|
|2/ represents an engineering tradeoff because the borrowing saves the  
|trouble of managing another new ID space.

2/ also creates a significant security issue.  If a MAC address is visible
outside of the local subnet, then it implies that someone can track a host
as it migrates across the Internet.  That's been widely discussed during the
first iteration of GSE and pretty generally viewed as a Bad Idea.  At the
very least, there needs to be a mechanism to escape from the MAC address and
jump to a separately assigned space.  

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 8 Jul 2008 10:25:42 -0700

> jump to a separately assigned space.

the above is just one of the factors of why I call 2/ an engineering  
judgment call: it gives some saving, but definitely has associated  
cost with doing so.

If one has a clear description of all the desired properties of a true  
node ID, then one can see more clearly what are the costs of this  
borrowing idea.

Lixia

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 09 Jul 2008 13:45:38 +0800

> In GSE, the IPv6 address is divided into 3 parts:

To some extent, the purpose of the STP is to make the routing on flat
identifier scalable. However, ESD is still used as routing hint, just in a
smaller scale of network.

Xiaohu XU

---

From: Christian Vogt <[email-masked]>
Date: Wed, 9 Jul 2008 18:07:39 +0300

> 2/ represents an engineering tradeoff because the borrowing saves  
> the trouble of managing another new ID space.

Right.  In addition, and perhaps more importantly, borrowing also
saves the managing and securing of a mapping between the lower-layer
ID and the upper-layer ID.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 9 Jul 2008 18:27:51 +0300

Brian and Tony -

>> Brian wrote:
>> EIDs in LISP being called EIDs from the start - once they hit the  
>> site
>> network, they become locators instantaneously; they are only
>> identifiers in the global context.)
>
> Tony wrote:
>
> Indeed.  It's pretty clear that we can still have semantic cleanliness
> tho, as we can isolate a particular bit string as having L3 identifier
> semantics (coupled with L2 locator and L2 identifier semantics) and
> distinct from L3 locator semantics.

You define the terms "identifier" and "locator" based on whether you
can route on them.  This is why an identifier can become a locator, or
vice versa, if you look at it in a different context.

Hitherto, my definition of the terms was independent of whether you
route on them or not:  I thought of a "locator" as a place in network
topology, and of an "identifier" as a name for a host (or for some
entity on the host such as an interface card or an application
session).  In other words, given an attachment point to the network, a
the locator described something on the network side of it, and the
identifier described something on the host side of it.  With this
definition, whether a name is an identifier or a locator does not
change with the context.

Decoupling what a name describes from what you can do with the name is
sensible IMHO because only the latter depends on the context:  Within
small scope, routing based on identifiers may certainly be feasible. A
good example is the bridge you mentioned, which maps MAC addresses
(which are identifiers according to my definition) onto "next-hops".
For global scope, routing based on identifiers fails due to
scalability issues because identifiers cannot facilitate aggregation
of next-hop information in routers or switches due to host mobility
and multi-homing.  Locators do facilitate such aggregation, provided
they have a suitable structure, which is why they are more appropriate
for global-scope routing.

Anyway, I have no problems changing my definition if the research
group wants to use a different one.  Let's just agree on one of them.

- Christian

---

From: <[email-masked]>
Date: Wed, 9 Jul 2008 17:38:28 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Christian Vogt
> Sent: 09 July 2008 16:08
> To: Lixia Zhang
> Cc: rrg
> Subject: [RRG] Re: Should the identifier be used as local locator
> 
> Right.  In addition, and perhaps more importantly, borrowing 
> also saves the managing and securing of a mapping between the 
> lower-layer ID and the upper-layer ID.
> 
> - Christian
> 

I am not sure I follow this bit - if I am a multi-homed terminal there
is not a simple 1-1 mapping

Louise

---

From: Christian Vogt <[email-masked]>
Date: Wed, 9 Jul 2008 20:03:43 +0300

> I am not sure I follow this bit - if I am a multi-homed terminal
> there is not a simple 1-1 mapping

Louise,

you are absolutely right.  A multi-homed host would get multiple
"host IDs", if we re-used the MAC address as a host ID.  This is
one of the disadvantages of such re-use.

Note that my comment didn't mean that I would favor such re-use.
Was just an observation.

- Christian

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 9 Jul 2008 13:32:25 -0400

Earlier, Christian Vogt wrote:
% you are absolutely right.  A multi-homed host would
% get multiple "host IDs", if we re-used the MAC address
% as a host ID.  This is one of the disadvantages of such re-use.

The above assumption is not necessarily the case.

For example, one easily could permit a MAC-derived
Identifier [ ID := f(any MAC on the node)] to be
a "Node Identifier" that would be interface independent.
[1]

ILNP does precisely that; this approach works just fine.

Cheers,

Ran

[1] For those who'd prefer not to use a MAC-derived ID,
that is also fine, just use the EUI-64 syntax, set the
Scope bit to "local", the Multicast/Unicast bit to "unicast"
since this is for a single node's ID, and put any 62 bits
that you choose into the EUI-64.  That also works fine,
though one should then be very sure to use IPv6 DAD or
Gratuitous ARP in case some other node happened to choose
the same other 62 bits.

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Jul 2008 13:46:17 -0400 (EDT)

> From: Christian Vogt <[email-masked]>

    > borrowing also saves the managing and securing of a mapping between the

Yes, but it also makes the whole thing less flexible and more brittle (as we
have found, to our cost), by removing that extra layer of binding
(indirection). Remember Lampson's famous dictum about 'most problems in
computer science can be solved with another level of indirection'.

In addition, it means having one entity (the transport layer) know about the
internal data of another entity (the internetworking layer), which is another
thing that is frowned on today (most programming languages now try to hide
internal data).

TANSTAAFL.

	Noel

---

From: Christian Vogt <[email-masked]>
Date: Wed, 9 Jul 2008 21:21:24 +0300

> Yes, but it also makes the whole thing less flexible and more brittle
> (as we have found, to our cost), by removing that extra layer of
> binding (indirection). Remember Lampson's famous dictum about 'most
> problems in computer science can be solved with another level of
> indirection'.

But doesn't the dictum continue:  "...but usually this will create
another problem?"  ;-)

Anyway, I completely agree with you that the advantages of having
an ID/locator indirection more than outweigh the costs.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 9 Jul 2008 21:23:00 +0300

> a "Node Identifier" that would be interface independent.

Ran,

in this case, you are not re-using the MAC address as a node ID; you
are generating a new node ID.  The purpose of the MAC address being
part of the function is simply to make this node ID globally unique.

So what you are proposing above is similar to what happens today in
Stateless Address Autoconfiguration:  an IP address is built based on
a MAC address.  What Louise and I were talking about is similar to
what happens today between TCP and IP:  TCP re-uses IP addresses as
node IDs.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Wed, 9 Jul 2008 14:44:42 -0400

> vice versa, if you look at it in a different context.

Right.  The definition should not be based on whether you can route on
them, because you always can.  It should be based on whether the value
is independent of location when a particular approach is put in
operation.

> group wants to use a different one.  Let's just agree on one of them.

You are asking a lot!

---

From: Christian Vogt <[email-masked]>
Date: Wed, 9 Jul 2008 21:53:53 +0300

> is independent of location when a particular approach is put in

Yep.  And I like this wording.

- Christian