Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Sun, 31 Dec 2006 18:27:54 -0500 (EST)

> From: Roland Dobbins <[email-masked]>

    >> Ah. Could you please sketch out for us the technical details of such a
    >> solution?

    > the fact that I personally haven't yet come up with a solution to a
    > problem which has for quite some time been vexing a large number of
    > people who're a lot smarter than I am doesn't invalidate the
    > widely-shared view within the operational community that SHIM6 as
    > currently constituted will not work for most organizations

OK, but the latter point doesn't help with the former one, either.

TANSTAAFL. If people want the benefit of widespread multihoming, there is
going to be a cost, and, as you indicated, many smart people have failed to
come up with a painless one.

And when I said "sketch", I meant just that. I don't want a protocol from
you, just some idea of the vague outlines of an approach that you think might
work. Saying "A won't work because of X, and B won't work because of Y"
doesn't really help much.

Do you have any idea at all how to make this work? (And a list of goals,
like "it should be the same for everyone" or "it should be easy to manage"
aren't "how to make it work".)

    > The point is that *any solution which mandates multiple endpoint IP
    > addresses in multihoming situations is a nonstarter*

If you mean "solutions which mandate multiple IP addresses" above, then I'm
OK with that. If you mean "solutions which mandate multiple routing-names",
then I have some very bad news for you.

Other than "let the routing do it" (and flat - aka PI - routing doesn't
scale), *every* proposed solution which I've ever heard of (including ones
which simply aren't feasible in the current routing architecture, such as
Dave Clark's trailing route fragments, my local topology fragments, etc)
involves use of multiple routing-names (the semantics of which vary, but
that's what they all are, basically).

So if multiple routing-names are out, widespread multi-homing is out.

"We are a lighthouse. Your call."

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 15:44:45 -0800

> doesn't really help much.

I am thinking about it, as are a lot of other folks.  If and when I  
have something sensible to say on the subject, I'll say it.  Right  
now, I don't.

Saying "A won't work because of X, and B won't work because of Y"  
helps a great deal, actually, especially when apparently nobody  
involved in developing A and B took X and Y into consideration.   
That's the situation we find ourselves in today.

> then I have some very bad news for you.

I mean 'mandating multiple identiling list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 15:44:45 -0800

> then I have some very bad news for you.

I mean 'mandating multiple identifiers of the type which go into  
ACLs, firewall rules, QoS rules, etc. for filtering/matching packets'  
is out.

> that's what they all are, basically).

Agreed.

Which is why I'll say, one last time, the *best* thing to do, while  
it's not too late, would be to take the lessons learned so far and  
get to work on a new protocol suite which implements a host/locator  
split (leveraging your work and that of others) and a bunch of other  
useful stuff, rather than expending a lot of blood, sweat, and  
treasure deploying a protocol suite which leaves us with all the  
problems we had in the first place, along with some new problems -  
and in -hexadecimal-, no less.

;>

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman

fiers of the type which go into  
ACLs, firewall rules, QoS rules, etc. for filtering/matching packets'  
is out.

> that's what they all are, basically).

Agreed.

Which is why I'll say, one last time, the *best* thing to do, while  
it's not too late, would be to take the lessons learned so far and  
get to work on a new protocol suite which implements a host/locator  
split (leveraging your work and that of others) and a bunch of other  
useful stuff, rather than expending a lot of blood, sweat, and  
treasure deploying a protocol suite which leaves us with all the  
problems we had in the first place, along with some new problems -  
and in -hexadecimal-, no less.

;>

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman