Re: (multi6) requirements draft comments

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

    > From: Michael Richardson <mcr@sandelman.ottawa.on.ca>

    >> Yes, but... if you have a solution which works for 10^7 multi-homed
    >> houses, and works well, why bother to have a separate one for
    >> companies?

    > If we can find a way to multihome 10^7 sites using a single route-name,
    > then I'm all for it.

??? I never implied that any routing-based solution would allow all 10^7
sites to use a single routing-name.

Actually, we need to be a bit more precise here, because we are using the
term "routing-name" to mean both the name-including-location of individual
hosts, as well as the names for topology aggregates.

So I was thinking (using the terminology of a previous message) that all the
hosts in a particular set Sij of multihomed hosts would share an
aggregate-routing-name (ARN hereinafter). The chunk of topology (let's call
it the TA) referred to by that ARN would be grouped together with other
topologically close aggregates, i.e. topologically neighbouring groups (each
with their own ARN), and that collection (lets call it that TAA) given yet
another ARN (let's call it an AARN). Recurse as needed. :-)

The AARN would typically be one that allowed you to tell, simply from
inspecting an ARN and the AARN, that the TA (i.e. the aggregate named by the
ARN) was part of the TAA (i.e. the aggregate named by the AARN).

Some of the other TA's in that TAA might also be Sij's (other Sij's, of
course), but the TAA would almost certainly not be all Sij's - it would
probably include the local uni-homed hosts, the S0J's and Si0's, as well.


    > If the 10^7 can only be solved using your category (ii) solutions

I don't know which you're referring to here, since I used that numeration
scheme twice. (Perhaps I should have used different ones.)

But I think any of the approaches I laid out is probably viable in
*architectural* terms - provided the *engineering* is done competently!
Incompetent engineering will doom any approach: using the routing to track
10^7 hosts with flat addresses isn't going to work, but then again neither is
using a DNS-type multi-homing/mobility system with a single, big, central
server.

How you pick among the approaches, well that's hard - you have to look at
a) the costs and benefits of each architectural approach (e.g. using the
host's home address as its rendezvous for mobility purposes means that if
that part of the network goes offline, you can't reach the host), and b)
the costs and benefits of viable engineering solutions. For example:

My extensive comments on the routing stuff is simply intended to make clear
to people what the "envelope" (in the airplane performance sense) of the
viable engineering for routing-based approaches is.

Now, perhaps other non-technical factors will rule out the only approaches
which are viable in engineering terms. E.g. perhaps the providers won't
accept having to give up control over address allocation. If so, that means
all routing-based solutions to multi-homing/mobility are non-viable, so
you'd have to look elsewhere.


    > (In my mind, this means that applications need not be aware they are
    > multihomed, and some transport protocols would not care either)

That's a design decision - and a very important one - that people may well
decide is the right way to go. But I wasn't trying to decide on a particular
design, just trying to clarify what the choices were.

	Noel