Subject: Re: Re: [arch-d] [Off-topic] Further thoughts: about systems theory and the theory U

From: [email-masked] (Noel Chiappa)
Date: Thu, 9 Nov 2006 22:55:07 -0500 (EST)

> From: David Conrad <[email-masked]>

    >> The issue, to put it bluntly, is: how much will is there to change
    >> IPv6?

    > My answer: little to none in all but a few router jockeys in large
    > ISPs and some protocol geeks at a couple of large router vendors. But
    > hopefully that'll be enough.

How will that be enough? If any change impacts on the hosts, as most
attempts to separate location and id would, then don't host people have to
be on board too?

The exception would be if you're thinking of some kind of scheme where we jack
up IPv6, make IPv6 an end-end host-naming only layer, and IPv6 addresses the
end-end entity naming, and stick another layer underneath it with
routing-names. The entry router would have to lookup the destination
entity-name, and map it into the destination routing-name, and then throw on
another header with the destination routing-name in it (you have to do that,
otherwise you'd have to do the mapping step at every hop, which is probably
too inefficient).  Then the last-hop router would have to take that wrapper
off. If either source of desination host eventually understands the
routing-name layer, you could omit the first-hop/last-hop step.

Even to do that you need to get all of the router vendors on board, otherwise
you have to deal with the possibility that the packet has to get unwrapped
half-way along the path, and then you start to lose a lot of the benefits if
all you have is (effectively) a small portion of the network using the new
addressing (and routing).

Is there some other way to i) do identification/location split without
getting general consensus that I missed?

    > I don't believe that something will be a wholesale re-architecture and
    > redeployment of existing IPv6 technology, it will be an incremental,
    > evolutionary hack that will make IPv6 suck just sufficiently less to
    > keep things from falling over.

OK, so that takes whole books of potential solutions off the table. (Which
kind of contradicts what David said earlier. I'd love to hear his take on
your observations here.)

    > You attribute more power to the IESG and IAB than I.

I am fully aware that they can't make the community do something the
community doesn't want to do. Which is why I said:

    >> It can be as simple as "in our opinion, we think the community needs
    >> to do this - the community may disagree, but in doing so it will be
    >> going against our recommendation"

But if we're constrained to only do "bag-on-the-side" fixes, then of course
that's not needed.

	Noel

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

---

From: David Conrad <[email-masked]>
Date: Thu, 9 Nov 2006 20:52:45 -0800

Noel,

On Nov 9, 2006, at 7:55 PM, Noel Chiappa wrote:
> If any change impacts on the hosts, as most

Obviously, yes.  However, I am skeptical that you can re-implement  
and redeploy the host stack before one or another wall (there are  
several) is upon us.  As such, as you correctly surmise:

> routing-names.

Right.  And to minimize the necessity of redeploying existing code,  
the 'layer underneath' would simply be unmodified IPv6, leveraging  
the existing deployment of IPv6 capable core routers.  The  
'underneath IPv6' would route on highly aggregated locators (routing- 
names) using existing tools and techniques ISPs are comfortable with  
today.

> The entry router would have to lookup the destination
> another header with the destination routing-name in it.

Yep.  Alternatively, if this sort of dynamic tunneling is too scary  
due to MTU issues or whatever, you could do address rewriting at both  
ends (but that has a few serious downsides).

> Then the last-hop router would have to take that wrapper off.

I personally prefer the model where the encapsulation is done at the  
source edge and de-encapsulation is done at the destination edge as  
opposed to the first hop/last hop as that makes site-wide multi- 
homing and number portability very easy, but both approaches can co- 
exist.

> If either source of desination host eventually understands the

At the cost of having to make the host understand the routing-name.

> Even to do that you need to get all of the router vendors on board,

Cisco and Juniper have 75% of the worldwide service provider market  
share in routers (according to a Gartner report published on 15 Aug  
2006).

> otherwise
> half-way along the path,

Or, if the destination does not have a mapping, you fall back to  
potentially sub-optimal 'normal' routing, treating the identifier as  
the now-standard locator/id merged address.

> and then you start to lose a lot of the benefits if

Which will be the case during transition for any approach unless you  
assume a global flag day.

> getting general consensus that I missed?

Probably not -- you're a lot smarter on this stuff than I am, but I  
see this as a fairly pragmatic cost/benefit tradeoff.  I see 4 options:

a) Change both the end points and the infrastructure (I call this the  
IPv7 approach)
b) Change only the end points (every host IPv6 stack deployed to date)
c) Change only the infrastructure (all routers deployed for IPv6  
service)
d) Change the junction between the hosts and the infrastructure  
(e.g., the point between the "core" and the "edge").

I figure (d) is the cheapest, easiest, and thus, most likely to be  
deployed.

> But if we're constrained to only do "bag-on-the-side" fixes, then  

To be clear, I am not suggesting these are constraints (I certainly  
am not the one to define constraints in any event), I am merely  
voicing my opinion that attempts to deploy design, architect,  
implement, and deploy IPv7 is unlikely to be successful in the  
timeframes we have.  More to the point, the Internet is not going to  
stand still while IPv7 is developed, thus by the time the new  
architecture is "done", there will be that much more of an installed  
base to deal with.

However, as I said, this is merely my opinion...

Rgds,
-drc