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

From: <[email-masked]>
Date: Wed, 1 Jul 2009 09:05:01 +0100

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: 30 June 2009 20:51
> To: Krug,AL,Louise,CXR9 R
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rrg] Next topic: properties of identifiers
> 
> > Is host identification most useful for fault finding?
> 
> 
> Louise -
> 
> Absolutely.  In fact, there is a richness of purposes for 
> which one may need identifiers.  What I claim is that most of 
> those purposes are application-specific and not essential to 
> an Internet architecture.  For example, fault finding is the 
> purpose of a debugging application.
> 
> An Internet architecture must be versatile enough to enable 
> applications to use their own identifiers.  But to do this, 
> the Internet architecture itself must incorporate identifiers 
> for only two purposes:  to identify a peer service for 
> contact establishment, and to identify a session instantiated 
> during contact establishment.  On top of that, applications 
> can do what they want, such as providing a means to identify 
> hosts for fault finding.  Does this make sense?
> 
> - Christian
> 
> 
> 
It makes sense in the abstract, but I am still mulling the question "if
a lot of applications would need something such as a host ID, and the
network does not provide it will we end up with a lot of different ways
of providing it, and possibly some very nasty ways (like IP addresses
got overused). I guess then you might say that you have the core
architecture and a set of extras that need to be standardised but you
should not expect them to be gloablly available?

Do you think the session need to have a globally unique identifier or
locally agreed between the endpoints during the contact establishment?

Louise

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Jul 2009 10:03:19 -0400

While there is an architectural argument that we should have nothing 
more than is absolutely necessary in the architecture, taken too far 
this view encourages entangling components and misusing information. 
(~We could use that piece over there, instead of having the right piece 
with the right meaning, sicne it would save a part.~)

While it is sometimes (particularly for management purposes) useful to 
be able to name a physical node, when I look at this the piece I tend to 
want to name is the communicating entity.  Having a name for this thing 
is useful for session establishment, referral, and security purposes. 
This is distinct from, but may be a component of, the identifier used 
for a specific communication session.  (Some folks like to simply mint 
session IDs in a way that is sufficiently unique, some like to 
implicitly tie session IDs to the entity IDs, and some folks use designs 
where the tie-in is explicit.)

The reason I started with the comment about necessity is taht some folks 
argue that a communicating entity ID is not necessary as it can be 
represented by the collected network layer locators.  (And that once one 
has established communication using any locators, the protocol can 
exchange the rest.)  This is true as far as it goes.
It seems to me however that it is useful to be able to explicitly tell 
which locators go with the same communicating entity, as distinct from 
the larger set of locators which might go with the same service 
(whatever that means.)

To save myself typing, and because it tends to be similar to what other 
folks have meant when they use the term, I tend to prefer to think of 
this ID as a stack-ID.  And yes, I know that is vague.  Exactly what is 
the stack.  Does it include TCP, UDP, SCTP, and DCCP, or is it just one 
of them?  Etc.
I have considered writing a draft trying to clarify this, but the 
question of identifiers has not seemed to be the actual top problem, so 
I have not seen enough reason to do so.

Yours,
Joel

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

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 16:23:18 -0700

On Jul 1, 2009, Louise Burness wrote:

> got overused). [...]

Very likely we will.  But we may in any case, even if there was a
default means to identify a host.

Applications often have their very specific requirements, which makes it
hard to provide a default that is sufficient for all applications.  The
consequence is that applications incorporate their own mechanisms.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 16:58:12 -0700

On Jul 1, 2009, Joel M. Halpern wrote:

> the larger set of locators which might go with the same service [...]

Joel -

Yes, we absolutely need this.  But why does this imply the need for a
host or stack identifier?  Session identifiers already map to the set of
locators that go to the same communicating entity.  This is why we need
to distinguish them from service identifiers, which in turn may map to
locators of different communicating entities.

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Jul 2009 22:36:44 -0400

The reason this (naming the set of locators that lead to the same 
entity) leads to a stack ID (or node, host, something) is that I want 
that collective property available before I start communicating.
Referrals are the easy case.  I am trying to refer someone to a specific 
entity.  They do not have a session with that entity.  So a session ID 
is clearly totally useless for a referral.

