Subject: RE: [arch-d] Major practical decision

From: [email-masked] (Noel Chiappa)
Date: Sat, 9 Dec 2006 17:14:31 -0500 (EST)

> From: "Bound, Jim" <[email-masked]>

    > My understanding is adding a layer is jack-up

Well, jack-up adds a layer, but so does the other alternative.

As I said in my reply to Mark, separation of location and identity implies
the creation of a second namespace (even if they are syntactically identical,
as in SHIM6), to allow separation of those two functions - and to
subsequently allow bindings from one kind of name to the other (which is how
you provide support for all sorts of things, like mobility and multihoming).

Inevitably, you wind up structuring the new names as part of a layer, or
sub-layer (whatever/however you want to describe it). (People may not think
they are creating a new layer, but really, they are.) The key point is that
the location names go with the lower of the two, and the identity names going
with the higher layer.

The big question is: "What do the exising IPvN addresses become?" If they
turn into identity, you wind up with a jack-up design, you add a new lower
layer and the new namespace is the lower-layer locators; if they turn into
locators, the new-namespace becomes identity, and you wind up with SHIM6,
HIP, etc, etc.

    > and that is for RAM. Not this list?

Well, not really (but there is a stronger tie to routing for jack-up).

If we go with jack-up, that means deploying a new namespace for
routing-names, and there are consequences during the deployment (particularly
during the early deployment phases, where I think the problems are the worst)
for the routing, which has to handle (basically) two separate
routing-name-spaces for a while.

There isn't the same immediate tie-in with routing for a new end-end
namespace (e.g. HIP), but even down that road, the growth of the routing
tables may still be too large to handle, and so perhaps there's work to be
done there too.

So my concept was for RAM to try and focus on the routing issues,
particularly the implications for the routing of deploying jack-up, but
really I suspect both paths have routing issues.

    > This is to discuss not jack-up? Yes or No.

The question of whether we add a new end-end namespace, or a new
routing-names namespace (which is really the same question as whether the
existing IPvN addresses become identity or location) isn't really a routing
issue. Whatever we do, there's going to be one namespace for routing-names,
and the routing's going to have to do path selection.

So the decision between deploying a "new" (" "'s since SHIM6, HIP, etc are
already here) end-end namespace, and going with jack-up instead, really
doesn't have a major routing component*; so I reckon this list is a good
place to consider that question.

(* Unless, of course, people thinking about routing decide that the routing
implications of one path or the other are too horrible to contemplate, and we
really need to pick option X.)

	Noel

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

---

From: Tony Li <[email-masked]>
Date: Sat, 9 Dec 2006 16:34:10 -0800

> the location names go with the lower of the two, and the identity  

Certainly conceptually I agree.  However, I'm concerned that when  
other folks approach adding a layer, they will want to invoke another  
header and tunnel everything.  While I'm a big fan of tunneling (see  
RFC 1701 ;-), I don't see tunneling as a first-class architectural  
solution.  It adds non-trivial overhead and creates subsidiary issues  
like MTU and ICMP problems that don't live up to our standards for  
architectural cleanliness.

Hi ho,
Tony

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 10 Dec 2006 11:16:26 +0200

> Inevitably, you wind up structuring the new names as part of a  
> layer, or sub-layer (whatever/however you want to describe it).   
> (People may not think they are creating a new layer, but really,  
> they are.) The key point is that the location names go with the  
> lower of the two, and the identity names going
> with the higher layer.

Very well stated.

> The big question is: "What do the exising IPvN addresses become?"  
> If they turn into identity, you wind up with a jack-up design, you  
> add a new lower layer and the new namespace is the lower-layer  
> locators; if they turn into locators, the new-namespace becomes  
> identity, and you wind up with SHIM6, HIP, etc, etc.

Right.

When answering this, IMHO it is important to keep two partly-distinct  
sets of questions in mind:

1. Architectural and technical.  This is what we have most looked at  
so far.

2. Economic and deployment.  This is at least as important.

> routing-names, and there are consequences during the deployment  
> (particularly during the early deployment phases, where I think the  
> problems are the worst) for the routing, which has to handle  
> (basically) two separate routing-name-spaces for a while.

Which makes me to worry if we could get going with the jack-up model  
in the first place.  What would be the deployment scenario?  Would  
the costs and benefits fall largely to the same parties; or,  
alternatively, are there existing business relationships that allow  
the costs to be distributed to those that benefit?

> There isn't the same immediate tie-in with routing for a new end- 
> end namespace (e.g. HIP), but even down that road, the growth of  
> the routing tables may still be too large to handle, and so perhaps  
> there's work to be done there too.

Stating what I think is essentially the same point but differently,  
if we pick the way of a new layer above, we will need to work hard to  
reap the potential routing benefits from introducing the new end-end  
namespace.  That is, a new end-end name space allows more freedom to  
routing as it allows more agile routing names, but it is far from  
clear how to utilise that freedom.  Furthermore, the new layer-above  
may also allow different regions of the network to use different  
routing schemes; such regions could be connected by what would be,  
from today's point of view, kind-of architected NAT boxes.  (Not  
quite that simple in practise but that should give the idea.)  But  
again, there're lots of remaining work on a more detailed level.

(I think I mostly agree with the rest of your message.  In any case,  
I don't have anything to add to it.)

--Pekka Nikander

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 11 Dec 2006 07:09:30 -0500

> The question of whether we add a new end-end namespace, or a 
> new routing-names namespace (which is really the same 
> question as whether the existing IPvN addresses become 
> identity or location) isn't really a routing issue. Whatever 
> we do, there's going to be one namespace for routing-names, 

I think we need two new name spaces.  How we do *new* routing and how we
do *new* end-to-end semantics I think are separate tasks.  The
transition will require jack-up but eventually the jack-up should not be
required in either case. Where we can use existing tools to help is
probably a wise excercise depending on our time-to-market resolution to
IAB concerns.

/jim