Subject: Re: Ok, so what should we do then? (Was: Re: [arch-d] [Off-topic]Further thoughts: about systems theory and the theory U)

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Nov 2006 15:13:30 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    > address ambiguity destroys the e2e identification property and third
    > party referrals

That's not a bug, that's a feature.

We want to discourage people from passing around bare endpoint identifiers.
(Such an identifier might e.g. identify one particular server in a pool - not
what you really wanted anyway.) Rather, they *should* be passing around
higher-level identifiers.

NewArch deliberately, for architectural reasons on a blank sheet, went down
this same path, that endpoint identifiers (except the approximately equivalent
things in NewArch are somewhat different) are not globally unique, and
necessarily cannot be passed to third parties.

So, if it doesn't work to pass around bare endpoint identifiers to third
parties, so much the better.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2006 11:18:52 +0100

> higher-level identifiers.

In theory, I agree. In practice, real time apps really don't want to pay
the overhead of another lookup, once a multiparty session is started.

Address ambiguity has other unpleasant effects as well, of course. And
there's no need for it any more.

      Brian

---

From: Scott W Brim <[email-masked]>
Date: Tue, 14 Nov 2006 18:09:49 -0800

On 11/14/2006 02:18 AM, Brian E Carpenter allegedly wrote:
> Noel Chiappa wrote:
>> We want to discourage people from passing around bare endpoint 
>> identifiers. (Such an identifier might e.g. identify one
>> particular server in a pool - not what you really wanted anyway.)
>> Rather, they *should* be passing around higher-level identifiers.
> 
> In theory, I agree. In practice, real time apps really don't want
> to pay the overhead of another lookup, once a multiparty session is
> started.

But when new parties join, they join at multiple layers.  That is the
application might have visibility into the IP address (as presented to
the receiver), but it also gets higher layer identifiers,
authentication etc.  I don't see what you're saying.

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Nov 2006 11:01:57 +0100

> authentication etc.  I don't see what you're saying.

In something like a massive multi-player game, it's OK to pay lookup/AAA
overhead when a new player joins, or when you first encounter a new player,
but from then on you need to pass a handle that does not generate
further lookup. It seems a shame if we can't use network layer handles
for that.

     Brian

---

From: <[email-masked]>
Date: Wed, 15 Nov 2006 15:07:15 +0200

Brian E Carpenter [mailto:[email-masked]] wrote:
>>>>identifiers. (Such an identifier might e.g. identify one particular 
>>>>server in a pool - not what you really wanted anyway.) Rather, they 
>>>>*should* be passing around higher-level identifiers.
>>>
>>>In theory, I agree. In practice, real time apps really don't want to 
>>>pay the overhead of another lookup, once a multiparty session is 
>>>started.
>> 
>> 
>In something like a massive multi-player game, it's OK to pay 
>lookup/AAA overhead when a new player joins, or when you first 
>encounter a new player, but from then on you need to pass a 
>handle that does not generate further lookup. It seems a shame 
>if we can't use network layer handles for that.
>

An application layer handle is needed to refer to a player. What if a
player changes from one host to another? Why should his handle change?
Why would you want to use network layer handles for that? Doing exactly
that has gotten us in this inability to renumber mess (network layer
handles used to refer to service/app layer stuff in config files etc.).

	Jarno

---

From: Scott W Brim <[email-masked]>
Date: Wed, 15 Nov 2006 06:31:55 -0800

> further lookup. It seems a shame if we can't use network layer handles

I don't see where the further lookup comes from.  Someone joins and
the information is propagated, including persistent identifier and
authentication information, as well as the (last known) network layer
"handle".  If & when he changes his NLH, the information that is
important to the game is still there.  It's like HIP at an application
layer.  The downside is that every application has to have such a
mechanism, so it would be good to have a common mechanism at a common
layer.  Anyway I'm still missing something.

Scott

---

From: Ross Callon <[email-masked]>
Date: Wed, 15 Nov 2006 12:13:27 -0500

>higher-level identifiers.

In principle I agree: Applications should deal with application
identifiers (such as DNS names), not with network layer
addresses. Having applications pass around network layer
addresses (or network layer IDs) puts constraints on the
network layer that is making it significantly more difficult to
deal with various problems.

However, I thought that the point of this ongoing discussion
was to exchange information and ideas that will lead to a
practical solution that can be deployed in the real Internet.

In practice, we aren't going to get applications re-written to
remove all of the cases where they carry around network
layer addresses. Thus we are going to have to live with the
fact that this isn't going to change. We could redefine the
network layer thing that Applications already are carrying
to be an "identifier" that is location-independent, but we
can't stop them from carrying something that looks a whole
lot like the IP addresses that they already carry.

Ross

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 15 Nov 2006 19:02:38 +0100

Dear Ross,
We already have IPv4 and IPv6 using 2 /3 blocks. That works and 
should not be changed, just fade away if a new solution works better.
We have to devise a new system which works in _addition_. Using a 
different /3 block (so we are sure there is not conflict).

