Re: multihoming goals and lear-multi6-things-to-think-about?

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 9 Mar 2004, Brian E Carpenter wrote:
> Agreed. Looking at some of the drafts, I had a strong impression
> that some authors had read the section headings in 3582, but
> not the details, which were thoroughly debated. As Kurtis said,
> let's concentrate on sharpening up the questions in your draft.

Totally agree here.  I guess the good question comes from whether we 
expect the user to fully understand nuances of the issues raised in 
3582 or not.

Two example questions:

y.y.y  Does the mechanism solve traffic engineering issues?

A significant multihoming benefit today is the ability obtain 
traffic-engineering (whether for load sharing, performance, or policy) 
benefits.  Does your solution solve these problems -- if so, how?  Is 
this control possible in an "aggregated" fashion, for the whole (or 
parts) of the site, or must it be done individually for each host?

x.x.x  Manageability of the mechanism at site level?

How is the site multihoming mechanism managed [RFC3582, 3.2.5]?  In
particular, does one have to manage each host individually, or is it 
possible to manage the mechanism in an "aggregated" fashion, for the 
whole site at a time?

... are these important enough to be added?  I think these two are the 
ones that have been misunderstood the most often -- and adding these 
in the "things to think aboug" -document migth help in catching the 
folks who didn't think of these issues at enough depth.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings