Re: Requirements for IP Multihoming Architectures

[Margaret Wasserman <mrw@windriver.com>]

Hi Ben,

Good job on the requirements document.

However, I think that it should include more information regarding
the
scope of the problem that the WG should be trying to solve.  Do
we
want to handle all issues concerned with any site (or AS) having
multiple points of connection to the IPv6 Internet?  Or only deal
with
mechanisms that ensure connectivity of multi-homed sites in the
event
of some type of failure?

I also have some questions on the requirements draft, included
below.

> 3.2 Load Sharing
>
>    Load sharing is distributing traffic across multiple links.
> Reasons
>    for load sharing include but are not limited to: 
>
>    o  Performance,
>
>    o  Cost, and
>
>    o  Availability of Infrastructure.

What are the actual requirements in this area?  Do we require that
all 
site multihoming solutions support load sharing, as described? 
What
types of load sharing decisions do we need to support?

 From discussion on the list, there seems to be come consensus that
customers expect load sharing when they purchase connectivity from 
more than one site.  But, are the mechanisms to provide that
load
sharing something that this WG will discuss/develop/promote?


> 3.3 Performance
>
>    One of the reasons for multihoming with two providers is
> poor
>    connectivity between them. For example, customer C is buying
> transit
>    from ISP A, and there is long term congestion between ISP A
> and ISP
>    B. To improve connectivity to ISP B, customer C buys transit
> from
>    ISB B, thus bypassing the congestion and improving the
> performance
>    between C and ISP A. 
>
>    Some operators have requirements to provide different grades
> of
>    connectivity to customers based on network reach, and
> achieve this
>    objective by grouping customers of similar service grades
> together,
>    and advertising their networks over separate transit
> circuits. The
>    result is multihoming for the purpose of transit
> capacity
>    segregation.

I am also uncertain what the requirements are in this area.  

It seems obvious that while both (or all) connections are working, the
routing system should be able to choose the best (by any definition)
route 
for the outgoing traffic.  However, maximizing performance in
this
situation (i.e. picking the "right" best route) is more of a
general
routing question than a multihoming question, isn't it?

> 3.5 Availability of Infrastructure
>
>    Sometimes it is not possible to increase transit capacity to
> a
>    single provider, because that provider does not have
> sufficient
>    spare capacity to sell. In this case a solution is to
> acquire
>    additional transit capacity through a different provider.
> This
>    scenario is common in bandwidth-starved stubs of the network
> where,
>    for example, transit demand outpaces under-sea cable
> deployment.

On a similar note, what are the requirements in this area? 
Obviously,
it won't help for a multi-homing solution to "fail-over" to
exclusively
using a provider that doesn't have sufficient bandwidth to handle
the
load.  Is there a requirement, then, that we be able to fail-over
the
highest priority traffic?  Or what?

> 4. Overview of the Current Architecture
>
> 4.1 Motivations for CIDR-Based Site Multihoming
>
>    The CIDR-based solution currently deployed meets most of
> the
>    requirements defined in Section 3, but also provides the
> following
>    features: 
>
>    o  Conceptually simple

I think that this is one of the requirements in Section 3.


>    o  Fine-grained policy
> control for multihomed sites
>
> 4.2 Drawbacks of CIDR-Based Site Multihoming
>
>    When a site multi-homes, one or more additional prefixes
> are
>    introduced into the global BGP table.  If the site
> uses
>    provider-aggregatable addresses, then upstreams may need
> to
>    advertise both the aggregate and the more specific route,
> resulting
>    in super-linear growth of the default-free zone. 
>
>    Concern over prefix-table growth in the default-free zone is
> leading
>    at least one large provider to filter advertisements
> received from
>    peers on the basis of allocation boundaries, such that
> long-prefix
>    provider-aggregatable prefixes are denied transit across
> that
>    provider's network. If this approach becomes more
> widespread, the
>    ability to multi-home effectively will become restricted to
> those
>    networks who have sufficient addressing requirements to
> justify a
>    provider-independent allocation.
>
>    Furthermore, increasing numbers of multihomed sites
> accelerates the
>    growth in the number of distinct paths for a given prefix in
> the
>    default-free zone.  This causes a significant increase
> in the
>    convergence time for BGP after network changes.  This
> issue is
>    discussed in great detail in [5].
>
>    Although conceptually simple, this approach does not lend
> itself
>    well to troubleshooting of inter-AS network
> pathologies.  The
>    opacity of policy interaction between ASes in the network
> can hide
>    numerous, unpredictable path selection
> behaviors.

So, is it a requirement that the IPv6 multihoming architecture 
address one or all of these points?

Thanks,
Margaret