Network Working Group E. Chen Internet Draft K. Patel Intended Status: Standards Track A. Lo Expiration Date: June 6, 2012 Cisco Systems December 5, 2011 Extended Community Based Outbound Route Filter for BGP-4 draft-chen-bgp-ext-community-orf-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 6, 2012. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Chen, Patel & Lo [Page 1] Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011 described in the Simplified BSD License. Abstract This document defines two new Outbound Router Filter types for BGP, termed "Extended Community Outbound Route Filter Type I", and "Extended Community Outbound Route Filter Type II", that can be used to perform extended community based route filtering. 1. Introduction The Outbound Route Filtering Capability defined in [RFC5291] 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 filter its outbound routing updates to the speaker. This document defines two new Outbound Router Filter type for BGP [RFC4271], termed "Extended Community Outbound Route Filter Type I", and "Extended Community Outbound Route Filter Type II", that can be used to perform the extended community [RFC4360, RFC5760] based route filtering. The former can be used only for the 8-octet extended communities defined in [RFC4360], and is retained for backward compatibility. The latter can be used for the extended communities defined in both [RFC4360] and [RFC5701]. This document also specifies procedures for performing route filtering when both types are supported. 1.1. 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 RFC2119 [RFC2119]. Chen, Patel & Lo [Page 2] Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011 2. Extended Communities ORF Type I The Extended Community ORF Type I allows to express ORFs in terms of the 8-octet BGP Extended Communities defined in [RFC4360]. That is, the Extended Communities ORF Type I provides the 8-octet Extended Community based route filtering. Conceptually the ORF entry of the Extended Communities ORF Type I consists of a single Extended Community of 8 octets. The sender SHOULD set the value of the Match field to PERMIT; the receiver SHOULD ignore the value of the Match field. The remote peer should consider only those routes whose Extended Communities attribute has at least one Extended Community in common with the Extended Communities list specified in the ORF. 2.1. Encoding The value of the ORF-Type for the Extended Communities ORF Type I is 3. The type-specific part of the Extended Communities ORF Type I consists of a single Extended Community as specified in [RFC4360]. 3. Extended Communities ORF Type II The Extended Community ORF Type II allows to express ORFs in terms of the BGP Extended Communities defined in both [RFC4360] and [RFC5701]. That is, the Extended Communities ORF Type II provides Extended Community based route filtering. Conceptually the ORF entry of the Extended Communities ORF-Type consists of a single Extended Community, of either 8 octets, or 20 octets. The sender SHOULD set the value of the Match field to PERMIT; the receiver SHOULD ignore the value of the Match field. The remote peer should consider only those routes whose Extended Communities attribute has at least one Extended Community in common with the Extended Communities list specified in the ORF. Chen, Patel & Lo [Page 3] Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011 3.1. Encoding The value of the ORF-Type for the Extended Communities ORF Type II is . The type-specific part of the Extended Communities ORF Type II consists of a single Extended Community encoded as the following +------------------------------------------+ | Ext-community Length (1 octet) | +------------------------------------------+ | Ext-community value (8 or 20 octets) | +------------------------------------------+ where the "Ext-community Length" field contains the number of octets of the extended community in the "Ext-community value" field. 4. Operations In addition to the general procedures defined in [RFC5291], the following procedures are specified for the Extended Community ORF types. As the Extended Community ORF Type I can only handled the extended communities defined in [RFC4360], clearly it SHOULD NOT be enabled over a BGP session that exchanges routes with the extended communities defined in [RFC5701]. The Extended Community ORF Type I is retained for backward compatibility. An implementation SHOULD migrate to the Extended Community ORF Type II in order to handle the extended communities defined in both [RFC4360] and [RFC5701]. During the lifetime of a BGP session, ORF entries of only one of the two types would be carried in the ROUTE-REFRESH message, and be used in route filtering. When both types are allowed, respectively, by the "Send/Receive" fields in the Outbound Route Filtering Capability and the procedures specified in [RFC5291], Type II would be used. When only one of the two types is allowed by the "Send/Receive" fields in the Outbound Route Filtering Capability and the procedures specified in [RFC5291], that particular type would be used. Chen, Patel & Lo [Page 4] Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011 5. IANA Considerations This document specifies two new Outbound Route Filtering (ORF) types, Extended Community ORF Type I (with ORF-type value 3), and the Extended Community ORF Type II (with ORF-type value ). 6. Security Considerations This extension to BGP does not change the underlying security issues in BGP [RFC4271]. 7. Acknowledgements We would like to thank Yakov Rekhter for his contribution on this work. 8. Normative References [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November2009. [RFC5291] Chen, E., and Rekhter, Y., "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Chen, Patel & Lo [Page 5] Internet Draft draft-chen-bgp-ext-community-orf-02.txt Dec 5, 2011 9. Author Information Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA EMail: enkechen@cisco.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Alton Lo Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: altonlo@cisco.com Chen, Patel & Lo [Page 6]