idnits 2.17.1 draft-ietf-idr-bgp-prefix-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): ---------------------------------------------------------------------------- ** 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 3667, Section 5.1 on line 16. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 4 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 5 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 147 has weird spacing: '...ecified un-s...' == Line 151 has weird spacing: '...ecified spec...' -- 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) == Unused Reference: 'BGP-4' is defined on line 168, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-24 ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-10 Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft Redback Networks 4 Expiration Date: February 2005 Srihari R. Sangli 5 Cisco Systems 7 Address Prefix Based Outbound Route Filter for BGP-4 9 draft-ietf-idr-bgp-prefix-orf-00.txt 11 1. Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 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 2. Abstract 36 This document defines a new Outbound Router Filter type for BGP, 37 termed "Address Prefix Outbound Route Filter", that can be used to 38 perform address prefix based route filtering. This ORF-type supports 39 prefix length or range based matching, wild-card based address prefix 40 matching, as well as the exact address prefix matching for address 41 families. 43 3. Introduction 45 The Cooperative Outbound Route Filtering Capability defined in [BGP- 46 ORF] provides a mechanism for a BGP speaker to send to its BGP peer a 47 set of Outbound Route Filters (ORFs) that can be used by its peer to 48 filter its outbound routing updates to the speaker. 50 This documents defines a new ORF-type for BGP, termed "Address Prefix 51 Outbound Route Filter (Address Prefix ORF)", that can be used to 52 perform address prefix based route filtering. The Address Prefix ORF 53 supports prefix length or range based matching, wild-card based 54 address prefix matching, as well as the exact address prefix matching 55 for address families [BGP-MP]. 57 4. Address Prefix ORF-Type 59 The Address Prefix ORF-Type allows one to express ORFs in terms of 60 address prefixes. That is, it provides address prefix based route 61 filtering, including prefix length or range based matching, as well 62 as wild-card address prefix matching. 64 Conceptually an Address Prefix ORF entry consists of the fields 65 . 67 The "Sequence" field is a number that specifies the relative ordering 68 of the entry. 70 The "Match" field specifies whether this entry is "PERMIT" (value 0), 71 or "DENY" (value 1). 73 The "Length" field indicates the length in bits of the address 74 prefix. A length of zero indicates a prefix that matches all (as 75 specified by the address family) addresses (with prefix itself of 76 zero octets). 78 The "Prefix" field contains an address prefix of an address family. 80 The "Minlen" field indicates the minimum prefix length in bits that 81 is required for "matching". The field is considered as un-specified 82 with value 0. 84 The "Maxlen" field indicates the maximum prefix length in bits that 85 is required for "matching". The field is considered as un-specified 86 with value 0. 88 The fields "Sequence", "Length", "Minlen", and "Maxlen" are all 89 unsigned integers. 91 This document imposes the following requirement on the values of 92 these fields: 94 0 <= Length < Minlen <= Maxlen 96 In addition, the "Maxlen" must be no more than the maximum length (in 97 bits) of a host address for a given address family [BGP-MP]. 99 5. Address Prefix ORF Encoding 101 The value of the ORF-Type for the Address Prefix ORF-Type is 64. 103 An Address Prefix ORF entry is encoded as follows. The "Match" field 104 of the entry is encoded in the "Match" field of the common part [BGP- 105 ORF], and the remaining fields of the entry is encoded in the "Type 106 specific part" as follows. 108 +--------------------------------+ 109 | Sequence (4 octets) | 110 +--------------------------------+ 111 | Minlen (1 octet) | 112 +--------------------------------+ 113 | Maxlen (1 octet) | 114 +--------------------------------+ 115 | Length (1 octet) | 116 +--------------------------------+ 117 | Prefix (variable length) | 118 +--------------------------------+ 120 Note that the Prefix field contains the address prefix followed by 121 enough trailing bits to make the end of the field fall on an octet 122 boundary. The value of the trailing bits is irrelevant. 124 6. Address Prefix ORF Matching 126 In addition to the general matching rules defined in [BGP-ORF], 127 several Address Prefix ORF specific matching rules are defined as 128 follows. 130 Consider an Address Prefix ORF entry, and a route maintained by a BGP 131 speaker with NLRI in the form of . 133 The route is considered as "no match" to the ORF entry if the NLRI is 134 neither more specific than, nor equal to, the fields 135 of the ORF entry. 137 When the NLRI is either more specific than, or equal to, the fields of the ORF entry, the route is considered as a match 139 to the ORF entry only if the NLRI match condition as listed in the 140 following table is satisfied. 142 ORF Entry NLRI 143 Minlen Maxlen Match Condition 144 +------------------------------------------------------+ 145 | un-spec. un-spec. NLRI.legnth == ORF.length | 146 +------------------------------------------------------+ 147 | specified un-spec. NLRI.length >= ORF.Minlen | 148 +------------------------------------------------------+ 149 | un-spec. specified NLRI.length <= ORF.Maxlen | 150 +------------------------------------------------------+ 151 | specified specified NLRI.length >= ORF.Minlen | 152 | AND NLRI.length <= ORF.Maxlen | 153 +------------------------------------------------------+ 155 It is possible that the speaker would have more than one Prefix 156 Address ORF entry that matches the NLRI of the route. In that case 157 the "first-match" rule applies. That is, the ORF entry with the 158 smallest sequence number (among all the matching ORF entries) is 159 considered as the sole match, and it would determine whether the 160 route should be advertised. 162 7. Security Considerations 164 This extension to BGP does not change the underlying security issues. 166 8. References 168 [BGP-4] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol 169 4 (BGP-4)", draft-ietf-idr-bgp4-24.txt, November 2003. 171 [BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 172 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 174 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 175 Capability for BGP-4", draft-ietf-idr-route-filter-10.txt, March 176 2004. 178 9. Author Information 180 Enke Chen 181 Redback Networks, Inc. 182 300 Holger Way 183 San Jose, CA 95134 184 Email: enke@redback.com 186 Srihari R. Sangli 187 Cisco Systems, Inc. 188 170 W. Tasman Dr. 189 San Jose, CA 95134 190 Email: rsrihari@cisco.com 192 10. Full Copyright Notice 194 Copyright (C) The Internet Society (2004). This document is subject 195 to the rights, licenses and restrictions contained in BCP 78, and 196 except as set forth therein, the authors retain all their rights. 198 This document and the information contained herein is provided on an 199 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 200 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 201 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 202 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 203 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.