I believe that similar constraints apply at the time of initial 
communication establishment, in that there is a semantic difference 
between using multiple locators for a target to establish communication 
and trying to establish communicaiton with multiple "equivalent but 
distinct" targets.  I consider it helpful to udnerstand that distinction.

It seems clear to me that one of the important properties of a 
communication session is the pair (or worse, if one likes multiparty 
sessions) of entities that are talking.  But session identification is 
much more specific than just naming the communicating parties, or even 
the available interfaces.  At this stage of the game I do not care 
whether session IDs are minted using the stack IDs, or minted out of 
whole cloth using bilateral state.  Either can work.  I am not arguing 
that session IDs inherently require stack IDs.  They don't.  I am 
arguing that stack IDs are useful separate from session IDs.

Yours,
Joel

---

From: Christian Vogt <[email-masked]>
Date: Sun, 5 Jul 2009 15:15:16 -0700

Joel -

You are saying that there ought to be a third identifier type, besides
service and session identifiers, which is used to map a service of
interest to a particular stack on which an instance of this service is
running.  This would enable a host to refer a third party to this
particular service instance.

I agree with you that such "service instance referrals" must be
possible.  Where our opinions diverge is on whether we need a third
identifier type for it.

In my opinion, we don't need a third identifier type for service
instance referrals.  The service identifiers, which we need in any case,
are already sufficient for this purpose:  At the point where an
application wants to refer a third party to a particular service
instance, it is defining a new service that only said service instance
can provide.  This new service can naturally have its own service
identifier.  This service identifier, in turn, will map to the locators
of only the stack on which the referenced service instance in running.

Oh, and regarding session identifiers:  Those are irrelevant for all of
the above. I agree with this. It is the service identifiers that matter.

- Christian

On Jul 3, 2009, Joel M. Halpern wrote:

> Yours, Joel

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 7 Jul 2009 19:40:12 +0300

Joel,

I think you are right here and I got it all wrong when claiming that
host-ID, hereafter stack-ID, should be coupled together with a
session-ID.
Now I agree that they should be separated - when separated only the
server need to have a stack-ID, the client doesn't need to have one.
Then we are close to a HTTP session token solution, aren't we?

http://en.wikipedia.org/wiki/Session_(computer_science)

-- patte

On Sat, Jul 4, 2009 at 5:36 AM, Joel M. Halpern<[email-masked]> wrote:
> The reason this (naming the set of locators that lead to the same entity)
> leads to a stack ID (or node, host, something) is that I want that
> collective property available before I start communicating.
> entity.  They do not have a session with that entity.  So a session ID is
> clearly totally useless for a referral.
>
> communication establishment, in that there is a semantic difference between
> using multiple locators for a target to establish communication and trying
> to establish communicaiton with multiple "equivalent but distinct" targets.
>  I consider it helpful to udnerstand that distinction.
>
> It seems clear to me that one of the important properties of a communication
> session is the pair (or worse, if one likes multiparty sessions) of entities
> that are talking.  But session identification is much more specific than
> just naming the communicating parties, or even the available interfaces.  At
> this stage of the game I do not care whether session IDs are minted using
> the stack IDs, or minted out of whole cloth using bilateral state.  Either
> can work.  I am not arguing that session IDs inherently require stack IDs.
>  They don't.  I am arguing that stack IDs are useful separate from session
> IDs.
>
> Yours,
> Joel
>
> Christian Vogt wrote:
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 07 Jul 2009 15:55:10 -0400

It is probably true that for a client-server protocol, the client does 
not need to have a stack-ID.

 From an architectural perspective, I tend to see that any machine may 
sometimes be a server, and therefore I prefer to approach things by 
giving every stack an ID.

Thank you,
Joel

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 15 Jul 2009 10:42:55 -0700

Apology for this belated response.  In an effort to get ready for our  
next meeting, I've been going through the mail again....

> should not expect them to be gloablly available?

we are facing complex design issues.  I feel that one way to make us  
see the picture clearly is to clarify any vague notion, so here is  
one: the above says

    "if a lot of applications would need something such as
     a host ID, and the network does not provide it will we
     end up with a lot of different ways of providing it..."

