One document matched: draft-stewart-bgp-without-as-00.txt
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
<draft-stewart-bgp-without-as-00.txt>
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-
Draft.
Abstract
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
removed.
- 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
USC/ISI
4350 North Fairfax Drive
Suite 620
Arlington, VA 22203
phone: +1 703 807 0132
email: jstewart@isi.edu
Enke Chen
MCI
2100 Reston Parkway
Reston, VA 20191
phone: +1 703 715 7087
email: enke@mci.net
Stewart & Chen [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 06:01:42 |