idnits 2.17.1 draft-ietf-idr-aspath-orf-09.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 273. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 4) being 138 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'BGP-CAP' is mentioned on line 116, but not defined == Missing Reference: 'FFFKKKSR' is mentioned on line 177, but not defined == Missing Reference: '0-9' is mentioned on line 208, but not defined == Unused Reference: 'BGP-4' is defined on line 239, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-05 Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keyur Patel 2 Internet Draft Cisco Systems 3 Expiration Date: August 2007 Susan Hares 4 Nexthop Technologies 6 Aspath Based Outbound Route Filter for BGP-4 8 draft-ietf-idr-aspath-orf-09.txt 10 1. Status of this Memo 12 By submitting this Internet-Draft, each author represents 13 that any applicable patent or other IPR claims of which he 14 or she is aware have been or will be disclosed, and any of 15 which he or she becomes aware will be disclosed, in 16 accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This document is an individual submission. Comments are solicited and 35 should be addressed to the author(s). 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 2. Abstract 43 This document defines a new Outbound Router Filter type for BGP, 44 termed "Aspath Outbound Route Filter", that can be used to perform 45 aspath based route filtering. This ORF-type supports aspath based 46 route filtering as well as regular expression based matching, for 47 address groups. 49 3. Introduction 51 The Cooperative Outbound Route Filtering Capability defined in [BGP- 52 ORF] provides a mechanism for a BGP speaker to send to its BGP peer a 53 set of Outbound Route Filters (ORFs) that can be used by its peer to 54 filter its outbound routing updates to the speaker. 56 This documents defines a new ORF-type for BGP, termed "Aspath 57 Outbound Route Filter (Aspath ORF)", that can be used to 58 perform Aspath based route filtering. The Aspath ORF supports Aspath 59 route filtering as well as the regular expression based matching for 60 address groups. 62 4. Aspath ORF-Type 64 The Aspath ORF-Type allows one to express ORFs in terms of 65 regular expression and aspath numbers. That is, it provides aspath 66 based route filtering, including regular expression based matching. 68 Conceptually an Aspath ORF entry consists of the fields 69 . 71 The "Sequence" field is a number that specifies the relative ordering 72 of the entry. 74 The "Match" field specifies whether this entry is "PERMIT" (value 0), 75 or "DENY" (value 1). 77 The "Length" field indicates the length of aspath regular expression 78 string. 80 The "Aspath" field contains an aspath regular expression of an 81 address group. 83 The field "Sequence" is an unsigned 32 bit value. The field "Length" 84 is an unsigned 16 bit value. The field "Aspath" is a variable length 85 hexadecimal string. The field "Aspath" will be followed by enough 86 trailing bits to make end of field fall on an octet boundry. Note 87 that the value of trailing bits is irrelevant. 89 5. Aspath ORF Encoding 91 The value of the ORF-Type for the Aspath ORF-Type is . 93 An Aspath ORF entry is encoded as follows. The "Match" field 94 of the entry is encoded in the "Match" field of the common part 95 [BGP-ORF], and the remaining fields of the entry is encoded in the 96 "Type specific part" as follows. 98 +--------------------------------+ 99 | Sequence (4 octets) | 100 +--------------------------------+ 101 | Length (2 octet) | 102 +--------------------------------+ 103 | Aspath ( variable length) | 104 +--------------------------------+ 106 Note that the Aspath field is varibale length hexadecimal string 107 whose length is defined by Length field. 109 6. Capability Specification for Cooperative route filtering with ASpath 111 As specified in the Coperative Router filtering draft 112 [draft-ietf-idr-route-filter-05.txt], a BGP speaker that is 113 willing to receive ORF entries from its peer, 114 or a BGP speaker that would like to send ORF entries to its peer 115 advertises this to the peer by using the Cooperative Route Filtering 116 Capability uses a new BGP capability [BGP-CAP] defined as follows: 118 Capability code: 3 120 Capability length: variable 121 Capability value: one or more of the following entries: 123 +--------------------------------------------------+ 124 | Address Family Identifier (2 octets) | 125 +--------------------------------------------------+ 126 | Reserved (1 octet) | 127 +--------------------------------------------------+ 128 | Subsequent Address Family Identifier (1 octet) | 129 +--------------------------------------------------+ 130 | Number of ORFs (1 octet) | 131 +--------------------------------------------------+ 132 | ORF Type (1 octet) | 133 +--------------------------------------------------+ 134 | Send/Receive (1 octet) | 135 +--------------------------------------------------+ 136 | ... | 137 +--------------------------------------------------+ 138 | ORF Type (1 octet) | 139 +--------------------------------------------------+ 140 | Send/Receive (1 octet) | 141 +--------------------------------------------------+ 143 Fig 4. Capability encoding 145 The use and meaning of these fields are as follows: 147 Address Family Identifier (AFI): 149 This field carries the identity of the Network Layer protocol 150 associated with the Network Address that follows. Presently 151 defined values for this field are specified in RFC1700 (see the 152 Address Family Numbers section). 154 Subsequent Address Family Identifier (SAFI): 156 This field provides additional information about the type of 157 the Network Layer Reachability Information carried in the 158 attribute. 160 Number of ORF Types: 162 This field contains the number of Filter Types to be listed in 163 the following fields. 165 ORF Type: 167 This field contains the value of an ORF Type. 169 Send/Receive: 171 This field indicates whether the sender is (a) willing to 172 receive ORF entries from its peer (value 1), (b) would like to 173 send ORF entries to its peer (value 2), or (c) both (value 3) 174 for the ORF Type that follows. 176 In the upper bits of the Send/Receive byte the top three 177 bits have the following encoding: [FFFKKKSR] 178 where bit 0 is the left most bit. 180 Where - S = Send ORF for ASpath 181 R = Receive ORF for ASpath 183 Where KKK is a 3 bit field reserved for future expansion of 184 regular expression differences in ORF. 186 Where FFF indicates 3 bits. Bit 0 is the left most bit, 187 Bit 1 is the middle bit and Bit 2 is the right most bit. 189 bit 0 - anchors 190 0 - full length regex, ie: implicit anchoring of AsPath as in 191 ^AsPath$ 192 1 - partial as-path regex with anchoring. ie: the regex may 193 or may not have anchors and thus may be a partial match. 194 eg: 195 anchoring non-anchoring 196 ^X -> X .* 197 ^X$ -> X 198 X -> .* X .* 200 bit 1 - "." wildcard operator [Collating Element] 201 0 - traditional application of "." as wildcard, ie: "." matches 202 any single character of the set [0-9 ]. 203 1 - "." matches an AS-path token/term, 204 regex "." == traditional regex "[0-9]+" 206 bit 2 - "[]" operator 207 0 - not supported. 208 1 - supported, eg: [0-9] 210 7. Aspath ORF Matching 212 In addition to the general matching rules defined in [BGP-ORF], 213 several Aspath ORF specific matching rules are defined as follows. 215 It is possible that the speaker would have more than one Aspath 216 ORF entry that matches the route. In that case the "first-match" rule 217 applies. That is, the ORF entry with the smallest sequence number 218 among all the matching ORF entries) is considered as the sole match, 219 and it would determine whether the route should be advertised. 221 If any speaker does not support capabilities specified by the 222 receiver but still decide to establish the connection, the 223 receiver is expected to translate the Aspath regular 224 expressions to the its (receiver's) interpretation of regular 225 expressions as indicated in the capability announcement. 227 7. Security Considerations 229 This extension to BGP does not change the underlying security issues. 231 8. Acknowledgements 233 We express our thanks to Andrew Partan, Avneesh Sachdev, Alec Peterson, 234 Enke Chen, John Heasley, Dorian Kim and Bruce Cole for their 235 comments. 237 9. References 239 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 240 4)", RFC 1771, March 1995. 242 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 243 Capability for BGP-4", draft-ietf-idr-route-filter-05.txt, January 244 2002. 246 10. Author Information 248 Keyur Patel 249 Cisco Systems 250 510 McCarthy Blvd 251 Milpitas, CA 95035 252 email: keyupate@cisco.com 254 Susan Hares 255 NextHop Technologies. Inc. 256 517 W. Williams 257 Ann Arbor, MI 48103-4943 258 email: skh@nexthop.com 260 11. Full Copyright Notice 262 Copyright (C) The IETF Trust (2007). This document is subject 263 to the rights, licenses and restrictions contained in BCP 78, and 264 except as set forth therein, the authors retain all their rights. 266 This document and the information contained herein 267 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 268 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 269 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 270 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 271 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 272 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 273 OR FITNESS FOR A PARTICULAR PURPOSE.