What is this "network" referred to in the above?
The data delivery network?
or the overall Internet architecture?

I assume the answer is the latter?

> locally agreed between the endpoints during the contact establishment?

I've seen multiple mentioning about "sessions", but yet to see a clear  
definition of it.

Lixia

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Jul 2009 13:52:43 -0400

> I've seen multiple mentioning about "sessions", but yet to see a clear

Lixia,

First informally: You know what it is.  Why do you need it rigorously
defined?

Attempting formality, something like: An exchange of messages between
two or more high level (i.e. top of stack, ultimate consumer of packet)
entities that involves synchronized state information.  A session is
distinguishable from a transaction (no synchronized state) and a one-way
stream (not an "exchange").

Scott

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 15 Jul 2009 10:52:49 -0700

> locators of different communicating entities.

the above comment seems brining more implicit assumptions regarding  
"session identifiers", e.g. "Session identifiers already map to the  
set of locators that go to the same communicating entity..."

as I mentioned in the prev msg, I've yet to see a simple and clear  
definition of "Session" first.  As Joel questioned in next msg,

    I am trying to refer someone to a specific entity. They
    do not have a session with that entity.  So a session ID
    is clearly totally useless for a referral.

Maybe I would not go as far as saying session ID is totally useless  
because I do not even know what it identifies:)

Lixia

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Jul 2009 14:05:51 -0400

Lixia Zhang allegedly wrote on 07/15/2009 1:52 PM:
> "session identifiers", e.g. "Session identifiers already map to the set
> of locators that go to the same communicating entity..."

This mapping of session identifier -> locators is transient and not for
general use.  That is, you couldn't put a session identifier in DNS and
expect to use it as a "where is this node" locator.  However, while a
session exists, participants in that session can use a session
identifier internally.

> definition of "Session" first.  As Joel questioned in next msg,

See previous reply.

>    is clearly totally useless for a referral.

That's a different purpose and the statement is correct.  A session ID
is meaningless if there is no session.

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 17 Jul 2009 23:43:33 -0700

> First informally: You know what it is.  Why do you need it rigorously

1/ I honestly do not know.  Citing Joel's comment here: does a session  
mean the combination of two ends?  do we care unicast/multicast  
sessions?  how lasting/transient is a session (hence the life time of  
its ID)?  etc etc.

2/ more fundamentally: when I program, maybe I could say "I know what  
each part does" and dont define rigorous interface (but still, that is  
NOT good practice)
But here we are talking about a big architecture. As I've seen, even a  
term with a definition often gets different interpretation by  
different people, let alone a term without a clear definition!

But I would like to step up a level and repeat what I said earlier:
1/ I do not think it is in our charter to define how many identifiers  
we ought to have, or what they ought to be.
2/ Our job is to figureout scalable routing architecture.
3/ We need to have a good understanding about the interplay between  
addresses and identifiers, no less and also no more.

Related to the last point: I had planned to get a short draft out on  
the terminology discussion we had at SF IETF before the draft 00  
deadline but you all know by now that I did not get there.  I am still  
trying to finish it in coming days, to get it ready for discussion at  
Stockholm.

Lixia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 18 Jul 2009 10:23:13 -0400

I think that this is at least misleading.
 From a pure routing architecture perspective, the statement that IPv6 
started with (thou shalt always use provider address) is sufficient.
However, once we acknowledge that issues like renumbering and the 
realities of building networks are relevant, we have to look beyond just 
our playpen and pay attention to adjacent activities and our affects on 
them.  Similarly, when evaluating map-and-encaps ideas, we should be 
aware of the interaction of those ideas and other activities like 
multi-path TCP, even though multi-TCP is clearly not "routing".

If we claim to have solved something with too small a focus, we won't 
have anything usable.

Yours,
Joel

Lixia Zhang wrote:
...
> 1/ I do not think it is in our charter to define how many identifiers we 
> ought to have, or what they ought to be.
...

---

From: Luigi Iannone <[email-masked]>
Date: Sat, 18 Jul 2009 16:41:13 +0200

On Jul 18, 2009, at 8:43 , Lixia Zhang wrote:
> 1/ I do not think it is in our charter to define how many  
> identifiers we ought to have, or what they ought to be.

