Fwd: Re: Requirements for IP Multihoming Architectures

[Margaret Wasserman <mrw@windriver.com>]

Sorry -- my mailer was apparently misconfigured.  Here is a resend of
my message in plain text.

Margaret


 >Date: Tue, 20 Mar 2001 18:19:13 -0500
 >To: multi6@ops.ietf.org
 >From: Margaret Wasserman <mrw@windriver.com>
 >Subject: Re: Requirements for IP Multihoming Architectures
 >
 >
 >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