[plaintext] Requirements for IP Multihoming Architectures

["Jon (Taz) Mischo" <taz@tazlore.com>]

This should pull out the HTML tags.

-Taz

On Tue, 20 Mar 2001, Margaret Wasserman wrote:

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

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989