Subject: Re: My impressions of the Sunday meetings....

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 21 Nov 2002 12:16:43 -0500

> From: Christian Kuhtz <[email-masked]>

    > many of these proposals are good for solving world hunger and cooking
    > coffee in the morning. Right now, a glass of cold water is all I
    > really need because right now we have nothing, and people are starting
    > to think about getting thirsty someday.

I hear you, but at the same time a quick easy solution to part of the
problem can sometimes make the rest of the problem *harder* to solve, if it
results in stuff being deployed that gets in the way of solving the harder
problems.

Some mailing list I'm on recently had a message about how truly painful it's
getting to do anything that requires changing the installed base. (Not that
that seems to trouble commercial Web sites, who seem to be continually
adding dubious "features" that require the latest and greatest browser, but
I digress...)

So sometimes it really does help to have some idea of what the long-term
path is going to be, to make sure that your short-term quick hacks aren't
going to get in the way of the long-term solution.

    > The most pressing problems to me DO NOT include an individual host's
    > ability to pick and chose a path out of several options. They DO
    > include for an administrative domain to be attached to multiple paths
    > and being able to chose which based on its own administrative ..
    > preferences.

This is, from the user's point of view, a subtle change to the goals of
"multi-homing", from reliability to control of paths. From the
architectural/ engineering point of view, it's enormous. This is an
important enough topic that I'm going to tackle it in a separate message.

    > The more pressing issue is those customers who have traditionally been
    > sophisticated and/or large enough to be multipathing candidates. Those
    > are what I would like to see developed as a priority

Sites that are "large" enough can "reasonably" be handled (in the sense of
allowing traditional multi-homing) by giving them a globally visible chunk
of address space. Handling extra path control requirements is harder (see
comment above) no matter how you do it.

    > MPLS-VPN is an example of a bastard child which actually has a
    > practical application and is being deployed commercially.

Umm, do you know of any plans to have a single MPLS-VPN cover multiple
administrative domains? If not, local solutions are always trivial. It's
ones that work on a world-wide scale which are harder.

    > significance of address space over great 'distances' is another one.
    > Is it neccessary for things to show up in the DFZ that may rest in
    > layers around it? Is there a way we can abstraction very complex
    > topology to the DFZ?

Sure, but it means having i) more layers of abstraction (i.e. names for
areas of the network) in the routing system, which means ii) having better
tools to a) define the boundaries of abstractions and b) make sure that the
routing system slowly (as the distance from an abstraction increases)
discards detailed information about the insides of the abstraction.

YMMV, but it seems to me that trying to do all that in the context of
abstractions defined with bit masks on fixed-length addresses, and a routing
architecture that ships around routing tables (i.e. BGP and everything that
looks anything like it) is a waste of time. So, see Figure 1.

    > But, before we can do any of that.. let's narrow down this monstrous
    > scope to a managable piece!

See Figure 1....

	Noel

---

From: Tim Chown <[email-masked]>
Date: Thu, 21 Nov 2002 18:16:10 +0000

> adding dubious "features" that require the latest and greatest browser, but

Which is why the recent discussions have been focused on using existing
components (cf. Christian's draft) and hand-waving for any extras that
may be desirable (e.g. a new ICMP message type).
 
> going to get in the way of the long-term solution.

I view multi6 rather like v6 transition.  If tools can be deployed by
those wanting to benefit, without affecting requirements on othes, we have
a path we can take now.  If a better solution for that target audience 
comes along, we can take that path then.

This has been one focus of the Atlanta meetings.

I'm trying to summarise recent discussions in Atlanta and on the lists; I'll
try to get a snapshot out soon.

tim

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 21 Nov 2002 19:58:46 +0100

> results in stuff being deployed that gets in the way of solving the 

I am not arguing for a quick and easy solution, rather the contrary. 
BUT, I think that we need more data, experience and time. Giving out a 
temporary PI block would give us this at little or no cost.

> adding dubious "features" that require the latest and greatest 

I agree, and therefor I am very reluctant to go in a direction that 
would require changes or implementations to the current installed base 
- without us even having understood the problem and agreed on it.

> going to get in the way of the long-term solution.

Again, I agree. That is why I wrote that we need a road-map so we know 
where we are going with the different solutions.

- kurtis -