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 10:52:33 -0500 (EST)

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

    > the proposed SHIM6 solution is iatrogenic in nature due to the reasons
    > outlined previously.

Well, perhaps it is fatally flawed, but if so, we need to figure out why, and
then work on how to overcome those issues.

Look, as far as I can work out, there are basically two classes of solution
to providing widespread multi-homing.

The first is "let the routing do it". Alas, within the current routing
architecture, that amounts to "forcing every router in the entire
default-free zone to carry an advertisement for site X's PI-address", which
is widely seen (although not universally, q.v. that address registry meeting
where they approved the PI proposal) as non-workable.

So, that leave us with "other", which as far as I can work out, means some
form of "multiple routing-names for each connected entity", because I can't
think of any other. (If someone has an idea which is neither of these two,
please speak up!) So now the only question is the engineering details: who
picks, when they are added, where they are carried, etc, etc.

    > I don't know what the right solution is, yet.

Well, a lot of people have been struggling with this for a long time. There
is no easy solution, or somebody would probably have figured it out by now.

It's easy to sit back and say "solution A has problem X" and "solution B has
problem Y". That sort of situation, where there is no perfect solution, is
almost inevitable when we're trying to upgrade a large, deployed system.
Heck, I could come up with a great design for multi-homing, *if I had a blank
sheet of paper*.

The problem here is that if we start out with a solution-space of size A, and
then start enumerating constraints, what happens is that each constraint
chops off a piece of solution space, until eventually we're caught in a
pretty small piece of solution-space. Apply enough constraints, and you're
probably tiled the entire solution-space. Something - or somebody - has got
to give.

    > this class of proposals cannot be realistically considered for 'the
    > IPv6 multihoming solution'.

What exactly are you including in "this class"? Because if you're including
all solutions in which things have more than one routing-name, we've just
ruled out the entire solution-space (other than "let the routing do it").

If you are OK with the general concept, but just think the particular details
of SHIM6 have problems, yeah, could be. Explain what they are, and we can see
if there's a way to change things to overcome them. TLi explained some of the
constraints that got applied which reduced the solution-space - perhaps we
need to go back and re-examine whether some of them need to be reconsidered.

But if you're against all solutions of the form "multiple routing-names",
what's left, other than "let the routing do it"?

	Noel

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

---

From: Roland Dobbins <[email-masked]>
Date: Sun, 31 Dec 2006 08:27:16 -0800

> what's left, other than "let the routing do it"?

My preference is in fact to 'let the routing do it', because that's  
the simplest way from an operational/administrative standpoint for  
the majority of the user/customer base (which is why it's handled  
this way today in the IPv4 world); but I don't think we ought to bet  
the farm on that approach due to the many potential issues folks have  
raised, so we must come up with another set of solutions which are  
scalable and deployable.  We cannot bet the future of internetworking  
on Moore's Law, no matter how much we'd like to do so.

[ Well, that's not entirely true.  My real preference would be to  
declare the 'IPv6 Limited-Deployment Proof-of-Concept Experiment' a  
success, and then get on with designing IPv10 for general deployment,  
incorporating the lessons we've learned over the last 30 years with  
what became IPv4 and what has become IPv6, mandating a host/locator  
split, ensuring that operational realities and requirements from SP,  
enterprise, SOHO, and consumer users are taken into account.  I would  
also like a flying pony. ]

I'm against all solutions of the form 'require each host to be  
assigned x number of transitory SP-provided IP addresses, where x=the  
number of SP transit links required to serve traffic originating from/ 
destined to said host' due to the reasons stated.

My hope is that a more practical solution lies somewhere between  
these two extremes.

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

		All battles are perpetual.

     		   -- Milton Friedman