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

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Christian Kuhtz <ck@arch.bellsouth.net>

    > 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