[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initial issues
- To: itojun@iijlab.net
- Subject: Re: initial issues
- From: Christian Schild <ipng@uni-muenster.de>
- Date: Thu, 15 Feb 2001 08:37:29 +0100 (CET)
- Cc: multi6@ops.ietf.org
- Delivery-date: Wed, 14 Feb 2001 23:37:38 -0800
- Envelope-to: multi6-data@psg.com
- Organization: Westfaelische Wilhelms-Universitaet
Hi Itojun, all,
On 14-Feb-2001 itojun@iijlab.net wrote:
>
>>* There was a brief behind-the-scenes discussion, about the definition
>> of multihoming, which seemed to result in "being logically connected
>> to more than one TLA or NLA simultaneously".
>
> i guess there still are many different configurations possible.
> we need to define what "multihome" means in this mailing list.
>
> the following tries to summarize what we discussed in the past,
> in couple of occasions (incl, ipngwg tokyo interim meeting and japan-
> local multihome workshop).
>
> itojun
>
>
> who are you?
> - a SLA, or a leaf site (/48)
> - an NLA, or small ISP (/n, where n < 48)
> - a TLA, or big ISP (/16, /29-35 sTLA, or /24-28 pTLA)
>
> goals of multihoming
> - cope with L2 failures
> - cope with upstream ISP failures
> - load balancing, try to fill up two pipes we have toward upstream
> this needs more routing tricks.
> - whatever you name it (but shouldn't dream too much, we need a workable
> operational solution not a 20-year-to-deploy new protocol)
What about QoS balancing?
Consider a site with one cheap but narrow bandwidth upstream and a second
expensive but wide bandwidth upstream. To save money such a site would want
to use the wide one only if needed, e.g. videoconferencing and such, and the
cheaper one for everything else. I'm not sure if this is covered by 'load
balancing'.
Christian