Internet Engineering Task Force Yuanchao Su Internet-Draft CCS Intended status: Proposed Standard Expires: October 3, 2009 April 1, 2009 Additive-Routes-Wanted Outbound Route Filter for BGP-4 draft-yuanchao-additive-routes-wanted-orf-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 October 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a solution for overcoming the limitations of existing route reflect mechanism:even there are equal routes,route reflector(RR) would use the nexthop router ID to break tie and only reflect the route with lower router ID to its Su Expires - October 2009 [Page 1] Additive-Routes-Wanted ORF for BGP-4 April 2009 clients,so RR clients send all the traffic for the destination to only one nexthop which leads to traffic unbalanced in an AS. Additive-Routes-Wanted ORF extends ORF to not only filter BGP routes but also give RR client the ablility to ask RR for additive BGP routes in its BGP database. With the additive routes, RR clients could make inner-AS native IP and VPNV4 load sharing easier. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. Table of Contents 1. Contributors...................................................2 2. Terminology....................................................2 3. Introduction...................................................2 4. Additive Routes ORF............................................2 5. Additive Routes ORF Encoding...................................3 6. Additive Routes ORF Matching...................................3 7. IANA Considerations............................................3 8. Security Considerations........................................3 9. Normative References...........................................3 10. Acknowledgments...............................................3 Author's Addresses................................................3 1. Contributors Yuanchao Su 2. Terminology This document uses terminology described in [ORF], [BGP-4] and [MP-BGP]. 3. Introduction The Outbound Route Filtering Capability defined in [ORF] provides a mechanism for a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that can be used by its peer to filterits outbound routing updates to the speaker. This document defines a new ORF-Type for BGP-4, termed " Additive-Routes-Wanted Outbound Route Filter (Additive Routes ORF)", which can be used by RR clients to ask RR for additive routes. After receive the additive routes from RR,RR clients use iBGP multipath load Sharing to balance the traffic in an AS. The Additive Routes ORF-Type inherits exsiting ORF encoding and matching mechanism. 4. Additive Routes ORF The Additive Routes ORF-Type acturally use the BGP capabilities exchanging mechanism for ORF to ask RR for additive BGP routes. The Additive Routes ORF-Type inherits existing ORF encoding and matching method and have no need to define a new one. Su Expires - October 2009 [Page 2] Additive-Routes-Wanted ORF for BGP-4 April 2009 For example,if RR and clients both support Address Prefixe ORF- Type(RFC 5292),then clients may send a Additive Routes ORF-Type consisting of the following fields with ORF-Type set to 65 but not 64: . After receives Additive Routes ORF,not like normal ORF-Type looking up routes in routing table,RR looks up routes in its BGP database and then advertises matched(according to the rules in ORF) routes to clients throught BGP updates.In the case of hierarchical RRs,it is necessary that Additive Routes ORF be used between RRs and between RR and clients. It is suggested that ORF would support (extended)communities and AS-path regular expressions based encoding and matching method for convenience,which is out of the scope of this document. 5. Additive Routes ORF Encoding The value of the ORF-Type for the Additive Routes ORF-Type is 65. An Additive Routes ORF entry is encoded in the same manner as normal ORF-Type. 6. Additive Routes ORF Matching An Additive Routes ORF entry is matched in the same manner as normal ORF-Type. 7. IANA Considerations This document specifies a new Outbound Route Filtering (ORF) type, Additive Route ORF. The value of the ORF-Type is 65. 8. Security Considerations This extension to BGP does not change the underlying security issues in [BGP-4]. 9. Normative References [ORF] E. Chen, S. Sangli "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, August 2008 [BGP-4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [MP-BGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 10. Acknowledgments The authors are deeply grateful to the authors of ORF(RFC 5291). Author's Addresses Yuanchao Su China Communications Services Co. No.19 chaoyangmen.Beidajie.Dongcheng District.Beijing.100010,P.R.China Email: syc@gpdi.com Su Expires - October 2009 [Page 3] Additive-Routes-Wanted ORF for BGP-4 April 2009 Su Expires - October 2009 [Page 4]