--- 1/draft-ietf-idr-symm-multi-prov-00.txt 2006-02-04 23:31:53.000000000 +0100 +++ 2/draft-ietf-idr-symm-multi-prov-01.txt 2006-02-04 23:31:53.000000000 +0100 @@ -1,20 +1,20 @@ INTERNET-DRAFT Enke Chen - Tony Bates - MCI - May 1995 + Tony Bates +Expires in six months MCI + June 1995 - Analysis and Critique of the Current - Practice of Implementing Symmetric Routing + Current Practice of Implementing + Symmetric Routing and Load Sharing in the Multi-Provider Internet - + 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 @@ -33,56 +33,67 @@ In the current multi-provider Internet, it is common for an entity to have multiple service providers. Symmetric routing becomes increasingly important for various reasons. This memo documents and analyzes the current practice in implementing symmetric inter-domain routing using BGP for several representative topologies of Internet connections. 1. Introduction In the multi-provider Internet, it is common for an entity to have - multiple service providers. These connections would provide for the - capability of load sharing, path diversification and backup. + multiple connections to the Internet. For example, + 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 resolution, and provides for better resource (especially network - capacity) planning and utilization. Routing symmetry is also - desirable in achieving optimal traffic flow in terms of reliability, - delay character, cost and other QoS metrics. In the multi-provider - Internet, routing asymmetry, especially at the inter-domain level, - could have serious economic and legal ramifications. + capacity) planning and utilization. Routing symmetry is also desir- + able in achieving optimal traffic flow in terms of reliability, delay + character, cost and other QoS metrics. Several applications such as + NTP, RSVP and MBONE rely upon routing symmetry. In the multi- + 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 - connection and their inter-domain routing requirements. It then - documents and analyzes the current practice in implementing symmetric + connection and their inter-domain routing requirements. It then doc- + uments and analyzes the current practice in implementing symmetric inter-domain routing in these cases using BGP. This paper assumes that in general an ISP treats other ISPs equally - (in terms of the "local_pref" parameter) in the route selection - process. It also assumes that the following order of preference is - followed for the purpose of route selection: first the "local_pref" + (in terms of the "local_pref" parameter) in the route selection pro- + cess. It also assumes that the following order of preference is fol- + lowed for the purpose of route selection: first the "local_pref" parameter, followed by the shortest AS-path, the MED, and the IGP metric. 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 been included in more than one implementations, and has been widely used as such. 2. Internet Connection and Routing The Internet is a mesh of transit Internet Service Providers (ISPs), - Regional Service Providers (RSPs), and service subscribers. In - general this mesh is rather sparsely connected with loose hierarchy. - In the multi-provider Internet, a good routing plan for an entity - (i.e., autonomous system) requires good understanding of its internal - network topology, its connection to direct providers (and neighboring + Regional Service Providers (RSPs), and service subscribers. In gen- + eral this mesh is rather sparsely connected with loose hierarchy. In + the multi-provider Internet, a good routing plan for an entity (i.e., + autonomous system) requires good understanding of its internal net- + work topology, its connection to direct providers (and neighboring ASs), and its path to the major interconnection points (or network access points, NAPs). In this section, we present several typical topologies of Internet connections, and their inter-domain routing requirements. Although these cases are not meant to be exhaustive, they are expected to cover the vast majority of Internet connection topologies. 2.1 An Entity with a Single Direct Provider @@ -129,24 +140,24 @@ +------+ +------+ | AS1 |------| AS2 | +------+ +------+ (a) (b) (c) Figure 2 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 - to receive AS2's routes from both AS2 and its direct provider, and - permit their announcements to its direct providers. Similar - configuration is required for AS2. + In all cases of Figure 2, in order to provide for backup, AS1 shall + permit the acceptance of AS2's routes from both AS2 and AS1's direct + provider, and permit their announcements to its direct providers. + Similar configuration is required for AS2. There are two common routing policies depending upon how the link between AS1 and AS2 is used. Policy 1: Used solely as a backup link The routing policy can be implemented by coordinating AS-based "local_pref" values between neighboring ASs. In all cases of Figure 2, the "local_pref" value for the peer of @@ -362,34 +373,40 @@ o The number of ASs that need to be preprended is in general proportional to the number of direct providers. o Compatibility with other BGP implementation may be a problem. 3.2 Splitting AS This approach requires an AS to be split into multiple ASs and run external BGP between these ASs (possibly with MEDs configured for - load balancing among multiple links). Then the cases in Figure 3 can - be reduced to the cases in Figure 2, which have been discussed in - Section 2. + load balancing among these ASs). Then the cases in Figure 3 can be + reduced to the cases in Figure 2, which have been discussed in Sec- + tion 2. This is probably the cleanest approach the current BGP version can offer. However, there is a great deal of reluctance in using this 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 involved depending upon the internal network topology. o Extra AS numbers are required [7]. It would be necessary to 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 could become real with the ever-increasing number of such needs. o The increased number of ASs would add complexity to the Inter- net topology, and therefore complicate problem resolution. o An AS number has been traditionally tied to an organization. Splitting AS means loss of coherence for some customers. @@ -398,88 +415,104 @@ 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- erence on their routers, according to preference provided by AS1. For example, for route X, ISP1 would configure higher preference for its direct link with AS1, and lower preference for its direct link with ISP2. This approach requires NRLI-based customization with the direct providers and sometimes indirect providers as well as the originating AS. The NSFNET configuration experience has shown that this approach - requires non-trivial administrative coordination, and it places a - burden on routers with limited memory capacity. For these reasons, - the NLRI-based preference configuration should be avoided at the - provider level if possible. Instead, such a configuration should be - pushed as close to the originating AS as possible. + requires non-trivial administrative coordination and full topology + information. In addition, it places a burden on routers with limited + memory capacity. For these reasons, the NLRI-based preference con- + figuration should be avoided at the provider level if 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 As has been illustrated in Section 3, it is not easy to implement - routing symmetry for an entity with multiple direct providers using - the current functionality of BGP. There are many drawbacks with the - current practice of implementation. Even the implementation of the - AS-based "local_pref" parameter can sometimes be quite involved. The - difficulty is caused by the lack of a globally transitive preference - an AS (with multiple direct providers) can specify, and be used in - the route selection process. + routing symmetry and load sharing for an entity with multiple direct + providers using the current functionality of BGP. There are many + drawbacks with the current practice of implementation. Even the + implementation of the AS-based "local_pref" parameter can sometimes + be quite involved. The difficulty is caused by the lack of a glob- + ally transitive preference an AS (with multiple direct providers) can + specify, and be used in the route selection process. - An Multi-Provider Preference (MPP) attribute is proposed [3] for the - purpose of facilitating the implementation. As illustrated in [4], - the routing policies presented in Section 2 can be implemented with - ease by using the MPP attribute. In particular, only the AS that - originates this preference needs to specify this preference on a per- - route basis. + A new BGP attribute termed "Destination Preference Attribute" (DPA) + has been proposed in [3] to address such need. As illustrated in + [4], the routing policies presented in Section 2 can be implemented + with ease by using the DPA attribute. In particular, only the AS + that originates this preference needs to specify this preference on a + per-route basis. 5. Security Considerations Security considerations are not discussed in this memo. 6. Acknowledgments The authors would like to thank Roy Alcala, Dennis Ferguson, John Stewart, and Jack Waters of MCI for the many interesting hallway dis- - cussions related to this work. We also acknowledge Sean Doran of - Sprint as the first person (to the authors knowledge) to make use of - the AS path manipulation technique. + cussions related to this work. We also acknowledge helpful comments + and suggestions by Yakov Rekhter of Cisco. 7. References [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC1771, March 1995. [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro- tocol in the Internet", RFC1772, March 1995. - [3] Chen, E., and Bates, T., "Multi-Provider Preference Attribute for - BGP", INTERNET-DRAFT, , April 1995. + [3] Chen, E., and Bates, T., "Destination Preference Attribute for + BGP", INTERNET-DRAFT, , 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- - DRAFT, , April 1995. + DRAFT, , June 1995. [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, , March 1995. [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, April 1995. [7] Hawkinsin, J., and Bates, T., "Guidelines for creation, selec- tion, and registration of an Autonomous System (AS)", INTERNET-DRAFT, , May 1995. 8. Author's Addresses Enke Chen MCI 2100 Reston Parkway - Reston, VA 22094 + Reston, VA 22091 phone: +1 703 715 7087 email: enke@mci.net Tony Bates MCI 2100 Reston Parkway - Reston, VA 22094 + Reston, VA 22091 phone: +1 703 715 7521 email: Tony.Bates@mci.net