idnits 2.17.00 (12 Aug 2021) /tmp/idnits7004/draft-ietf-idr-aspath-orf-13.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: ---------------------------------------------------------------------------- No issues found here. 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 19, 2016) is 1972 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: 'FFFKKKSR' is mentioned on line 194, but not defined == Missing Reference: '0-9' is mentioned on line 241, but not defined == Unused Reference: 'RFC2119' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Hares 3 Internet-Draft Huawei 4 Intended status: Standards Track K. Patel 5 Expires: June 22, 2017 Cisco 6 December 19, 2016 8 AS Path Based Outbound Route Filter for BGP-4 9 draft-ietf-idr-aspath-orf-13.txt 11 Abstract 13 This document defines a new Outbound Router Filter type for BGP, 14 termed "Aspath Outbound Route Filter", that can be used to perform 15 aspath based route filtering. This ORF-type supports aspath based 16 route filtering as well as regular expression based matching, for 17 address groups. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 22, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. ASpath ORF-Type . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. ASpath ORF encoding . . . . . . . . . . . . . . . . . . . . . 3 56 4. Capability Specification for Cooperative route filtering with 57 ASpath . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. ASpath ORF Matching . . . . . . . . . . . . . . . . . . . . . 6 59 6. Error handling . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The Cooperative Outbound Route Filtering Capability defined in 70 [RFC5292] provides a mechanism for a BGP speaker to send to its BGP 71 peer a set of Outbound Route Filters (ORFs) that can be used by its 72 peer to filter its outbound routing updates to the speaker. 74 This documents defines a new ORF-type for BGP, termed "ASpath 75 Outbound Route Filter (ASpath ORF)", that can be used to perform AS 76 Path based route filtering. The ASpath ORF supports AS path route 77 filtering as well as the regular expression based matching for 78 address groups. 80 2. ASpath ORF-Type 82 The ASpath ORF-Type allows one to express ORFs in terms of regular 83 expression and AS path numbers. That is, it provides AS path based 84 route filtering, including regular expression based matching. 86 Conceptually an ASpath ORF entry consists of the fields . 89 The "Sequence" field is a number that specifies the relative 90 ordering of the entry. 92 The "Match" field specifies whether this entry is "PERMIT" (value 93 0), or "DENY" (value 1). 95 The "Length" field indicates the length of AS path regular 96 expression string. 98 The "aspath" field contains an AS path regular expression of an 99 address group. 101 The field "Sequence" is an unsigned 32 bit value. The field 102 "Length" is an unsigned 16 bit value. The field "aspath" is a 103 variable length hexadecimal string. The field "aspath" will be 104 followed by enough trailing bits to make end of field fall on an 105 octet boundary. Note that the value of trailing bits is 106 irrelevant. 108 3. ASpath ORF encoding 110 The value of the ORF-Type for the ASpath ORF-Type is . 112 An ASpath ORF entry is encoded as follows. The "Match" field of the 113 entry is encoded in the "Match" field of the common part [RFC5292], 114 and the remaining fields of the entry is encoded in the "Type 115 specific part" as follows: 117 +--------------------------------+ 118 | Sequence (4 octets) | 119 +--------------------------------+ 120 | Length (2 octet) | 121 +--------------------------------+ 122 | Aspath ( variable length) | 123 +--------------------------------+ 125 Note the aspath is a variable length hexadecimal string whose length 126 is defined by Length field. 128 4. Capability Specification for Cooperative route filtering with ASpath 130 As specified in Cooperative Route Filter[RFC5292], a BGP speaker that 131 is willing to receive ORF entries from its peer, or a BGP speaker 132 that would like to send ORF entries to its peer advertises this to 133 the peer by using the Cooperative Route Filtering Capability uses a 134 new BGP capability [RFC3392] defined as follows: 136 Capability code: 3 138 Capability length: variable 140 Capability value: one or more of the following entries: 142 +--------------------------------------------------+ 143 | Address Family Identifier (2 octets) | 144 +--------------------------------------------------+ 145 | Reserved (1 octet) | 146 +--------------------------------------------------+ 147 | Subsequent Address Family Identifier (1 octet) | 148 +--------------------------------------------------+ 149 | Number of ORFs (1 octet) | 150 +--------------------------------------------------+ 151 | ORF Type (1 octet) | 152 +--------------------------------------------------+ 153 | Send/Receive (1 octet) | 154 +--------------------------------------------------+ 155 | ... | 156 +--------------------------------------------------+ 157 | ORF Type (1 octet) | 158 +--------------------------------------------------+ 159 | Send/Receive (1 octet) | 160 +--------------------------------------------------+ 162 Fig 4. Capability encoding 164 The use and meaning of these fields are as follows: 166 Address Family Identifier (AFI) 168 This field carries the identity of the address family for the 169 Network Layer protocol associated with the Network Address that 170 follows. 172 Subsequent Address Family Identifier (SAFI): 174 This field provides additional information about the type of 175 the Network Layer Reachability Information carried in the 176 attribute. 178 Number of ORF Types 180 This field contains the number of Filter Types to be listed in 181 the following fields. 183 ORF Type 185 This field contains the value of an ORF Type. 187 Send/Receive 188 This field indicates whether the sender is (a) willing to 189 receive ORF entries from its peer (value 1), (b) would like to 190 send ORF entries to its peer (value 2), or (c) both (value 3) 191 for the ORF Type that follows. 193 In the upper bits of the Send/Receive byte the top three bits 194 have the following encoding: [FFFKKKSR] where bit 0 is the left 195 most bit. 197 where: 199 S = Send ORF for ASpath 201 R = Receive ORF for ASpath 203 KKK = a 3 bit field reserved for future expansion of regular 204 expression differences in ORF. 206 FFF = 3 bits. 208 Bit 0 is the left most bit, and indicates anchoring 209 status. 211 Bit 0 = 0 - implies full length regular express 212 (regex), that is implicit anchoring of ASPath as in 213 "^ASPath$" 215 anchoring--non-anchoring 217 ^X --------> X .* 219 ^X$ --------> X 221 X -----------> .* X .* 223 Bit 0 = 1 - implies partial aspath regex, regex may or 224 may not have anchors 226 Bit 1 is the middle bit, and it is the "." wildcard 227 operator. [Collating Element] 229 Bit 1 = 0 -- indicates traditional application of "." 230 as wildcard, ie: "." matches any single character of 231 the set [0-9 ]. 233 Bit 1 = 1 -- indicates "." matches an AS-path token/ 234 term, regex "." == traditional regex "[0-9]+" 236 Bit 2 is the right most bit, and indicates the "[]" 237 operator where: 239 Bit 2 = 0 - indicates not supported 241 Bit 2 = 1 - indicates support, e.g. [0-9] 243 5. ASpath ORF Matching 245 In addition to the general matching rules defined in [RFC5292], 246 several ASpath ORF specific matching rules are defined as follows. 248 It is possible that the speaker would have more than one ASpath ORF 249 entry that matches the route. In that case the "first-match" rule 250 applies. That is, the ORF entry with the smallest sequence number 251 among all the matching ORF entries) is considered as the sole match, 252 and it would determine whether the route should be advertised. 254 If any speaker does not support capabilities specified by the 255 receiver but still decide to establish the connection, the receiver 256 is expected to translate the AS path regular expressions to the its 257 (receiver's) interpretation of regular expressions as indicated in 258 the capability announcement. 260 6. Error handling 262 ORFs provide information that guides future sending, but any 263 malformed ORF is simply missed filtering information. If ASpath ORF 264 is malformed, the attribute shall simply be discarded. 266 7. Security Considerations 268 This extension to BGP does not change the underlying security issues. 270 8. Acknowledgements 272 We express our thanks to Andrew Partan, Avneesh Sachdev, Alec 273 Peterson, Enke Chen, John Heasley, Dorian Kim and Bruce Cole for 274 their comments. 276 9. IANA Considerations 278 No IANA exist for this document. 280 10. Security Considerations 282 No security considerations are involved with a gap analysis. 284 11. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 292 with BGP-4", RFC 3392, DOI 10.17487/RFC3392, November 293 2002, . 295 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 296 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 297 DOI 10.17487/RFC4271, January 2006, 298 . 300 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 301 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 302 August 2008, . 304 Authors' Addresses 306 Susan Hares 307 Huawei 308 7453 Hickory Hill 309 Saline, MI 48176 310 USA 312 Email: shares@ndzh.com 314 Keyur Patel 315 Cisco 316 Milipitas, CA 95035 318 Email: keyupate@cisco.com