I am confused here. Isn't 1 a part 2? i.e., by defining a new routing  
architecture shall we not define exactly what is an identifier  
(including how many different identifiers)?

Luigi

> deadline but you all know by now that I did not get there.  I am  
> still trying to finish it in coming days, to get it ready for  
> discussion at Stockholm.
>
> Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 18 Jul 2009 08:05:03 -0700

On Jul 18, 2009, at 7:41 AM, Luigi Iannone wrote:

> I am confused here. Isn't 1 a part 2? i.e., by defining a new  
> routing architecture shall we not define exactly what is an  
> identifier (including how many different identifiers)?
>
> Luigi

I fully agree with defining exactly what properties an identifier  
ought to have with regard to routing, as we have discussed at SF IETF.

I do not believe this group is the right body to tell how many  
identifiers the applications may ever want. I take the liberty to  
quote a paragraph from a msg Scott Brim sent earlier in reply to  
Christian (July 9, 2009 10:30:45 AM PDT):

    First, let's avoid thinking of the Internet in client/server
    concepts. "Service" has connotations of a destination that is
    frequently accessed, well-known, and perhaps globally addressed.
    We need to leave room for simple personal communications.

We need to leave room for future new applications, which we dont know  
what they may be but we know for sure they will come.

I saw my earlier statement was not exactly clear; I should have said:

    I do not think it is in our charter to define exactly how many
    identifiers all the upper layers ought to have.

> addresses and identifiers, no less and also no more.

does this sound right now?

>> Related to the last point: I had planned to get a short draft out  
>> on the terminology discussion we had at SF IETF before the draft 00

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 18 Jul 2009 08:08:57 -0700

On Jul 18, 2009, at 7:23 AM, Joel M. Halpern wrote:

> From a pure routing architecture perspective, the statement that  
> IPv6 started with (thou shalt always use provider address) is  
> sufficient.
> realities of building networks are relevant, we have to look beyond  
> just our playpen and pay attention to adjacent activities and our  
> affects on them.  Similarly, when evaluating map-and-encaps ideas,  
> we should be aware of the interaction of those ideas and other  
> activities like multi-path TCP, even though multi-TCP is clearly not  
> "routing".

Joel, I fully agree with the above statements (except the one about  
misleading:)

e.g. taking multipath-tcp as an example: I thought this is covered  
under my 3rd statement below:

    We need to have a good understanding about the interplay
    between addresses and identifiers

> If we claim to have solved something with too small a focus, we  
> won't have anything usable.

agree.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 18 Jul 2009 11:15:18 -0400

Fair enough.  If what you intended and what I was trying to ask for are 
similar enough, then at least the two of us (and I think quite a few 
others) are on the same page.
Thanks,
Joel

Lixia Zhang wrote:
>> affects on them.  Similarly, when evaluating map-and-encaps ideas, we 
>> should be aware of the interaction of those ideas and other activities 
>> like multi-path TCP, even though multi-TCP is clearly not "routing".
> 
> e.g. taking multipath-tcp as an example: I thought this is covered under 
> my 3rd statement below:
>

---

From: Luigi Iannone <[email-masked]>
Date: Sat, 18 Jul 2009 17:27:56 +0200

On Jul 18, 2009, at 17:05 , Lixia Zhang wrote:

> We need to leave room for future new applications, which we dont  
> know what they may be but we know for sure they will come.
>

Totally agree.

> does this sound right now?

Yes

thanks

L.

>>> on the terminology discussion we had at SF IETF before the draft  
>>> 00 deadline but you all know by now that I did not get there.  I  
>>> am still trying to finish it in coming days, to get it ready for  
>>> discussion at Stockholm.
>>>
>>> Lixia

---

From: Scott Brim <[email-masked]>
Date: Sat, 18 Jul 2009 12:16:42 -0400

Routing per se only uses locators and forwarding indications, and
doesn't care what properties any identifiers might have (it doesn't use
them). From the point of view of routing and addressing, the motivation
for locator/identifier separation is to REMOVE constraints on routing
architecture, to make it possible to solve the routing architecture
problems (scaling, robustness, adaptability etc.).  The list of RRG
requirements with respect to identifiers is negative, not positive.  For
example, something like: "A locator MUST NOT be constrained to a
long-term association with an object.  Locators name network attachment
points, not endpoint interfaces.".

