[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                John W. Stewart, III / ISI
<draft-stewart-bgp-without-as-00.txt>                    Enke Chen / MCI
                                                            January 1997
                                                    Expire in six months

                 Using BGP Without Consuming a Unique ASN

Status of this Memo

   This document is an Internet-Draft. 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.  Internet-Drafts may be updated, replaced or obsoleted by
   other documents at any time. It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the abstract listing contained in each Internet-Draft
   directory to learn the current status of this or any other Internet-


   The number of organizations that have more than one Internet
   connection is increasing significantly with time.  In a substantial
   number of these cases, an organization's multiple connections are
   from the same ISP; this type of multi-homing is localized to the
   organization and its single provider, so a globally unique ASN should
   not be needed.  However, many ISPs can only support their customers'
   reliability and load-sharing requirements by using BGP, which DOES
   require an ASN.  Since the needs of the ISP and its multi-homed
   customer are contrary to the Internet's need to allocate the ASN
   space sensibly, this is a problem.  A solution to this problem has
   been proposed which makes use of private ASNs, but it has several
   disadvantages.  This paper documents the existing solution and
   describes its disadvantages, then presents another solution which
   doesn't share the same disadvantages.

Stewart & Chen                                                  [Page 1]

INTERNET-DRAFT   BGP For Load-Sharing Without Unique AS     January 1997

1.  Introduction

   With the increased commercial use of the Internet, there has been an
   increase in the number of organizations with more than one Internet
   connection.  This document explicitly does NOT apply to cases where
   the multiple connections are from different Internet Service
   Providers (ISPs).

   In a case where the multiple connections are from the same ISP,
   because those multiple connections are "localized" to the ISP and its
   customer, the rest of the routing system doesn't need to see routing
   information for that organization any differently than a singly-
   connected organization.  In other words, with respect to the rest of
   the routing system the organization is singly-connected, so the
   complexity of the multiple connections is not relevant in a global
   sense.  Autonomous System Numbers (ASNs) are administrative
   identifiers used in routing protocols and are needed by routing
   domains which are bona fide members of the global routing system.
   Because organizations with multiple connections to the same ISP are
   tail networks with respect to the global routing mesh, these sites do
   not need a unique ASN.  This is architecturally clean and it
   preserves the finite ASN space (a two-octet value).

   Despite the fact that these organizations don't need a unique ASN
   with respect to the Internet routing system, many ISPs can only
   support the load-sharing and reliability requirements of a multi-
   homed customer if that customer exchanges routing information with
   the Border Gateway Protocol Version 4 (BGP4), which DOES require an
   ASN.  The number of organizations that have multiple connections to a
   single provider is significant and growing over time, so solving this
   problem of competing needs could represent a significant savings in
   the use of the ASN space while at the same time fulfilling the users'
   needs of reliability and load-sharing.

   This document describes an existing solution to the problem along
   with some of the disadvantages of that approach when used by globally
   unique ASs.  Later sections present another solution which doesn't
   share the same disadvantages along with some of the implications of
   that solution.

2.  Using "Private ASN" Space

   The existing solution proposed to this problem thus far is one which
   involves the use of ASNs 64512-65535 by organizations multi-homed to
   a single ISP.  (These ASNs were allocated for private use by the
   Internet Assigned Numbers Authority (IANA) in RFC1930.)
   Specifically, each ISP has the entire range of private ASN space

Stewart & Chen                                                  [Page 2]

INTERNET-DRAFT   BGP For Load-Sharing Without Unique AS     January 1997

   available to it to assign to customers multi-homed only to them.  An
   ISP peers with this type of customer using a private ASN, so it
   carries that AS within its Internal-BGP (IBGP) mesh.  However, the
   ISP's border routers strip the private ASs from the AS-path when the
   routes are advertised to External BGP neighbors.

   Note that a responsible provider would explicitly inform customers of
   this type that the ASN they have been delegated is purely for use
   between their two ASs and that if that customer (1) changes providers
   or (2) acquires another connection to the Internet, then that
   customer's network may need to be reconfigured with a different ASN.

   The end result is that, because BGP is being used, the ISPs are able
   to support their customers' load-sharing requirements.  However, the
   pool of unique ASNs is not affected (because private ASNs are used)
   and the rest of the routing system does not see the complexity of
   multi-homing (because ISPs remove the private ASs from the AS-path
   before further advertising the routes into the routing system).

   While this approach does address the problem, we feel that there are
   several disadvantages.

      - First, although the ASN used by a customer multi-homed to a
        single ISP does not have to be GLOBALLY unique, it DOES have
        to be unique within the scope of the ISP.  This requires that
        ISPs create new systems to track the delegation of the private
        ASN space.

      - Second, although the number of private ASNs allocated is
        reasonably large, it does not scale to an arbitrary number of
        these types of customers.

      - Third, and perhaps most operationally significant in the
        Internet of today, the work of stripping the private ASs from
        the AS-path needs to be done on already-busy routers (i.e.,
        edge routers which connect to customers and to other providers).

      - Fourth, in the event of an implementation problem or a
        misconfiguration with stripping the private ASs from the
        AS-path, those routes could be subject to filtering elsewhere
        in the routing system (e.g., similar to the common filtering of
        RFC1597's private address space).

      - Fifth, if the ISP's customer breaks the agreement and acquires
        another connection to the Internet without acquiring a new ASN,
        the possibility of looping routing announcements exists
        because some of the AS-path (the mechanism to detect loops) has
        been removed.

Stewart & Chen                                                  [Page 3]

INTERNET-DRAFT   BGP For Load-Sharing Without Unique AS     January 1997

   Note well that while we do not suggest using the mechanism described
   above in a transit AS, there are instances where it is appropriate.
   An example of such an instance is an organization which wants to main
   administrative boundaries within its routing domain but look like a
   single AS to the rest of the Internet's routing system.  For this
   reason (as well as the simplest case of a completely disconnected
   internet), the IANA's allocation of the ASNs for private use was good
   and useful.

3.  Using a Dedicated ASN

   Instead of using private ASN space, we propose that an ISP take a
   SINGLE ASN which has been assigned to it and use it for all of its
   customers multiply connected just to it.  For example, if MCI was
   assigned the ASN 4293, and companies Foo and Bar both have
   connections to MCI (but no other provider), then MCI would instruct
   both Foo and Bar to use ASN 4293 in their BGP configurations.

   Logically, this plan results in a provider having many peers with the
   same AS, although that AS exists in "islands" completely disconnected
   from one another.

   This plan satisfies the two requirements:  namely that (1) the
   provider and its customer are able to use BGP for load-sharing and
   reliability (2) while not having to consume a unique ASN for each of
   its customers. This plan does not have the same disadvantages of the
   first proposal.

      - First, ISPs do not have to track the delegation of private
        address space, since all of its customers would use the same AS.

      - Second, there is no limit to the number of customers which an
        ISP could configure using this scheme.

      - Third, it is not necessary for any routers to do any extra work
        to remove ASNs from the AS-path.

      - Fourth, because the AS being used is perfectly valid to be seen
        in the global routing system, the possibility of filtering is

      - Fifth, because the complete AS-path is left in tact, looping is
        no more likely than today.

   The disadvantage of this approach is that the customer multiply-
   connected to the single ISP cannot receive true full routing.  The
   reason for this is that, although the specification allows it, in all

Stewart & Chen                                                  [Page 4]

INTERNET-DRAFT   BGP For Load-Sharing Without Unique AS     January 1997

   current implementations of BGP, ASN x will not accept a route over an
   external BGP session if ASN x is already in the AS-path.  So to be
   specific, under this proposal a customer multi-homed to an ISP who
   requested "full routes" would NOT hear routes from other customers
   using the same dedicated ASN.  A result of this is that these types
   of customers would have to carry a default route.  We do not view
   this as a significant disadvantage, though, because if the customer
   is connected only to a single provider they should not need true full
   routes.  A customer of this type MAY want to take something close to
   full routes for the sake of load-sharing (e.g., to hear MULTI-EXIT-
   DISCRIMINATORS), but it is not necessary to hear 100% of full routes
   for this and hearing a large percentage of the routes is adequate.

   Two additional observations can be made about this approach.  First,
   it is possible to merge these two approaches and use a private ASN as
   the dedicated ASN.  We do not recommend this, however, because if the
   ASN is stripped from the AS-path then the "extra work on busy
   routers" disadvantage applies, but if the ASN is not stripped the
   "possibility of filtering" disadvantage applies.  The second
   observation is that it is possible for ALL providers to use the SAME
   dedicated ASN.  This has the advantage of consuming even fewer ASNs
   and also allows customers to move from one provider to another
   without reconfiguring their ASN (though it is still required that
   they be connected to ONLY ONE provider).  This is worth serious
   consideration in the future; we are not proposing it at this point,
   however, because there is not yet enough wide-scale operational
   experience with our proposed solution.

4.  Implications

4.1.  Change of External Connectivity

   As noted several times earlier, if an organization that was once
   multi-homed to a single provider and used that provider's dedicated
   ASN changes its external connectivity, then it may be necessary for
   them to reconfigure their network to use a different ASN (either a
   globally unique one or a dedicated ASN of a different provider).  For
   this reason, organizations (particularly ones with a large number of
   routers) that know they will eventually be multi-homed to more than
   one ISP are encouraged to seek a globally unique ASN from the
   beginning in order to avert a large-scale configuration change.

4.2.  Issues Related to Routing Registries

   The registration of routes in the Internet Routing Registry (IRR) by
   an organization with multiple connections to a single ISP is not
   special.  Specifically, a route is registered with the appropriate

Stewart & Chen                                                  [Page 5]

INTERNET-DRAFT   BGP For Load-Sharing Without Unique AS     January 1997

   ASN as origin, and whether or not that ASN is being used by other
   organizations doesn't matter.  One thing that IS different in these
   cases is related to route filtering:  the way that an ISP selects
   routes from the IRR to build the list to accept from its BGP
   customer.  In general, the selection of routes from the IRR is based
   on origin AS.  This process WOULD WORK for customers multi-homed to a
   single provider, but the list of routes would be a super-set of those
   needed.  The reason for this is that the list would contain ALL
   routes registered by ALL customers using the dedicated ASN.  This
   effectively reduces the control which is the point of route
   filtering, so it needs to be fixed.  The simplest fix is to change
   the code which generates the list of routes to include the feature of
   matching on origin ASN AND "mntner" name.

5.  Security Considerations

   Security considerations are not discussed in this memo.

6.  Acknowledgments

   The authors would like to thank Roy Alcala of MCI for a number of
   interesting hallway discussions related to this work.

7.  References

   [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
   RFC1771, March 1995.

   [2] Rekhter, Y., and Gross, P., "Application of the Border Gateway
   Protocol in the Internet", RFC1772, March 1995.

   [3] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787,
   April 1995.

   [4] Hawkinson, J., and Bates, T., "Guidelines for creation,
   selection, and registration of an Autonomous System (AS)", RFC1930,
   March 1996.

   [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
   M. Terpstra, & J. Yu., "Representation of IP Routing Policies in a
   Routing Registry (ripe-81++)", RFC1786, March 1995.

Stewart & Chen                                                  [Page 6]

INTERNET-DRAFT   BGP For Load-Sharing Without Unique AS     January 1997

8.  Author's Addresses

   John Stewart
   4350 North Fairfax Drive
   Suite 620
   Arlington, VA  22203
   phone: +1 703 807 0132
   email: jstewart@isi.edu

   Enke Chen
   2100 Reston Parkway
   Reston, VA  20191
   phone: +1 703 715 7087
   email: enke@mci.net

Stewart & Chen                                                  [Page 7]