[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipngwg-ipv6-2260-00.txt
It would be unreasonable to take as accepted a requirements document
that is less than 4 days old, no matter its content.
--
Eliot Lear
lear@cisco.com
Ben Black wrote:
>
> This draft can also be found at:
>
> http://www.layer8.net/~ben/drafts/draft-black-multi6-requirements-00.txt
>
> Flame on.
>
> Ben
> Vijay
> Joe
>
> --
>
> Network Working Group B. Black
> Internet-Draft Layer8 Networks
> Expires: August 2, 2001 V. Gill
> J. Abley
> Metromedia Fiber Network Inc.
> February 2001
>
> Requirements for IP Multihoming Architectures
> draft-multi6-multihoming-requirements-00
>
> Status of this Memo
>
> This document is an Internet-Draft and is in full conformance with
> all provisions of Section 10 of RFC2026.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as
> Internet-Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other documents
> at any time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on August 2, 2001.
>
> Copyright Notice
>
> Copyright (C) The Internet Society (2001). All Rights Reserved.
>
> Abstract
>
> Multihoming is an essential component of service for autonomous
> systems connected to the Internet. The existing multihoming
> architecture is based on CIDR [1], which is predicated upon a
> hierarchy of service providers.
>
> However, it appears that this hierarchy is being supplanted by a
> dense mesh of interconnections [5]. Additionally, there has been an
> enormous growth in the number of multihomed organizations. For
> purposes of redundancy and load sharing, the multihomed customer
> blocks, which are almost always a longer prefix from the provider
>
> Black, et. al. Expires August 2, 2001 [Page 1]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> aggregate, are announced, along with the larger aggregate by the
> provider. This results in rapidly increasing size of the global
> routing table. This explosion places significant stress on both the
> routing protocols and the routing hardware.
>
> Migration to IPv6 with its greatly enlarged address space is likely
> to exacerbate the weaknesses in the existing system.
>
> This document outlines a set of requirements for new multihoming
> architectures to address weaknesses in the current, CIDR-based
> infrastructure.
>
> Black, et. al. Expires August 2, 2001 [Page 2]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> 1. Introduction
>
> Multihoming is an essential component of service for autonomous
> systems connected to the Internet. The existing multihoming
> architecture is based on CIDR [1], which is predicated upon a
> hierarchy of service providers.
>
> However, it appears that this hierarchy is being supplanted by a
> dense mesh of interconnections [5]. Additionally, there has been an
> enormous growth in the number of multihomed organizations. For
> purposes of redundancy and load sharing, the multihomed customer
> blocks, which are almost always a longer prefix from the provider
> aggregate, are announced, along with the larger aggregate by the
> provider. This results in rapidly increasing size of the global
> routing table. This explosion places significant stress on both the
> routing protocols and the routing hardware.
>
> Migration to IPv6 with its greatly enlarged address space is likely
> to exacerbate the weaknesses in the existing system.
>
> Black, et. al. Expires August 2, 2001 [Page 3]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> 2. Terminology
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [2].
>
> Black, et. al. Expires August 2, 2001 [Page 4]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> 3. Multihoming Requirements
>
> Multihoming is the connection of one autonomous system to multiple,
> other autonomous systems. This is done for reasons of service
> redundancy and reliability, and also for load-sharing.
>
> 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.
>
> Specific failure modes which must be protected against by any
> solution for site multihoming in IP networks include:
>
> o Physical link failure, such as a fiber cut or router failure,
>
> o Logical link failure, such as a misbehaving router interface,
>
> o Routing protocol failure, such as a BGP peer reset,
>
> o Service provider failure, such as a backbone-wide IGP failure, and
>
> o Exchange failure, such as a BGP reset on an inter-provider
> peering.
>
> Additionally, during failure events described above, multihoming
> solutions must provide re-routing transparency for applications;
> i.e. exchange of data between devices on the multi-homed network and
> devices elsewhere on the Internet may proceed with no greater
> interruption than transient packet loss during the re-routing event.
>
> 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.
>
> 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
>
> Black, et. al. Expires August 2, 2001 [Page 5]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> 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.
>
> 3.4 Cost
>
> A provider may choose to multihome for financial reasons. For
> example, customer C homed to ISP A may wish to shift traffic of a
> certain class or application, NNTP, for example, to ISP B because
> ISP B charges less for traffic. Any future multihoming proposals
> must provide support for multihoming for financial reasons.
>
> 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.
>
> 3.6 Simplicity and Scalability
>
> As any proposed multihoming solution must be deployed in real
> networks with real customers, simplicity is paramount. The current
> multihoming solution, despite its drawbacks, is quite
> straightforward to deploy and maintain.
>
> Unlike the current solution, however, new solutions must provide for
> scaling of the number of multihomed sites many orders of magnitude
> larger than are currently deployed. The limitations for scalability
> with the existing solution and current protocols are outlined in
> Section 4.
>
> Black, et. al. Expires August 2, 2001 [Page 6]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> 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
>
> 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.
>
> Black, et. al. Expires August 2, 2001 [Page 7]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> References
>
> [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
> Inter-Domain Routing (CIDR): an Address Assignment and
> Aggregation Strategy", RFC 1519, September 1993.
>
> [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
> Levels", RFC 2119, March 1997.
>
> [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
> Architecture", RFC 2373, July 1998.
>
> [4] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
> Global Unicast Address Format", RFC 2374, July 1998.
>
> [5] Huston, G., "Analyzing the Internet's BGP Routing Table",
> January 2001.
>
> Authors' Addresses
>
> Benjamin Black
> Layer8 Networks
>
> EMail: ben@layer8.net
>
> Vijay Gill
> Metromedia Fiber Network Inc.
> 8075 Leesburg Pike
> Suite 300
> Vienna, VA 22182
> US
>
> Phone: +1 410 262 0660
> EMail: vgill@mfnx.net
>
> Joe Abley
> Metromedia Fiber Network Inc.
> 2204 Pembroke Court
> Burlington, ON L7P 3X8
> Canada
>
> Phone: +1 905 319 9064
> EMail: jabley@mfnx.net
>
> Black, et. al. Expires August 2, 2001 [Page 8]
>
> Internet-Draft IP Multihoming Requirements February 2001
>
> Full Copyright Statement
>
> Copyright (C) The Internet Society (2001). All Rights Reserved.
>
> This document and translations of it may be copied and furnished to
> others, and derivative works that comment on or otherwise explain it
> or assist in its implementation may be prepared, copied, published
> and distributed, in whole or in part, without restriction of any
> kind, provided that the above copyright notice and this paragraph
> are included on all such copies and derivative works. However, this
> document itself may not be modified in any way, such as by removing
> the copyright notice or references to the Internet Society or other
> Internet organizations, except as needed for the purpose of
> developing Internet standards in which case the procedures for
> copyrights defined in the Internet Standards process must be
> followed, or as required to translate it into languages other than
> English.
>
> The limited permissions granted above are perpetual and will not be
> revoked by the Internet Society or its successors or assigns.
>
> This document and the information contained herein is provided on an
> "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
> MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
> Acknowledgement
>
> Funding for the RFC editor function is currently provided by the
> Internet Society.
>
> Black, et. al. Expires August 2, 2001 [Page 9]