Internet Engineering Task Force Olivier Bonaventure INTERNET DRAFT FUNDP <draft-bonaventure-bgp-redistribution-00.txt> June, 2001 Expires December, 2001 Controlling the redistribution of BGP routes 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. Abstract This document proposes the redistribution extended community. This new well-known extended community allows a router to influence how a specific route should be redistributed towards a specified set of eBGP speakers. The redistribution community allows to indicate that a specific route should not be announced to a set of eBGP speakers, should only be announced to a set of eBGP speakers or should be prepended n times when announced to a set of eBGP speakers. 1 Introduction In today's commercial Internet, many ISPs need to have some control on their interdomain traffic. In the outgoing direction, this control can be obtained by configuring the BGP routers of the ISP to favor some routes over others by using the LOCAL-PREF attribute. However, due to the assymetry of Internet traffic, most ISPs mainly need to Bonaventure [Page 1]
Internet Draftdraft-bonaventure-bgp-redistribution-00.txt June 2001 control their incoming traffic. +---------------+ | | | AS22 | | | +---------------+ || +---------------+ +---------------+ | 13.0.0.0/8 | | AS21 | | 12.0.0.0/8 |===============| | | AS20 | +---------------+ +---------------+ || +---------------+ | | | AS10 | | | +---------------+ Figure 1: Simple interdomain topology In the incoming direction, the only way to influence the traffic flow is to control the redistribution of its routes. Several methods exist and are used in practice [Hal97]. In this case, it needs to influence the redistribution and the selection of its own routes by remote ISPs. Since the default configuration of many BGP routers is to select the route with the smallest AS path length, a common technique is to artificially increase the length of the AS path for some announced routes. For example, in figure 1, if AS20 wanted to indicate that it prefers to receive its traffic towards subnet 13.0.0.0/8 through its link with AS22, then it would announce this prefix as usual on this link to AS22 and announce a prefix with the AS20:AS20:AS20:AS20 path to AS21 and AS10. If AS10 and AS21 rely only on the AS path length to select the best BGP route, they will prefer the shorter route received by AS22. This requires a manual configuration of the BGP routers, but path prepending is used very often on the Internet according to [Hus01]. In some cases, the configuration burden can be reduced by using the BGP communities attribute. Recently, several large ISPs have gone one step further by defining BGP communities that allow their customers to influence the redistribution of their routes. For example, in figure 1, AS20 could configure its BGP routers to always prepend four times AS20 when they announce via eBGP a route received from one of AS20's customers with a special community attribute. For this, AS20 needs to publish the specific BGP communities that it supports and its customers need to Bonaventure [Page 2]
Internet Draftdraft-bonaventure-bgp-redistribution-00.txt June 2001 configure their router appropriately. If AS20 needs to define a new BGP community or change an existing one, it must inform all its customers would will then have to update the configuration of their routers. A quick survey of the RIPE database in May 2001 revealed that the utilization of BGP community attributes to control outbound routes is becoming more and more frequent. Several utilizations of the BGP community attributes are interesting to mention. - More than twenty different AS define their own BGP community attributes to allow their customers/peers to indicate that a particular route should not be propagated towards a specific AS, towards the routers attached to a specific IX, or towards AS within a given geographical area (e.g. a European AS could want to prohibit a route from being announced to US peers). - More than twenty different AS define their own BGP community attributes to allow their peers or customers to indicate that an announced route should be prepended when announced towards a specific AS, IX or set of AS. upstreams. - Five AS define their own BGP community attribute to indicate that a given route should only be redistributed towards a specified AS. >From this survey, it is clear that this utilization of the BGP communi- ties attribute occurs in todat's Internet. However, asking each AS to select its own values for the BGP communities and documenting these val- ues in the RIPE database is not very efficient because it forces the BGP routers to be configured manually based on information found in the RIPE database or in peering agreements. Given the growing utilization of the BGP community attribute to support such facilities, we propose in this document a new type of well-known BGP extended community. By using a well-known BGP extended community with a precise syntax, we sup- port most of the current utilizations of the BGP communities without relying unnecessarily on manual configuration of the BGP routers. We believe that reducing the manual configuration of these routers would be very useful for the stability and the performance of the global Inter- net. 2 The redistribution community The extended communities attribute is defined in [RTR01]. This attribute allows a BGP router to attach a set of extended communities to an UPDATE message. Each extended community value is encoded as an eight octet quantity with a two octet type field and a 6 octets value field. [RTR01] defines types 0x00, 0x01, 0x02, 0x0002, 0x0102, 0x0003, 0x0103 and 0x0004. This document proposes the well-known redistribution commu- nity whose type field is TBD_IANA.The 6 octet value field of the pro- posed extended community is encoded as follows : Bonaventure [Page 3]
Internet Draftdraft-bonaventure-bgp-redistribution-00.txt June 2001 +------------------+ | Flags (1 octet)| +------------------+-----------------------------------+ | eBGP speakers (5 octets) | +------------------------------------------------------+ The flags field indicates how the attached route needs to be redis- tributed towards the set of BGP speakers specified in the eBGP speakers field. The flags field is divided in three parts. The high order bit indicates whether the flags field has a standard value defined by this document or revisions of it (bit set to zero) or a vendor-specific value (bit set to one). The four next high order bits of the flags octet spec- ify the operation to be performed when redistributing the routes con- tained in the same UPDATE message. The following semantics for these four bits is currently defined : - The attached route(s) must not be announced to the specified eBGP speakers (Value : 0000) - When announcing the attached route(s) to one of the specified eBGP speakers, the AS number of the eBGP speaker that announces the route must be prepended once (Value : 001) - When announcing the attached route(s) to one of the specified eBGP speakers, the AS number of the eBGP speaker that announces the route must be prepended twice (Value : 0010) - When announcing the attached route(s) to one of the specified eBGP speakers, the AS number of the eBGP speaker that announces the route must be prepended three times (Value : 0011) - When announcing the attached route(s) to one of the specified eBGP speakers, the AS number of the eBGP speaker that announces the route must be prepended four times (Value : 0100) - The attached route(s) must only be announced to the specified eBGP speakers (Value : 1111) The redistribution communities with values 1111 and 0000 provide similar facilities as the DIST_LIST_EXCL and DIST_LIST_INCL attributes of IDRP [ISO93]. The utilization of the values between 0101 and 1110 is left for further study. The three low order bits of the flags octet indicate the format of the eBGP speakers field. This document supports the following for- mats. Bonaventure [Page 4]
Internet Draftdraft-bonaventure-bgp-redistribution-00.txt June 2001 - The BGP speakers field contains a two octets AS number (value 001). - The BGP speakers field contains a CIDR prefix/length pair (value 010). - The BGP speakers field contains a four octets AS number (value 011). The BGP speakers field shall be encoded as follows. If this field con- tains a two octet AS number, the AS number shall be placed in the two low order octets. The three high order octets shall be set to zero upon transmission and ignored upon reception. If the BGP speakers field con- tains a four octet AS number, the AS number shall be placed in the four low order octets. The high order octet shall be set to zero upon trans- mission and ignored upon reception. If the BGP speakers field contains a CIDR prefix/length pair, the IP prefix shall be placed in the four high order octets and the low order octet will contain the prefix length. 3 Operations A router may, depending on its policy, add any redistribution community to a route received from another BGP speaker with iBGP or eBGP. The redistribution communities defined in this document do not affect the redistribution of routes to iBGP peers. When a router receives a route with redistribution communities, it should apply the operations specified by these communities when redis- tributing the route to eBGP peers. A router should remove the received redistribution communities when redistributing the route to eBGP peers. If a router receives a route that contains conflicting redistribution communities that apply to the same set of BGP speakers, it should apply the specified operations in the order that they appear in the BGP attribute. These conflicting communities should be logged through a man- agement interface of the router. 4 IANA considerations This document requests the attribution of a new BGP extended communities type field from IANA. 5 Conclusion This document has proposed the new redistribution community. By using the defined redistribution communities, a BGP router can influence the Bonaventure [Page 5]
Internet Draftdraft-bonaventure-bgp-redistribution-00.txt June 2001 redistribution of a given route by its peers. The proposed redistribu- tion community is intended to replace the current widespread utilization of local BGP extended communities that relies heavily on manual router configuration. The redistribution community proposed by this document could also be very useful for interprovider VPNs such as those described in [RRB^+01]. Acknowledgements This work was partially funded by the European Commission, within the ATRIUM IST project. References [Hal97] B. Halabi. Internet Routing Architectures. Cisco Press, 1997. [Hus01] G. Huston. AS1221 BGP table statistics. available from http://www.telstra.net/ops/bgp/, 2001. [ISO93] ISO/IEC, Protocol for Exchange of Inter-domain Routeing infor- mation among Intermediate Systems to Support Forwarding of ISO 8473 PDUs, ISO/IEC 10747:1993 [RRB^+01] E. Rosen, Y. Rekther, T. Bogovic, , R. Vaidyanathan S. Bran- non, M. Morrow, M. Carugi, C. Chase, L. Fang, T. Wo Chung, J. De Clercq, E. Dean, P. Hitchin, A. Smith, M. Leelanivas, D. Marshall, L. Martini, V. Srinivasan, and A. Vedrenne. BGP/MPLS VPNs. Internet draft draft-rosen-rfc2547bis-03.txt, work in progress, February 2001. [RTR01] S. Ramachandra, D. Tappan, and Y. Rekhter. BGP extended commu- nities attribute. Internet draft,draft-ramachandra-bgp-ext-communi- ties-08.txt, work in progress, January 2001. Author's Address Olivier Bonaventure Infonet group (FUNDP) Facultes Universitaires Notre-Dame de la Paix Rue Grandgagnage 21, B-5000 Namur, Belgium. E-mail: Olivier.Bonaventure@info.fundp.ac.be URL : http://www.infonet.fundp.ac.be Bonaventure [Page 6]