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

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Mar 2004 08:49:00 +0200 (EET)

Hi,

As I mentioned in the meeting, I think there is a problem in
understanding the multihoming goals RFC, as evidenced by a couple of
solutions describing e.g., how they solve traffic engineering problem.
(That is, we're interested of *site* traffic engineering, not *node*
TE.)

Should we include a section in 
draft-lear-multi6-things-to-think-about which tries to briefly 
describe (again :) the actual goals of the multihoming goals RFC -- or 
should we just stick to asking a few pointed questions in 
draft-lear-... ?

Opinions?

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

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 9 Mar 2004 09:19:17 +0100

> should we just stick to asking a few pointed questions in

I think the pointed questions makes more sense. There is no point in 
using draft-lear to explain 3582.

- - kurtis -

---

From: Eliot Lear <[email-masked]>
Date: Tue, 09 Mar 2004 01:26:25 -0800

Hi Pekka,

I would not feel comfortable restating what is already written rather 
well.  It probably would cause more confusion than help.  Those who are 
actually doing the solutions should be aware of RFC 3582, and should 
have read it cover to cover and understood its context.  There's no 
substitute.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 2004 15:29:46 +0100

Eliot,

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.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Mar 2004 16:43:29 +0200 (EET)

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

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 10 Mar 2004 08:49:34 +0100

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

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