idnits 2.17.00 (12 Aug 2021) /tmp/idnits6782/draft-keyur-bgp-aspath-orf-00.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 106, but not defined == Missing Reference: 'FFFKKKSR' is mentioned on line 167, but not defined == Missing Reference: '0-9' is mentioned on line 198, but not defined == Unused Reference: 'BGP-4' is defined on line 229, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) -- Possible downref: Normative reference to a draft: ref. 'BGP-ORF' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keyur Patel 2 Internet Draft Tiara Networks 3 Expiration Date: June 2001 Susan Hares 4 Nexthop Technologies 6 Aspath Based Outbound Route Filter for BGP-4 8 draft-keyur-bgp-aspath-orf-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document defines a new Outbound Router Filter type for BGP, 34 termed "Aspath Outbound Route Filter", that can be used to perform 35 aspath based route filtering. This ORF-type supports aspath based 36 route filtering as well as regular expression based matching, for 37 address groups. 39 3. Introduction 41 The Cooperative Outbound Route Filtering Capability defined in [BGP- 42 ORF] provides a mechanism for a BGP speaker to send to its BGP peer a 43 set of Outbound Route Filters (ORFs) that can be used by its peer to 44 filter its outbound routing updates to the speaker. 46 This documents defines a new ORF-type for BGP, termed "Aspath 47 Outbound Route Filter (Aspath ORF)", that can be used to 48 perform Aspath based route filtering. The Aspath ORF supports Aspath 49 route filtering as well as the regular expression based matching for 50 address groups. 52 4. Aspath ORF-Type 54 The Aspath ORF-Type allows one to express ORFs in terms of 55 regular expression and aspath numbers. That is, it provides aspath 56 based route filtering, including regular expression based matching. 58 Conceptually an Aspath ORF entry consists of the fields 59 . 61 The "Sequence" field is a number that specifies the relative ordering 62 of the entry. 64 The "Match" field specifies whether this entry is "PERMIT" (value 0), 65 or "DENY" (value 1). 67 The "Length" field indicates the length of aspath regular expression 68 string. 70 The "Aspath" field contains an aspath regular expression of an 71 address group. 73 The field "Sequence" is an unsigned 32 bit value. The field "Length" 74 is an unsigned 16 bit value. The field "Aspath" is a variable length 75 hexadecimal string. The field "Aspath" will be followed by enough 76 trailing bits to make end of field fall on an octet boundry. Note 77 that the value of trailing bits is irrelevant. 79 5. Aspath ORF Encoding 81 The value of the ORF-Type for the Aspath ORF-Type is . 83 An Aspath ORF entry is encoded as follows. The "Match" field 84 of the entry is encoded in the "Match" field of the common part 85 [BGP-ORF], and the remaining fields of the entry is encoded in the 86 "Type specific part" as follows. 88 +--------------------------------+ 89 | Sequence (4 octets) | 90 +--------------------------------+ 91 | Length (2 octet) | 92 +--------------------------------+ 93 | Aspath ( variable length) | 94 +--------------------------------+ 96 Note that the Aspath field is varibale length hexadecimal string 97 whose length is defined by Length field. 99 6.) Capability Specification for Cooperative route filtering with ASpath 101 As specified in the Coperative Router filtering draft 102 [draft-ietf-idr-route-filter-01.txt], a BGP speaker that is 103 willing to receive ORF entries from its peer, 104 or a BGP speaker that would like to send ORF entries to its peer 105 advertises this to the peer by using the Cooperative Route Filtering 106 Capability uses a new BGP capability [BGP-CAP] defined as follows: 108 Capability code: 3 110 Capability length: variable 111 Capability value: one or more of the following entries: 113 +--------------------------------------------------+ 114 | Address Family Identifier (2 octets) | 115 +--------------------------------------------------+ 116 | Reserved (1 octet) | 117 +--------------------------------------------------+ 118 | Subsequent Address Family Identifier (1 octet) | 119 +--------------------------------------------------+ 120 | Number of ORFs (1 octet) | 121 +--------------------------------------------------+ 122 | ORF Type (1 octet) | 123 +--------------------------------------------------+ 124 | Send/Receive (1 octet) | 125 +--------------------------------------------------+ 126 | ... | 127 +--------------------------------------------------+ 128 | ORF Type (1 octet) | 129 +--------------------------------------------------+ 130 | Send/Receive (1 octet) | 131 +--------------------------------------------------+ 133 Fig 4. Capability encoding 135 The use and meaning of these fields are as follows: 137 Address Family Identifier (AFI): 139 This field carries the identity of the Network Layer protocol 140 associated with the Network Address that follows. Presently 141 defined values for this field are specified in RFC1700 (see the 142 Address Family Numbers section). 144 Subsequent Address Family Identifier (SAFI): 146 This field provides additional information about the type of 147 the Network Layer Reachability Information carried in the 148 attribute. 150 Number of ORF Types: 152 This field contains the number of Filter Types to be listed in 153 the following fields. 155 ORF Type: 157 This field contains the value of an ORF Type. 159 Send/Receive: 161 This field indicates whether the sender is (a) willing to 162 receive ORF entries from its peer (value 1), (b) would like to 163 send ORF entries to its peer (value 2), or (c) both (value 3) 164 for the ORF Type that follows. 166 In the upper bits of the Send/Receive byte the top three 167 bits have the following encoding: [FFFKKKSR] 168 where bit 0 is the left most bit. 170 Where - S = Send ORF for ASpath 171 R = Receive ORF for ASpath 173 Where KKK is a 3 bit field reserved for future expansion of 174 regular expression differences in ORF. 176 Where FFF indicates 3 bits. Bit 0 is the left most bit, 177 Bit 1 is the middle bit and Bit 2 is the right most bit. 179 bit 0 - anchors 180 0 - full length regex, ie: implicit anchoring of AsPath as in 181 ^AsPath$ 182 1 - partial as-path regex with anchoring. ie: the regex may 183 or may not have anchors and thus may be a partial match. 184 eg: 185 anchoring non-anchoring 186 ^X -> X .* 187 ^X$ -> X 188 X -> .* X .* 190 bit 1 - "." wildcard operator [Collating Element] 191 0 - traditional application of "." as wildcard, ie: "." matches 192 any single character of the set [0-9 ]. 193 1 - "." matches an AS-path token/term, 194 regex "." == traditional regex "[0-9]+" 196 bit 2 - "[]" operator 197 0 - not supported. 198 1 - supported, eg: [0-9] 200 7. Aspath ORF Matching 202 In addition to the general matching rules defined in [BGP-ORF], 203 several Aspath ORF specific matching rules are defined as follows. 205 It is possible that the speaker would have more than one Aspath 206 ORF entry that matches the route. In that case the "first-match" rule 207 applies. That is, the ORF entry with the smallest sequence number 208 among all the matching ORF entries) is considered as the sole match, 209 and it would determine whether the route should be advertised. 211 If any speaker does not support capabilities specified by the 212 receiver but still decide to establish the connection, the 213 receiver is expected to translate the Aspath regular 214 expressions to the its (receiver's) interpretation of regular 215 expressions as indicated in the capability announcement. 217 7. Security Considerations 219 This extension to BGP does not change the underlying security issues. 221 8. Acknowledgements 223 We express our thanks to Andrew Partan,Avneesh Sachdev, Alec Peterson, 224 Enke Chen, John Heasley, Dorian Kim and Bruce Cole for their 225 comments. 227 9. References 229 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 230 4)", RFC 1771, March 1995. 232 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 233 Capability for BGP-4", draft-chen-bgp-route-filter-01.txt, August 234 2000. 236 10. Author Information 238 Keyur Patel 239 Tiara Networks, Inc. 240 505 Race St#100 241 San Jose, CA 95126 242 email: keyur@tiaranet.com 244 Susan Hares 245 NextHop Technologies. Inc. 246 517 W. Williams 247 Ann Arbor, MI 48103-4943 248 email: skh@nexthop.com