IDR Working Group Renhai Zhang Internet Draft (Huawei) Expires: January 2006 Xiaodong Duan (China Mobile) Shaoling Sun (China Mobile) July 2005 draft-zhang-idr-bgp-entire-routes-reflect-01.txt Entire Route Reflect capability Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005).All Rights Reserved. Abstract This document defines a new Border Gateway Protocol [BGP4] capability termed 'Entire Route Reflect capability', which would allow a BGP Route Reflector (RR) to reflect all the routes it receives from other client or non-client peers to a peer which would perform load balancing across these routes. Zhang , Duan & Sun [Page 1] Internet Draft Entire Route Reflect capability July 2005 Table of Contents 1. Introduction.................................................2 2. Entire Route Reflect capability..............................3 3. Use of BGP Capability Advertisement..........................5 4. Operation....................................................6 5. IANA Considerations..........................................8 6. Security Considerations......................................8 7. References...................................................8 8. Author's Addresses...........................................9 9. Full Copyright Statement.....................................9 1. Introduction Nowadays, operators often employ RR configuration to reduce network configuration requirements and operational complexity. On the other hand, their customers often connect Customer Edge (CE) devices to two different Provider Edge (PE) routers for backup and want all the resources of links to be used, for example, load balancing on these links. Unfortunately, when RR is configured in the operator's network, the RR selects "best paths" before reflecting routes to another remote client peer, and only the selected path is reflected. If the remote peer has distinct link directly connected to the respective PE equipments, only one link can be used to forward the user's traffic. If an RR can reflect all paths before selecting its own best paths, this problem will be resolved. However, when a route is to be withdrawn, the RR must indicate exactly which routes to withdraw, since the RR has redistributed more than one route of the same destination to the RR client. Adding a next hop information in the withdrawn segment in the UPDATE message can accomplish this. 2. Entire Route Reflect capability In this document, we define the Entire Route Reflect capability, which is advertised by a client peer to the RR through BGP Capabilities Advertisement [BGP-CAP], announcing that the client is capable of handling the withdrawn routes segment that contains a NEXT_HOP in an update packet. 3. Use of BGP Capability Advertisement A client peer capable of handling the withdrawn routes segment containing a NEXT_HOP should use the Capability Advertisement procedures [BGP-CAP] to announce this capability to RR. Zhang , Duan & Sun [Page 2] Internet Draft Entire Route Reflect capability July 2005 The fields in the Capabilities Optional Parameter are set as follows. The Capability Code field is set to 68 (TBD). The Capability Length field is set to 4. The Capability Value field is defined as: +-------+-------+-------+-------+ | AFI | Res. | SAFI | +-------+-------+-------+-------+ AFI - Address Family Identifier (16 bit), encoded the same way as in the Multiprotocol Extensions Res. - Reserved (8 bit) field. Should be set to 0 by the sender and ignored by the receiver SAFI - Subsequent Address Family Identifier (8 bit), encoded the same way as in the Multiprotocol Extensions. A speaker that supports multiple Entire Route Reflect parameters includes these parameters as multiple Capabilities in the Capabilities Optional Parameter at OPEN time. 4. Operation Based on the topology of the network, the operator may determine if load balancing can be performed on a client peer. For example, if the client peer is connected to two PEs through distinct links, and these PEs have a common RR with the client peer. Then the Entire Route Reflect capability can be configured on the client peer. The RR should advertise all the routes to the client peer from which it has received the capability advertisement. The RR MUST add a NEXT_HOP into the withdrawn segment when withdrawing routes that have been distributed to the client peer. For IPv4 routes, the NEXT_HOP comprises only a IPv4 address. It is added between Withdrawn Routes Length and Withdrawn Routes in the UPDATE packet. The length is 4 octets. The value of Withdrawn Routes Length includes the length of NEXT_HOP. The UPDATE packet is described as below: +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | NEXT_HOP (4 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ For other multiprotocol routes, the NEXT_HOP comprises Length of Next Hop Network Address and Network Address of Next Hop. It is added just before the Withdrawn Routes that contained in the Zhang , Duan & Sun [Page 3] Internet Draft Entire Route Reflect capability July 2005 MP_UNREACH_NLRI attribute, it is described as below: +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Withdrawn Routes (variable) | +---------------------------------------------------------+ 5. IANA Considerations The code of Entire Route Reflect capability is to be assigned by IANA [RFC2434]. 6. Security Considerations This document does not introduce new security issues. 7. References [BGP4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [BGP RR] T. Bates. and R. Chandra. E, Chen "BGP Route Reflection" draft-ietf-idr-rfc2796bis-01.txt, November 2004 8. Author's Addresses Renhai Zhang Huawei Technologies No. 3 Xinxi Road, Shangdi, Haidian District, Beijing, China Email: zhangrenhai@huawei.com Duanxiao Dong China Mobile 53A,Xibianmennei Ave,Xunwu District Beijing, China duanxiaodong@chinamobile.com Zhang , Duan & Sun [Page 4] Internet Draft Entire Route Reflect capability July 2005 Shaoling Sun China Mobile 53A,Xibianmennei Ave,Xunwu District Beijing, China sunshaoling@chinamobile.com 9. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zhang , Duan & Sun [Page 5]