Network Working Group Renhai Zhang Internet Draft Mach Chen Expires: April 2007 Huawei Technologies Co,LTD October 12, 2006 Nexthop Based Outbound Route Filter for BGP-4 draft-chen-idr-bgp-nexthop-orf-00.txt 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 April 12, 2007. Abstract This document defines a new Outbound Route Filter type for BGP, termed "Nexthop Outbound Route Filter", which can be used to provide Nexthop based route filtering. Specification of requirements 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. Mach Expires April 12, 2007 [Page 1] Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006 Table of Contents 1. Introduction.................................................2 2. Motivation...................................................2 3. Nexthop ORF-type.............................................4 4. Nexthop ORF Encoding.........................................5 5. Capability Specification for Nexthop ORF.....................5 6. Nexthop ORF Matching.........................................5 7. Security Considerations......................................6 8. IANA Considerations..........................................6 9. References...................................................6 9.1. Normative References....................................6 9.2. Informative References..................................6 Author's Addresses..............................................6 Intellectual Property Statement.................................7 Copyright Statement.............................................7 Acknowledgment..................................................7 1. Introduction The Outbound Route Filtering Capability defined in [BGP-ORF] provides a mechanism for a BGP speaker to send its BGP peer a set of Outbound Route Filters (ORFs) which can be used by its BGP peer to filter outbound route updates to the speaker. This document defines a new Outbound Route Filter type for BGP, termed "Nexthop Outbound Route Filter", which can be used to perform Nexthop based route filtering. The Nexthop ORF only supports exact nexthop address matching. 2. Motivation Advertisement of Multiple Paths (referred to as AMP) in BGP has been defined in [ADD-PATH] and [MULTI-NEXTHOP]. So a BGP speaker, especially route reflector and IX server, MAY advertise multiple paths to its peer for a specific prefix. When we deploy AMP in our network, multiple paths for each prefix MAY be advertised between a BGP speaker and its BGP peer. But in some cases, a BGP router doesn't want to receive those routes with a specific nexthop address from its BGP peers. An alternative method for a BGP router to filter out those routes is based on local routing policy when it received them, but using Nexthop based ORF MAY be a better choice in such a scenario. Consider the following scenarios: Mach Expires April 12, 2007 [Page 2] Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006 +------------------------+ | AS1 | | +-----+ +-----+ | | |ASBR1| |ASBR2| | | +-----+ +-----+ | +----|--------------|----+ | | | | +---------|--------------|--------+ | +-----+ +-----+ | | |ASBR3| |ASBR4| | | +-----+ +-----+ | | \ / | | +\-----/+ AS2 | | | RR | | | +--/-\--+ | | / \ | | +------+ +------+ | | | R1 | | R2 | | | +------+ +------+ | +---------------------------------+ Figure 1: AMP scenario As illustrated above in Figure 1, if we deploy AMP in AS2, that is each router in AS2 has the AMP capability. So the RR MAY advertise two paths to R1 and R2 respectively for each prefix. However, in some cases, R1 or R2 doesn't want to receive those routes which are sent from ASBR1 or ASBR2. In order to avoid unwanted routing updates, R1 or R2 MAY send a Nexthop based Outbound Route Filer to its peer (RR) and the RR would apply this filter when it advertises routes to R1 or R2. So, using Nexthop based ORF is a simple method which can satisfy the above requirement in such scenario. Mach Expires April 12, 2007 [Page 3] Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006 +------------------------+ | +-----+ | | |ASBR1| | | +-----+ AS1 | +----------|-------------+ | +---------------|----------------+ | +-------+ AS2 | | | ASBR21| | | +-/---\-+ | | / \ | | +------+/ \+------+ | | | R1 | | R2 | | | +------+\ /+------+ | | \ / | | +-\---/-+ | | | ASBR22| | | +---|---+ | +---------------|----------------+ | +----------|-------------+ | +-----+ AS3 | | |ASBR3| | | +-----+ | +------------------------+ Figure 2: Multi-homing scenario Figure 2 is another scenario. As usual, in such a scenario R1 and R2 MAY receive two paths for each prefix, one with nexthop address of ASBR1 is from ASBR21 and the other with nexthop address of ASBR3 is from ASBR22. But for some reason, R1 prefers to choose ASBR21 as its exit ASBR and R2 prefers to choose ASBR22 as its exit ASBR. So R1 doesn't need to receive those routes with nexthop address of ASBR1, and R2 also doesn't need to receive those routes with nexthop address of ASBR3. R1 or R2 can use the local policy to filter out those unwanted routes when it received them. But in such a scenario, using Nexthop based ORF is easier to do so. 3. Nexthop ORF-type The Nexthop ORF allows one to express ORFs in terms of nexthop address. That is, it provides nexthop address based route filtering, including nexthop address based matching. Conceptually a Nexthop ORF entry consists of the fields<Sequence,Match,Length,Nexthop>. Mach Expires April 12, 2007 [Page 4] Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006 The "Sequence" field specifies the relative ordering of the entry, this field is an unsigned 32-bit value. The "Match" field specifies whether this entry is "PERMIT" (value 0) or "DENY" (value 1). The Length field specifies the length of Nexthop measured in octets, this field is an unsigned 16-bit value. The Nexthop filed contains the Network Address of the next router on the path to the destination. This field MAY be an IPv4 address, IPv6 address or any other kinds of addresses. 4. Nexthop ORF Encoding The value of the ORF-type for Nexthop ORF-type is <TBD>. A Nexthop ORF entry is encoded as follows. The "Match" field of the entry is encoded in the "Match" field of the common part[BGP-ORF], and the remaining fields of the entry is encoded as follows: +--------------------------------+ | Sequence (4 octets) | +--------------------------------+ | Length (2 octet) | +--------------------------------+ | Nexthop ( variable length) | +--------------------------------+ Figure 3: Nexthop ORF entry format The "Nexthop" field is a variable length string whose length is determined by "Length" field. This field contains the next hop address which COULD be used by its peer to filter outbound route updates to the speaker. 5. Capability Specification for Nexthop ORF The Outbound Route Filter capability has been defined in [BGP-ORF]. In this document, in order to implement Nexthop based ORF, we just need to add a new ORF-type for Nexthop based Outbound Route Filter. The Nexthop ORF-type is <TBD. 6. Nexthop ORF Matching In addition to the general matching rules defined in [BGP-ORF], there are no more other specific matching rules for Nexthop based ORF. Nexthop based ORF only supports exact nexthop address matching. Mach Expires April 12, 2007 [Page 5] Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006 7. Security Considerations This extension to BGP does not change the underlying security issues. 8. IANA Considerations This document specifies a new Outbound Route Filter (ORF) type: Nexthop ORF type. The value of the ORF-type is <TBD>. 9. References 9.1. Normative References [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering Capability for BGP-4", draft-ietf-idr-route-filter-15.txt, July 2006. [ASPATH-ORF] Keyur, P., and Susan, H., "Aspath Based Outbound Route Filter for BGP-4", draft-ietf-idr-aspath-orf-08.txt, January 2006. [PREFIX-ORF] Chen, E., and Sangli S., " Address Prefix Based Outbound Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf- 04.txt, July 2006. [ADD-PATH] Walton, D., and Chen, E., "Advertisement of Multiple Paths in BGP", draft-walton-bgp-add-paths-05.txt, February 2006. [MULTI-NEXTHOP] Bhatia, M., Joel, M., and Jakma, P., "Advertising Multiple NextHop Routes in BGP", draft-bhatia-bgp-multiple- next-hops-01.txt, August 2006. 9.2. Informative References Author's Addresses Mach Chen Huawei Technologies CO,.LTD. KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing P.R. China 100085 Email: mach@huawei.com Mach Expires April 12, 2007 [Page 6] Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mach Expires April 12, 2007 [Page 7]