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

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> 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?

I actually think that you are asking several questions in one here. 
Shouldn't this be

y.y Aggregation of capabilities

A number of mechanisms can be applied 'per host', 'per site' or both. 
This part lists the mechanisms where this might have an impact on other 
systems or procedures.

y.y.1 Traffic Engineering

Traffic engineering can be applied for load-sharing, performance or 
policy. Can this be handled in an aggregate fashion? If so, how? If 
not, can it be different per each host? How is it implemented?

> 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.

I think we should add something on the aggregation capabilities for 
various parts of the solution. These two are a good start, and I am 
sure there are more.

So I think a

y.y.2 Manageability

would also be good...

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQE7IkqarNKXTPFCVEQI6oACg4n7ilpAnH6u9QIPlGtz0J2OP5vAAnj6h
BqMftiEpeqRH1s6Ydttqclks
=h2ut
-----END PGP SIGNATURE-----