However, for any routing/addressing/forwarding architecture, RRG should
write up the implications has on identification functions.  In order to
do that, we do need to understand what identification functions are
essential for Internet operations.  We have to be sure we understand the
implications of what we recommend before we can do so responsibly.

I believe we are at the point where we have a good sense of what
identification functions are needed, and now we can keep that list in
our back pocket, as a checklist, and narrow the scope of activity back
down.

Scott

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 21 Jul 2009 09:07:29 -0700

I apologize for the delayed response: I'm trying to catch up with my
email.

The thing that bothers me about this otherwise excellent discussion is
that I interpret these emails as implying that all identifiers must be
known at the IP layer. A session ID is a transport layer or above
concept. It is desirable (e.g., for management and security) to be able
to correlate session IDs with locators and also with physical locations,
but this doesn't mean that it is desirable to map these identifiers
together within the same layer. Put another way, it is fine for locators
to be in the IP layer and identified at that layer and session IDs to be
at a transport and above layer and identified there. Should a function
need to correlate the two then their existence within their appropriate
layers would permit that in the general case.

-----Original Message-----
From: Scott Brim [mailto:[email-masked]] 
Sent: Wednesday, July 15, 2009 11:06 AM
To: Lixia Zhang
Cc: [email-masked]
Subject: Re: [rrg] Next topic: properties of identifiers

>> host or stack identifier?  Session identifiers already map to the set

>> of locators that go to the same communicating entity.  This is why we

>> need to distinguish them from service identifiers, which in turn may 
>> map to locators of different communicating entities.
> 

See previous reply.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 22 Jul 2009 23:52:28 -0700

> I apologize for the delayed response: I'm trying to catch up with my

like everyone else:)

> known at the IP layer.

Hi Eric, I do not see the implication here.

> A session ID is a transport layer or above

no disagreement here.

Lixia

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 23 Jul 2009 09:12:02 -0700

Hi, Lixia!

Concerning my unclear statement (i.e., your "I do not see the
implication here." comment), what I was trying to convey is the
following logic flow:
1) not all identifiers should be at the IP layer -- some logically occur
at other layers
2) just because identifiers are at several layers, one can still
correlate between them (e.g., for network management or security) as
long as that layer isn't encrypted.

The reason I made this statement is that some postings seemed to imply
(or, at least, this is how I read them) that routing identifiers have to
solve all problems. I disagree: routing identifiers need to solve
routing problems but other problems can be solved by identifiers at
other layers.

This observation is hopefully obvious but what excites me is what it
means to ancillary requirements such as security and network management.
As you may know, I've been keen for about a decade on the concept of
"security zones" in which one can have unique policies for parts of a
routing infrastructure to handle unique requirements of a community of
interest. I therefore consider the various insights of the RRG postings
to see their implications to this type of goal, which is why I felt the
need to mention something which to others is hopefully obvious.
Specifically, security zones theoretically can be made by routing policy
at the IP layer (e.g., policy-based routing) but I am currently
discouraged at how this works, except for VPNs and map-and-encaps, which
really are parallel (complementary) routing systems. Therefore, I am
currently trying to do this at the "IPsec layer" or above. I am curious
whether LISP, for example, could be used to support security zones but I
haven't pursued that idea myself. I wonder if others have?

I am also naturally interested if others have had more success doing
security zones solely at the IP layer, but that is probably out-of-scope
for the RRG and so I didn't want to go there in postings to this WG.

-----Original Message-----
From: Lixia Zhang [mailto:[email-masked]] 
Sent: Wednesday, July 22, 2009 11:52 PM
To: Fleischman, Eric
Cc: [email-masked]
Subject: Re: [rrg] Next topic: properties of identifiers

<snip>

<snip>

---

From: Scott Brim <[email-masked]>
Date: Thu, 23 Jul 2009 19:51:07 +0200

Fleischman, Eric allegedly wrote on 07/23/2009 6:12 PM:
> currently trying to do this at the "IPsec layer" or above. 

