Hi.
1. Whilst it is possible to do multihoming/multiattaching in a DFZ friendly way through a single provider, it would clearly be better if the solutions proposed addressed both cases in a similar way rather than having two totally separate solutions. Also, load balancing even to a single provider is still difficult to achieve.
2. Redundancy is illusory without getting into the 'shared fate' considerations which are currently exercising the IPO working group. If your multiple connections end up running in a single duct that gets back hoed all your hard work goes for nothing.
Regards,
Elwyn Davies
> -----Original Message-----
> From: Joe Abley [mailto:jabley-ietf@automagic.org]
> Sent: 20 March 2001 16:45
> To: Jun-ichiro itojun Hagino
> Cc: Ben Black; multi6@ops.ietf.org
> Subject: Re: Requirements for IP Multihoming Architectures
>
>
> On Wed, Mar 21, 2001 at 12:46:34AM +0900, Jun-ichiro itojun
> Hagino wrote:
> > >3.1 Redundancy
> > >
> > > By obtaining transit through more than one provider, a
> network can
> > > insulate itself from certain failure modes of one or
> more providers,
> > > as well as failures within layer 1 and layer 2 infrastructure.
> >
> > it looks to me that we should cover "multiple connectivity to
> > a single provider", like to different NOCs/routers.
>
> Multi-attaching to the same provider is a simplified case of the
> general cidr multi-homing technique, which doesn't suffer from:
>
> + contribution to AS exhaustion (private-use ASNs can be used)
>
> + path or prefix bloat (the prefixes announced by the multi-homing
> site can be aggregated by the single provider)
>
> However, it also doesn't fully satisfy the stated requirements, which
> included the requirement to protect against routing anomolies in a
> single autonomous system; the exact text describing the failure mode
> is:
>
> o Service provider failure, such as a backbone-wide IGP
> failure, and
>
> It might be worthwhile spelling this out in the draft, I guess.
>
>
> Joe
>
>
>