idnits 2.17.1 draft-chen-bgp-ext-community-orf-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2011) is 4526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5760' is mentioned on line 66, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft K. Patel 4 Intended Status: Standards Track A. Lo 5 Expiration Date: June 6, 2012 Cisco Systems 6 December 5, 2011 8 Extended Community Based Outbound Route Filter for BGP-4 9 draft-chen-bgp-ext-community-orf-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on June 6, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document defines two new Outbound Router Filter types for BGP, 52 termed "Extended Community Outbound Route Filter Type I", and 53 "Extended Community Outbound Route Filter Type II", that can be used 54 to perform extended community based route filtering. 56 1. Introduction 58 The Outbound Route Filtering Capability defined in [RFC5291] provides 59 a mechanism for a BGP speaker to send to its BGP peer a set of 60 Outbound Route Filters (ORFs) that can be used by its peer to filter 61 its outbound routing updates to the speaker. 63 This document defines two new Outbound Router Filter type for BGP 64 [RFC4271], termed "Extended Community Outbound Route Filter Type I", 65 and "Extended Community Outbound Route Filter Type II", that can be 66 used to perform the extended community [RFC4360, RFC5760] based route 67 filtering. The former can be used only for the 8-octet extended 68 communities defined in [RFC4360], and is retained for backward 69 compatibility. The latter can be used for the extended communities 70 defined in both [RFC4360] and [RFC5701]. This document also 71 specifies procedures for performing route filtering when both types 72 are supported. 74 1.1. Specification of Requirements 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC2119 [RFC2119]. 80 2. Extended Communities ORF Type I 82 The Extended Community ORF Type I allows to express ORFs in terms of 83 the 8-octet BGP Extended Communities defined in [RFC4360]. That is, 84 the Extended Communities ORF Type I provides the 8-octet Extended 85 Community based route filtering. 87 Conceptually the ORF entry of the Extended Communities ORF Type I 88 consists of a single Extended Community of 8 octets. 90 The sender SHOULD set the value of the Match field to PERMIT; the 91 receiver SHOULD ignore the value of the Match field. 93 The remote peer should consider only those routes whose Extended 94 Communities attribute has at least one Extended Community in common 95 with the Extended Communities list specified in the ORF. 97 2.1. Encoding 99 The value of the ORF-Type for the Extended Communities ORF Type I is 100 3. 102 The type-specific part of the Extended Communities ORF Type I 103 consists of a single Extended Community as specified in [RFC4360]. 105 3. Extended Communities ORF Type II 107 The Extended Community ORF Type II allows to express ORFs in terms of 108 the BGP Extended Communities defined in both [RFC4360] and [RFC5701]. 109 That is, the Extended Communities ORF Type II provides Extended 110 Community based route filtering. 112 Conceptually the ORF entry of the Extended Communities ORF-Type 113 consists of a single Extended Community, of either 8 octets, or 20 114 octets. 116 The sender SHOULD set the value of the Match field to PERMIT; the 117 receiver SHOULD ignore the value of the Match field. 119 The remote peer should consider only those routes whose Extended 120 Communities attribute has at least one Extended Community in common 121 with the Extended Communities list specified in the ORF. 123 3.1. Encoding 125 The value of the ORF-Type for the Extended Communities ORF Type II is 126 . 128 The type-specific part of the Extended Communities ORF Type II 129 consists of a single Extended Community encoded as the following 131 +------------------------------------------+ 132 | Ext-community Length (1 octet) | 133 +------------------------------------------+ 134 | Ext-community value (8 or 20 octets) | 135 +------------------------------------------+ 137 where the "Ext-community Length" field contains the number of octets 138 of the extended community in the "Ext-community value" field. 140 4. Operations 142 In addition to the general procedures defined in [RFC5291], the 143 following procedures are specified for the Extended Community ORF 144 types. 146 As the Extended Community ORF Type I can only handled the extended 147 communities defined in [RFC4360], clearly it SHOULD NOT be enabled 148 over a BGP session that exchanges routes with the extended 149 communities defined in [RFC5701]. 151 The Extended Community ORF Type I is retained for backward 152 compatibility. An implementation SHOULD migrate to the Extended 153 Community ORF Type II in order to handle the extended communities 154 defined in both [RFC4360] and [RFC5701]. 156 During the lifetime of a BGP session, ORF entries of only one of the 157 two types would be carried in the ROUTE-REFRESH message, and be used 158 in route filtering. When both types are allowed, respectively, by 159 the "Send/Receive" fields in the Outbound Route Filtering Capability 160 and the procedures specified in [RFC5291], Type II would be used. 161 When only one of the two types is allowed by the "Send/Receive" 162 fields in the Outbound Route Filtering Capability and the procedures 163 specified in [RFC5291], that particular type would be used. 165 5. IANA Considerations 167 This document specifies two new Outbound Route Filtering (ORF) types, 168 Extended Community ORF Type I (with ORF-type value 3), and the 169 Extended Community ORF Type II (with ORF-type value ). 171 6. Security Considerations 173 This extension to BGP does not change the underlying security issues 174 in BGP [RFC4271]. 176 7. Acknowledgements 178 We would like to thank Yakov Rekhter for his contribution on this 179 work. 181 8. Normative References 183 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 184 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 185 2006. 187 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 188 Communities Attribute", RFC 4360, February 2006. 190 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended 191 Community Attribute", RFC 5701, November2009. 193 [RFC5291] Chen, E., and Rekhter, Y., "Outbound Route Filtering 194 Capability for BGP-4", RFC 5291, August 2008. 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 9. Author Information 201 Enke Chen 202 Cisco Systems, Inc. 203 170 W. Tasman Dr. 204 San Jose, CA 95134 205 USA 207 EMail: enkechen@cisco.com 209 Keyur Patel 210 Cisco Systems 211 170 W. Tasman Drive 212 San Jose, CA 95134 213 USA 215 Email: keyupate@cisco.com 217 Alton Lo 218 Cisco Systems 219 170 W. Tasman Drive 220 San Jose, CA 95134 221 USA 223 Email: altonlo@cisco.com