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

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Nov 2006 10:34:55 -0500 (EST)

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

    >> 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 [become] the end-end entity naming, and stick another layer
    >> underneath it with 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)

Oh great, so once again we do the most minimal possible "bag-on-the-side"
kludge to muddle through the nearest bump we can see on the road.

We don't even take the opportunity to put a more capable layer down there,
something that could say, name (and thefore have the possibility of managing)
traffic aggregates. No, instead we'll just do the simplest, easiest hack
possible, and keep using our routing table lashup hammers to drive traffic
engineering screws.

For this, you don't need any architectural work, so this mailing list is
inappropriate. (Then again, this mailing list may be a complete waste of time
anyway. Sorry I'm so negative, but this is really depressing me. I think
maybe I'd better go back to making furniture.)

And the best part of all is that we're adding bags on the side of IPv6 before
it's even deployed. Wow, what a great design.

Sorry I'm ranting, but this is really, really, really depressing.

    >> 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

You're right, that would be the way to go.

    >> If either source of desination host eventually understands the
    >> routing-name layer, you could omit the first-hop/last-hop step.

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

Right, but the host gets more flexibility - e.g. if the other end has
multiple addresses (because it has interfaces to multiple networks), it could
control which one is picked, if it had some reason to so. (That may not be a
very useful thing to do in practise, it's just off the top of my head as an
*example* of the kind of thing you could do.)

    > 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.

In other words, you'd inject routes using names from the "identifier"
namespace into the "locator" routing plane? Ugh. How soon until you basically
lose the value of having a separate locator plane, if that becomes
widespread? And you know someone will find a reason to do that kludge. My
motto is always "make it impossible for people to kludge, otherwise they
will".

    >> 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

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

I understand that it will have to be deployed incrementally. All I meant was
that unless in the "end" state (I know, nothing's ever permanent) it is
deployed fairly widely, you'll have a large part of the network which does
have to deal with mega-tables, and does that really help? I suppose it helps
those people who are part of the region with the new stuff...

    > I see this as a fairly pragmatic cost/benefit tradeoff. 

I see it, obviously, as another instance of what Pekka pointed out - people
taking the easiest, but short-term, solution to their problem.

    > I see 4 options:
    > a) Change both the end points and the infrastructure ..
    > b) Change only the end points ..
    > c) Change only the [router] infrastructure ..
    > 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.

Well, you're right there.

It's basically 8+8, only it's now 16+16, and the edge routers add an entire
header, not just play with the RG bits.

    > 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

Alas (to me), it's one that makes a lot of sense.

	Noel

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Nov 2006 09:34:18 -0800

Noel,
> Sorry I'm ranting, but this is really, really, really depressing.
I'm sorry to interrupt your depression, but I'm interested
in hearing what you think we should do. Do you have
a pointer to a proposal that I could look at?

--Jari

---

From: David Conrad <[email-masked]>
Date: Fri, 10 Nov 2006 14:25:52 -0800

Noel,

> kludge to muddle through the nearest bump we can see on the road.

A not unfair characterization.

> traffic aggregates.

Having worked at a Silicon Valley software company, I am painfully  
aware that trying to do too much in too little time pretty much  
guarantees failure.  Given the dependence the world now has on the  
Internet, I'm fairly certain we don't really have the luxury of failing.

It is probably worthwhile pointing out that one advantage to the  
"jack up" approach is that once we do the initial jack up, we have  
_much_ greater flexibility in replacing the underlying layer(s).   
Right now, we're pretty screwed, particularly given the topics Fred  
touched on.

> it's even deployed.

I'd argue that IPv6 is deployed to a large extent now, if not  
actually used. I believe most core routers and host OSes support IPv6  
if the latest code is installed.  I would agree that there is very  
little if any actual use at this stage.

However, on the other hand, it has taken us 10 years to get this  
far.  Even if someone comes up with the Best Internet Architecture  
Ever(tm), it will take several years to get it deployed to the same  
level IPv6 is today and in the intervening time, people are going to  
be deploying more and more IPv6 and (presumably) actually using it.

> Wow, what a great design.

Call it an great educational experience.

> Sorry I'm ranting, but this is really, really, really depressing.

Again, I am just expressing my opinion and I too consider the state  
we're now in to be quite depressing.  I would be overjoyed to see an  
alternative.  Pragmatically speaking, however, I'm not sure there is  
one given the situation we have placed ourselves in.

Rgds,
-drc