That new system should not be too complex, nor to take too much room, 
on the machines, since it will have to be added. It should decrease 
the need for intelligence in routers and middle boxes (dumb network) 
sharing in the restauration of e2e. The DNS experience shows that 
architecturally that kind of parallel intelligent service went well. 
So an idea to dig into. Resolving routes instead of addresses? Which 
way these addresses are to be documented? Far easier and lighter if 
the topology is designed after the numbering plan.

Now, you can try to develop it from existing concepts. You can use 
any entirely new concepts and a protocol variant. There is no harm 
trying. There is harm only in failing to find a solution. The more 
ideas and concepts, the more we have chances to succeed.

And if all this was not necessary, never mind nothing will have changed.
But I do think that value added routing services are the IPv6 
"application" the IETF waits for 14 years.
jfc

---

From: David Conrad <[email-masked]>
Date: Wed, 15 Nov 2006 11:12:39 -0800

Ross,

On Nov 15, 2006, at 9:13 AM, Ross Callon wrote:
> fact that this isn't going to change.

Amen.

> We could redefine the

Exactly.  The point of my presentation in AMS was simply, treat the  
128 bit values as keys into a lookup table that can then return you  
the actual routing labels.  That is, add a layer of indirection with  
the pros (flexibility, backwards compatibility, etc.) and cons  
(performance hit) that implies.

The questions that then get generated include:

- how do you distinguish between a key and the value?
- where is the lookup table (hosts, first hop, customer edge, isp  
edge, core)?
- how is the lookup table (or changes to the table) propagated (pull,  
e.g., DNS or push, e.g., BGP attribute)?
- how can the performance hit be minimized (i.e., how do you cache)?

I personally believe that if we set the constraint that we want to  
minimize changes in order to leverage what has been done to date and  
limit the cost (both monetary and labor), answers to some of these  
questions become relatively straight-forward.

Rgds,
-drc

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 16 Nov 2006 05:04:11 -0500

I agree with Brian putting my IP stack developers hat on any time I
don't have to pop up to the apps layer the better.  ergo I think we need
network layer handles too.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, November 15, 2006 8:07 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Ok, so what should we do then? (Was: Re: 
> [arch-d][Off-topic]Furtherthoughts: about systems theory and 
> the theory U)
> 
> particular 
> handle that 
> >does not generate further lookup. It seems a shame if we can't use 
> >network layer handles for that.
> >
> 
> An application layer handle is needed to refer to a player. 
> What if a player changes from one host to another? Why should 
> his handle change?
> Why would you want to use network layer handles for that? 
> Doing exactly that has gotten us in this inability to 
> renumber mess (network layer handles used to refer to 
> service/app layer stuff in config files etc.).
> 
> 	Jarno
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2006 16:31:52 +0100

> layer.  Anyway I'm still missing something.

Well, it's remarkably similar to multihoming when you describe it
like that. The fact that the NLH has changed has to be detected
and dealt with, with security threats covered.

But my point was that as long as the NLH remains valid, it's more
efficient to use it, and in real-time games efficiency matters.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Nov 2006 16:20:37 +0100

[email-masked] wrote:
>>>But when new parties join, they join at multiple layers.  
>>
>>That is the 
>>
>>>application might have visibility into the IP address (as 
>>
>>presented to 
>>

You clearly need to be able to invalidate a network layer handle
if the upper layer entity migrates; and then you have to pay the
lookup overhead.

    Brian

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 16 Nov 2006 11:42:04 -0500

Shim6 has come up with a means to do what Ross asks and the question is
will end node implementations move to the Shim6 (very close to HIP)
model.  I will share my day job view input is this is significant code
base change and has significant effect to product IP stack
implementation.  But if all will move and all will go and support the
separation of identity from location then we need to move with Shim6.
Prototyping is a good thing and IETF Shim6 WG has done a good technical
job on first incantation that I have seen for end nodes that is worth
implementation and I have reviewed it with comments to the WG and
authors in depth it is ready for PS I believe too.  Caveat is I don't
buy into CGA at all for anything or any protocol, but I also think all
vendors should leave their IPR input at the door outside of the IETF or
any Open Standards Development Organization I am tired of IPR we don't
need it, require it, and have plenty of great minds here without having
to adapt vendor IPR it has become abusive.  But that gets into the
security issues and we need to do one step at a time.

> From: Ross Callon [mailto:[email-masked]] 
> Sent: Wednesday, November 15, 2006 12:13 PM
> To: Noel Chiappa; [email-masked]
> Subject: Re: Ok, so what should we do then? (Was: Re: 
> [arch-d][Off-topic]Further thoughts: about systems theory and 
> the theory U)
> 
> >(Such an identifier might e.g. identify one particular 
> server in a pool 
> >- not what you really wanted anyway.) Rather, they *should* 
> be passing 
> >around higher-level identifiers.
> 
> In principle I agree: Applications should deal with 
> application identifiers (such as DNS names), not with network 
> layer addresses. Having applications pass around network 
> layer addresses (or network layer IDs) puts constraints on 
> the network layer that is making it significantly more 
> difficult to deal with various problems.
> 
> In practice, we aren't going to get applications re-written 
> to remove all of the cases where they carry around network 
> network layer thing that Applications already are carrying to 
> be an "identifier" that is location-independent, but we can't 
> stop them from carrying something that looks a whole lot like 
> the IP addresses that they already carry.
> 
> Ross
> 
>