draft-ietf-idr-symm-multi-prov-00.txt   draft-ietf-idr-symm-multi-prov-01.txt 
INTERNET-DRAFT Enke Chen INTERNET-DRAFT Enke Chen
<draft-ietf-idr-symm-multi-prov-00.txt> Tony Bates <draft-ietf-idr-symm-multi-prov-01.txt> Tony Bates
MCI Expires in six months MCI
May 1995 June 1995
Analysis and Critique of the Current Current Practice of Implementing
Practice of Implementing Symmetric Routing Symmetric Routing and Load Sharing
in the Multi-Provider Internet in the Multi-Provider Internet
<draft-ietf-idr-symm-multi-prov-00.txt> <draft-ietf-idr-symm-multi-prov-01.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 1, line 44 skipping to change at page 1, line 44
In the current multi-provider Internet, it is common for an entity to In the current multi-provider Internet, it is common for an entity to
have multiple service providers. Symmetric routing becomes have multiple service providers. Symmetric routing becomes
increasingly important for various reasons. This memo documents and increasingly important for various reasons. This memo documents and
analyzes the current practice in implementing symmetric inter-domain analyzes the current practice in implementing symmetric inter-domain
routing using BGP for several representative topologies of Internet routing using BGP for several representative topologies of Internet
connections. connections.
1. Introduction 1. Introduction
In the multi-provider Internet, it is common for an entity to have In the multi-provider Internet, it is common for an entity to have
multiple service providers. These connections would provide for the multiple connections to the Internet. For example,
capability of load sharing, path diversification and backup. o A Regional Service Provider (RSP) may be connected to multiple
transit Internet Service Providers (ISPs).
o A service subscriber may be connected to multiple RSPs or ISPs.
o Subscribers of different providers may wish to backup each
other.
These connections would provide for the capability of load sharing,
path diversification and backup. The Internet is a mesh of ISPs,
RSPs and service subscribers and is generally sparsely connected.
Symmetric routing is generally preferred as it facilitates problem Symmetric routing is generally preferred as it facilitates problem
resolution, and provides for better resource (especially network resolution, and provides for better resource (especially network
capacity) planning and utilization. Routing symmetry is also capacity) planning and utilization. Routing symmetry is also desir-
desirable in achieving optimal traffic flow in terms of reliability, able in achieving optimal traffic flow in terms of reliability, delay
delay character, cost and other QoS metrics. In the multi-provider character, cost and other QoS metrics. Several applications such as
Internet, routing asymmetry, especially at the inter-domain level, NTP, RSVP and MBONE rely upon routing symmetry. In the multi-
could have serious economic and legal ramifications. provider Internet, routing asymmetry, especially at the inter-domain
level, may have serious economic and legal ramifications.
This paper presents several representative topologies of Internet This paper presents several representative topologies of Internet
connection and their inter-domain routing requirements. It then connection and their inter-domain routing requirements. It then doc-
documents and analyzes the current practice in implementing symmetric uments and analyzes the current practice in implementing symmetric
inter-domain routing in these cases using BGP. inter-domain routing in these cases using BGP.
This paper assumes that in general an ISP treats other ISPs equally This paper assumes that in general an ISP treats other ISPs equally
(in terms of the "local_pref" parameter) in the route selection (in terms of the "local_pref" parameter) in the route selection pro-
process. It also assumes that the following order of preference is cess. It also assumes that the following order of preference is fol-
followed for the purpose of route selection: first the "local_pref" lowed for the purpose of route selection: first the "local_pref"
parameter, followed by the shortest AS-path, the MED, and the IGP parameter, followed by the shortest AS-path, the MED, and the IGP
metric. metric.
It is noted that the length of the AS-path has not been specified in It is noted that the length of the AS-path has not been specified in
the BGP document [1] as a route selection criteria. However, it has the BGP document [1] as a route selection criteria. However, it has
been included in more than one implementations, and has been widely been included in more than one implementations, and has been widely
used as such. used as such.
2. Internet Connection and Routing 2. Internet Connection and Routing
The Internet is a mesh of transit Internet Service Providers (ISPs), The Internet is a mesh of transit Internet Service Providers (ISPs),
Regional Service Providers (RSPs), and service subscribers. In Regional Service Providers (RSPs), and service subscribers. In gen-
general this mesh is rather sparsely connected with loose hierarchy. eral this mesh is rather sparsely connected with loose hierarchy. In
In the multi-provider Internet, a good routing plan for an entity the multi-provider Internet, a good routing plan for an entity (i.e.,
(i.e., autonomous system) requires good understanding of its internal autonomous system) requires good understanding of its internal net-
network topology, its connection to direct providers (and neighboring work topology, its connection to direct providers (and neighboring
ASs), and its path to the major interconnection points (or network ASs), and its path to the major interconnection points (or network
access points, NAPs). access points, NAPs).
In this section, we present several typical topologies of Internet In this section, we present several typical topologies of Internet
connections, and their inter-domain routing requirements. Although connections, and their inter-domain routing requirements. Although
these cases are not meant to be exhaustive, they are expected to these cases are not meant to be exhaustive, they are expected to
cover the vast majority of Internet connection topologies. cover the vast majority of Internet connection topologies.
2.1 An Entity with a Single Direct Provider 2.1 An Entity with a Single Direct Provider
skipping to change at page 4, line 35 skipping to change at page 4, line 35
+------+ +------+ +------+ +------+
| AS1 |------| AS2 | | AS1 |------| AS2 |
+------+ +------+ +------+ +------+
(a) (b) (c) (a) (b) (c)
Figure 2 Figure 2
Note that in Figures 2(a)-2(b), AS1 and AS2 could be RSPs. Note that in Figures 2(a)-2(b), AS1 and AS2 could be RSPs.
In all cases of Figure 2, in order to provide for backup, AS1 needs In all cases of Figure 2, in order to provide for backup, AS1 shall
to receive AS2's routes from both AS2 and its direct provider, and permit the acceptance of AS2's routes from both AS2 and AS1's direct
permit their announcements to its direct providers. Similar provider, and permit their announcements to its direct providers.
configuration is required for AS2. Similar configuration is required for AS2.
There are two common routing policies depending upon how the link There are two common routing policies depending upon how the link
between AS1 and AS2 is used. between AS1 and AS2 is used.
Policy 1: Used solely as a backup link Policy 1: Used solely as a backup link
The routing policy can be implemented by coordinating AS-based The routing policy can be implemented by coordinating AS-based
"local_pref" values between neighboring ASs. "local_pref" values between neighboring ASs.
In all cases of Figure 2, the "local_pref" value for the peer of In all cases of Figure 2, the "local_pref" value for the peer of
skipping to change at page 9, line 47 skipping to change at page 9, line 47
o The number of ASs that need to be preprended is in general o The number of ASs that need to be preprended is in general
proportional to the number of direct providers. proportional to the number of direct providers.
o Compatibility with other BGP implementation may be a problem. o Compatibility with other BGP implementation may be a problem.
3.2 Splitting AS 3.2 Splitting AS
This approach requires an AS to be split into multiple ASs and run This approach requires an AS to be split into multiple ASs and run
external BGP between these ASs (possibly with MEDs configured for external BGP between these ASs (possibly with MEDs configured for
load balancing among multiple links). Then the cases in Figure 3 can load balancing among these ASs). Then the cases in Figure 3 can be
be reduced to the cases in Figure 2, which have been discussed in reduced to the cases in Figure 2, which have been discussed in Sec-
Section 2. tion 2.
This is probably the cleanest approach the current BGP version can This is probably the cleanest approach the current BGP version can
offer. However, there is a great deal of reluctance in using this offer. However, there is a great deal of reluctance in using this
approach. Practical problems with this approach include: approach. Practical problems with this approach include:
o It does not work with the partial load-sharing case where the
connections to multiple providers originate from one router.
o Splitting ASs and having them maintained could be quite o Splitting ASs and having them maintained could be quite
involved depending upon the internal network topology. involved depending upon the internal network topology.
o Extra AS numbers are required [7]. It would be necessary to o Extra AS numbers are required [7]. It would be necessary to
apply for AS numbers at the InterNIC. apply for AS numbers at the InterNIC.
o The number of split ASs is proportional to the number of
direct providers.
o Wasting of AS numbers. The exhaustion of the AS number space o Wasting of AS numbers. The exhaustion of the AS number space
could become real with the ever-increasing number of such could become real with the ever-increasing number of such
needs. needs.
o The increased number of ASs would add complexity to the Inter- o The increased number of ASs would add complexity to the Inter-
net topology, and therefore complicate problem resolution. net topology, and therefore complicate problem resolution.
o An AS number has been traditionally tied to an organization. o An AS number has been traditionally tied to an organization.
Splitting AS means loss of coherence for some customers. Splitting AS means loss of coherence for some customers.
skipping to change at page 10, line 37 skipping to change at page 10, line 43
This is the approach that has been used for the NSFNET. Here is how This is the approach that has been used for the NSFNET. Here is how
it is done with Figure 3(a). ISP1 and ISP2 configure net-based pref- it is done with Figure 3(a). ISP1 and ISP2 configure net-based pref-
erence on their routers, according to preference provided by AS1. erence on their routers, according to preference provided by AS1.
For example, for route X, ISP1 would configure higher preference for For example, for route X, ISP1 would configure higher preference for
its direct link with AS1, and lower preference for its direct link its direct link with AS1, and lower preference for its direct link
with ISP2. with ISP2.
This approach requires NRLI-based customization with the direct This approach requires NRLI-based customization with the direct
providers and sometimes indirect providers as well as the originating providers and sometimes indirect providers as well as the originating
AS. The NSFNET configuration experience has shown that this approach AS. The NSFNET configuration experience has shown that this approach
requires non-trivial administrative coordination, and it places a requires non-trivial administrative coordination and full topology
burden on routers with limited memory capacity. For these reasons, information. In addition, it places a burden on routers with limited
the NLRI-based preference configuration should be avoided at the memory capacity. For these reasons, the NLRI-based preference con-
provider level if possible. Instead, such a configuration should be figuration should be avoided at the provider level if possible.
pushed as close to the originating AS as possible. Instead, such a configuration should be pushed as close to the origi-
nating AS as possible.
3.4 Perfect Aggregation and Addressing
In the cases that all routes in the AS are covered by an aggregate
and address assignment is completely consistent with the network
topology, the rule of the longest prefix match can be used to help
achieve routing symmetry and load sharing. That is, a portion of the
aggregate, along with the aggregate itself, can be announced to one
direct provider. The remaining portion of the aggregate, along with
the aggregate itself, can be announced to the other direct provider.
It does not work with the partial load-sharing case where the connec-
tions to multiple providers originate from one router. More impor-
tantly, the requirement of this approach is not likely to be met in
practice. So, this approach is listed just for the sake of complete-
ness.
4. Discussion 4. Discussion
As has been illustrated in Section 3, it is not easy to implement As has been illustrated in Section 3, it is not easy to implement
routing symmetry for an entity with multiple direct providers using routing symmetry and load sharing for an entity with multiple direct
the current functionality of BGP. There are many drawbacks with the providers using the current functionality of BGP. There are many
current practice of implementation. Even the implementation of the drawbacks with the current practice of implementation. Even the
AS-based "local_pref" parameter can sometimes be quite involved. The implementation of the AS-based "local_pref" parameter can sometimes
difficulty is caused by the lack of a globally transitive preference be quite involved. The difficulty is caused by the lack of a glob-
an AS (with multiple direct providers) can specify, and be used in ally transitive preference an AS (with multiple direct providers) can
the route selection process. specify, and be used in the route selection process.
An Multi-Provider Preference (MPP) attribute is proposed [3] for the A new BGP attribute termed "Destination Preference Attribute" (DPA)
purpose of facilitating the implementation. As illustrated in [4], has been proposed in [3] to address such need. As illustrated in
the routing policies presented in Section 2 can be implemented with [4], the routing policies presented in Section 2 can be implemented
ease by using the MPP attribute. In particular, only the AS that with ease by using the DPA attribute. In particular, only the AS
originates this preference needs to specify this preference on a per- that originates this preference needs to specify this preference on a
route basis. per-route basis.
5. Security Considerations 5. Security Considerations
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Roy Alcala, Dennis Ferguson, John The authors would like to thank Roy Alcala, Dennis Ferguson, John
Stewart, and Jack Waters of MCI for the many interesting hallway dis- Stewart, and Jack Waters of MCI for the many interesting hallway dis-
cussions related to this work. We also acknowledge Sean Doran of cussions related to this work. We also acknowledge helpful comments
Sprint as the first person (to the authors knowledge) to make use of and suggestions by Yakov Rekhter of Cisco.
the AS path manipulation technique.
7. References 7. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995. RFC1771, March 1995.
[2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro- [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro-
tocol in the Internet", RFC1772, March 1995. tocol in the Internet", RFC1772, March 1995.
[3] Chen, E., and Bates, T., "Multi-Provider Preference Attribute for [3] Chen, E., and Bates, T., "Destination Preference Attribute for
BGP", INTERNET-DRAFT, <draft-ietf-idr-bgp-mpp-00.txt>, April 1995. BGP", INTERNET-DRAFT, <draft-ietf-idr-bgp-dpa-01.txt>, June 1995.
[4] Chen, E., and Bates, T., "Application of the BGP Multi-Provider [4] Chen, E., and Bates, T., "Application of the BGP Destination
Preference Attribute in Implementing Symmetric Routing", INTERNET- Preference Attribute in Implementing Symmetric Routing", INTERNET-
DRAFT, <draft-ietf-idr-mpp-application-00.txt>, April 1995. DRAFT, <draft-ietf-idr-dpa-application-01.txt>, June 1995.
[5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, <draft-ietf- [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, <draft-ietf-
idr-bgp-metrics-00.txt>, March 1995. idr-bgp-metrics-00.txt>, March 1995.
[6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787,
April 1995. April 1995.
[7] Hawkinsin, J., and Bates, T., "Guidelines for creation, selec- [7] Hawkinsin, J., and Bates, T., "Guidelines for creation, selec-
tion, and registration of an Autonomous System (AS)", INTERNET-DRAFT, tion, and registration of an Autonomous System (AS)", INTERNET-DRAFT,
<draft-ietf-idr-autosys-guide-03.txt>, May 1995. <draft-ietf-idr-autosys-guide-03.txt>, May 1995.
8. Author's Addresses 8. Author's Addresses
Enke Chen Enke Chen
MCI MCI
2100 Reston Parkway 2100 Reston Parkway
Reston, VA 22094 Reston, VA 22091
phone: +1 703 715 7087 phone: +1 703 715 7087
email: enke@mci.net email: enke@mci.net
Tony Bates Tony Bates
MCI MCI
2100 Reston Parkway 2100 Reston Parkway
Reston, VA 22094 Reston, VA 22091
phone: +1 703 715 7521 phone: +1 703 715 7521
email: Tony.Bates@mci.net email: Tony.Bates@mci.net
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/