Subject: Re: [rrg] Next topic: properties of identifiers

From: [email-masked] (Noel Chiappa)
Date: Mon, 27 Jul 2009 09:20:48 -0400 (EDT)

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

    > I agree that it would be useful to have locators which route to a given
    > host -- or better: to a given stack, since this is the entity through
    > which one must pass to reach a given service or session.

I've always had this degree of ambivalent feelings about this concept, that
locators can identify 'things' inside a host.

I've always felt like 'the job of the routing is to deliver the packets to
the right network interface, and once that's done, its job is over'. From
then on, it should be the next layer up's job to do demultiplexing - perhaps
with what I have called a Endpoint Selectors (ESEL - a short identifier, with
scope limited to a single interface, which can get a packet to whichever of
several endpoints is sharing a particular interface).

I guess the best counter-argument I've heard is that if you have a 'virtual
machine' setup, each virtual machine thinks it has a virtual network
interface, and that virtual interface needs its interface name. (You can just
do it with ESELs, since each VM would think it's managing the ESEL namespace,
and you could get clashes.) So that would mean that inside the VM system,
packets would have to be 'routed' to the correct VM.

Do note that if we want to support that model (locators for VIs on VMs), that
probably does imply variable length locators... (ducks :-)

	Noel

PS: Nobody has any reaction to my comments about models for connectivity?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jul 2009 03:45:18 -0400

There are at least two ways of looking at the problem of getting the 
packet to the right stack.
And, to put the answer before the quesiton, I think the level of 
distinction is irrelevant at this stage of the game.

Let us presume that we started with an identifier for something.  And we 
are going to end up with enough information to delvier the packet.
That information has to include
enough content that the network can delvier the packet to the right 
network interface
enough content that the packet will get from the network interface to 
the right processing stack.

Now, whether those two steps are represented by two pieces of 
information (a locator plus an ESEL),
one piece of information (a locator that is usable by machine packet 
dispatch logic)
or three pieces of information (a subnet locator, an identifier usable 
for packet delivery in the subnet, and a potentially separate field 
usable for intra-machine handling)
Or a variation on three where the identifier covers the last two pieces, 
and we are back to two,
and whether these pieces of information are all part of one fixed length 
field, one variable length field, or separate explicit fields,

we still have to get the packet there.
Different solutions will parse this differently.
I think what is important for the solutions to be clear about what the 
information names / locates, and in what scope.
I do not think it is important that we mandate a very specific meaning 
for the term across those solutions.  I don't think this particular 
ambiguity introduces major confusion, as long as we make sure we know 
what the solution we are examining does, and how it enables this.

(This relates to my hypothesis that we need stack identifiers in the 
abstract, but not all solutions need to have those identifiers exchanged 
on the wire.)

Yours,
Joel

Noel Chiappa wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>