It would seem to me that this depends on the what you need to secure. If
you don't want the world to know your IP addresses then you hide them.
If topology, hide routing and addressing. If you don't care about those
but just higher layer objects, you hide them instead, and so on.

> I am curious

Sure.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2009 09:37:49 +1200

> long as that layer isn't encrypted.

Agreed on both counts. Slightly orthogonally, there's
draft-carpenter-behave-referral-object-00.txt, which aims at how
the applications layer might achieve 2), among other things.
But in writing that, we found ourselves pretty much forced to
tackle the problem of identifiers for addressing scopes,
i.e. a form of meta-identifier at layer 3.

   Brian

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Jul 2009 09:23:47 -0700

[Catching up...]

Christian Vogt wrote:
> 
> An Internet architecture must be versatile enough to enable applications
> to use their own identifiers.  But to do this, the Internet architecture
> itself must incorporate identifiers for only two purposes:  to identify a
> peer service for contact establishment, and to identify a session
> instantiated during contact establishment.  On top of that, applications
> can do what they want, such as providing a means to identify hosts for
> fault finding.  Does this make sense?

Well, to me, central to the notion of the Internet architecture and more 
specifically to a routing architecture is the notion of topology.  It 
would seem somewhat challenging to be able to describe topology without 
being able to describe a graph.  And if we want to be able to describe a 
graph, we need to be able to articulate the nodes and edges in that 
graph.  I don't see how to do this with just service identifiers.

Regards,
Tony

---

From: Scott Brim <[email-masked]>
Date: Sat, 25 Jul 2009 22:04:04 +0200

> graph.  I don't see how to do this with just service identifiers.

An excellent thought-provoking post, although in the end I somewhat
disagree.  From the point of view of the network, the nodes in the graph
are attachment points, not hosts.  Attachment points are where the
network stops.  We do have names for those points without invoking node
identifiers -- according to
<http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGTerminology> they
are called locators.  Of course forwarding functions will use whatever
they want as input, including things that some people call
"identifiers", but that extra information is not necessary to describe
topology.

See you ... Scott

---

From: Tony Li <[email-masked]>
Date: Sun, 26 Jul 2009 06:53:03 +0200

> "identifiers", but that extra information is not necessary to describe

Well, for the most part we seem to be using locators to name the edges 
of the graph, not the nodes.  If we only have locators, it makes it very 
challenging to describe topology.  How do you deal with the case where 
there are two nodes that are both connected to two edges?

Tony

---

From: Michael Menth <[email-masked]>
Date: Sun, 26 Jul 2009 07:48:24 +0200

Tony Li schrieb:
> of the graph, not the nodes.  If we only have locators, it makes it 
> very challenging to describe topology.  How do you deal with the case 
> where there are two nodes that are both connected to two edges?
>
> Tony
The edges have two different names then? Sticking to one of them would 
imply that when used for hierarchical routing, multihoming becomes more 
difficult again? Or is this view too much constrained by current Loc/ID 
background?

Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Christian Vogt <[email-masked]>
Date: Mon, 27 Jul 2009 04:25:34 +0200

On Jul 25, 2009, Tony Li wrote:

>> applications

> graph.  I don't see how to do this with just service identifiers.

Tony -

This is about identification, not about routing.

For routing, 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.

- Christian

---

From: Tony Li <[email-masked]>
Date: Mon, 27 Jul 2009 05:15:51 +0200

Christian,

> This is about identification, not about routing.

This is RRG.  It's all about routing.  Identification is a necessary 
side-effect.

> entity through which one must pass to reach a given service or session.

Excellent, glad you're on board.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Tue, 28 Jul 2009 01:38:19 +0200

> This is RRG.  It's all about routing.  Identification is a necessary

... although it was you who started this thread. ;-)

Also, as I earlier mentioned to Lixia, I do believe this discussion is
useful also for RRG.  Keep in mind that there is a group of people in
RRG who believe that identifier-locator separation can accomplish our
mission.  Devising a suitable identifier-locator separation solution, in
turn, requires some discussion of the type we were having.

> Excellent, glad you're on board.

Yep, cool.

- Christian