idnits 2.17.1 draft-chen-idr-bgp-nexthop-orf-00.txt: 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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 288. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 12, 2006) is 6406 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) == Unused Reference: 'BGP-4' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'ASPATH-ORF' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'PREFIX-ORF' is defined on line 243, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-15 == Outdated reference: A later version (-13) exists of draft-ietf-idr-aspath-orf-08 == Outdated reference: A later version (-05) exists of draft-ietf-idr-bgp-prefix-orf-04 == Outdated reference: A later version (-06) exists of draft-walton-bgp-add-paths-05 -- Possible downref: Normative reference to a draft: ref. 'ADD-PATH' -- Possible downref: Normative reference to a draft: ref. 'MULTI-NEXTHOP' Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Renhai Zhang 2 Internet Draft Mach Chen 3 Expires: April 2007 Huawei Technologies Co,LTD 4 October 12, 2006 6 Nexthop Based Outbound Route Filter for BGP-4 7 draft-chen-idr-bgp-nexthop-orf-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-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/ietf/1id-abstracts.txt 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 April 12, 2007. 34 Abstract 36 This document defines a new Outbound Route Filter type for BGP, 37 termed "Nexthop Outbound Route Filter", which can be used to provide 38 Nexthop based route filtering. 40 Specification of requirements 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC-2119. 46 Table of Contents 48 1. Introduction.................................................2 49 2. Motivation...................................................2 50 3. Nexthop ORF-type.............................................4 51 4. Nexthop ORF Encoding.........................................5 52 5. Capability Specification for Nexthop ORF.....................5 53 6. Nexthop ORF Matching.........................................5 54 7. Security Considerations......................................6 55 8. IANA Considerations..........................................6 56 9. References...................................................6 57 9.1. Normative References....................................6 58 9.2. Informative References..................................6 59 Author's Addresses..............................................6 60 Intellectual Property Statement.................................7 61 Copyright Statement.............................................7 62 Acknowledgment..................................................7 64 1. Introduction 66 The Outbound Route Filtering Capability defined in [BGP-ORF] provides 67 a mechanism for a BGP speaker to send its BGP peer a set of Outbound 68 Route Filters (ORFs) which can be used by its BGP peer to filter 69 outbound route updates to the speaker. 71 This document defines a new Outbound Route Filter type for BGP, 72 termed "Nexthop Outbound Route Filter", which can be used to perform 73 Nexthop based route filtering. The Nexthop ORF only supports exact 74 nexthop address matching. 76 2. Motivation 78 Advertisement of Multiple Paths (referred to as AMP) in BGP has been 79 defined in [ADD-PATH] and [MULTI-NEXTHOP]. So a BGP speaker, 80 especially route reflector and IX server, MAY advertise multiple 81 paths to its peer for a specific prefix. When we deploy AMP in our 82 network, multiple paths for each prefix MAY be advertised between a 83 BGP speaker and its BGP peer. But in some cases, a BGP router doesn't 84 want to receive those routes with a specific nexthop address from its 85 BGP peers. An alternative method for a BGP router to filter out those 86 routes is based on local routing policy when it received them, but 87 using Nexthop based ORF MAY be a better choice in such a scenario. 89 Consider the following scenarios: 91 +------------------------+ 92 | AS1 | 93 | +-----+ +-----+ | 94 | |ASBR1| |ASBR2| | 95 | +-----+ +-----+ | 96 +----|--------------|----+ 97 | | 98 | | 99 +---------|--------------|--------+ 100 | +-----+ +-----+ | 101 | |ASBR3| |ASBR4| | 102 | +-----+ +-----+ | 103 | \ / | 104 | +\-----/+ AS2 | 105 | | RR | | 106 | +--/-\--+ | 107 | / \ | 108 | +------+ +------+ | 109 | | R1 | | R2 | | 110 | +------+ +------+ | 111 +---------------------------------+ 112 Figure 1: AMP scenario 114 As illustrated above in Figure 1, if we deploy AMP in AS2, that is 115 each router in AS2 has the AMP capability. So the RR MAY advertise 116 two paths to R1 and R2 respectively for each prefix. However, in some 117 cases, R1 or R2 doesn't want to receive those routes which are sent 118 from ASBR1 or ASBR2. In order to avoid unwanted routing updates, R1 119 or R2 MAY send a Nexthop based Outbound Route Filer to its peer (RR) 120 and the RR would apply this filter when it advertises routes to R1 or 121 R2. So, using Nexthop based ORF is a simple method which can satisfy 122 the above requirement in such scenario. 124 +------------------------+ 125 | +-----+ | 126 | |ASBR1| | 127 | +-----+ AS1 | 128 +----------|-------------+ 129 | 130 +---------------|----------------+ 131 | +-------+ AS2 | 132 | | ASBR21| | 133 | +-/---\-+ | 134 | / \ | 135 | +------+/ \+------+ | 136 | | R1 | | R2 | | 137 | +------+\ /+------+ | 138 | \ / | 139 | +-\---/-+ | 140 | | ASBR22| | 141 | +---|---+ | 142 +---------------|----------------+ 143 | 144 +----------|-------------+ 145 | +-----+ AS3 | 146 | |ASBR3| | 147 | +-----+ | 148 +------------------------+ 149 Figure 2: Multi-homing scenario 151 Figure 2 is another scenario. As usual, in such a scenario R1 and R2 152 MAY receive two paths for each prefix, one with nexthop address of 153 ASBR1 is from ASBR21 and the other with nexthop address of ASBR3 is 154 from ASBR22. But for some reason, R1 prefers to choose ASBR21 as its 155 exit ASBR and R2 prefers to choose ASBR22 as its exit ASBR. So R1 156 doesn't need to receive those routes with nexthop address of ASBR1, 157 and R2 also doesn't need to receive those routes with nexthop address 158 of ASBR3. R1 or R2 can use the local policy to filter out those 159 unwanted routes when it received them. But in such a scenario, using 160 Nexthop based ORF is easier to do so. 162 3. Nexthop ORF-type 164 The Nexthop ORF allows one to express ORFs in terms of nexthop 165 address. That is, it provides nexthop address based route filtering, 166 including nexthop address based matching. 168 Conceptually a Nexthop ORF entry consists of the 169 fields. 171 The "Sequence" field specifies the relative ordering of the entry, 172 this field is an unsigned 32-bit value. 174 The "Match" field specifies whether this entry is "PERMIT" (value 0) 175 or "DENY" (value 1). 177 The Length field specifies the length of Nexthop measured in octets, 178 this field is an unsigned 16-bit value. 180 The Nexthop filed contains the Network Address of the next router on 181 the path to the destination. This field MAY be an IPv4 address, IPv6 182 address or any other kinds of addresses. 184 4. Nexthop ORF Encoding 186 The value of the ORF-type for Nexthop ORF-type is . 188 A Nexthop ORF entry is encoded as follows. The "Match" field of the 189 entry is encoded in the "Match" field of the common part[BGP-ORF], 190 and the remaining fields of the entry is encoded as follows: 192 +--------------------------------+ 193 | Sequence (4 octets) | 194 +--------------------------------+ 195 | Length (2 octet) | 196 +--------------------------------+ 197 | Nexthop ( variable length) | 198 +--------------------------------+ 199 Figure 3: Nexthop ORF entry format 201 The "Nexthop" field is a variable length string whose length is 202 determined by "Length" field. This field contains the next hop 203 address which COULD be used by its peer to filter outbound route 204 updates to the speaker. 206 5. Capability Specification for Nexthop ORF 208 The Outbound Route Filter capability has been defined in [BGP-ORF]. 209 In this document, in order to implement Nexthop based ORF, we just 210 need to add a new ORF-type for Nexthop based Outbound Route Filter. 211 The Nexthop ORF-type is . 228 9. References 230 9.1. Normative References 232 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 233 4 (BGP-4)", RFC 4271, January 2006. 235 [BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering 236 Capability for BGP-4", draft-ietf-idr-route-filter-15.txt, 237 July 2006. 239 [ASPATH-ORF] Keyur, P., and Susan, H., "Aspath Based Outbound Route 240 Filter for BGP-4", draft-ietf-idr-aspath-orf-08.txt, 241 January 2006. 243 [PREFIX-ORF] Chen, E., and Sangli S., " Address Prefix Based Outbound 244 Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf- 245 04.txt, July 2006. 247 [ADD-PATH] Walton, D., and Chen, E., "Advertisement of Multiple Paths 248 in BGP", draft-walton-bgp-add-paths-05.txt, February 2006. 250 [MULTI-NEXTHOP] Bhatia, M., Joel, M., and Jakma, P., "Advertising 251 Multiple NextHop Routes in BGP", draft-bhatia-bgp-multiple- 252 next-hops-01.txt, August 2006. 254 9.2. Informative References 256 Author's Addresses 258 Mach Chen 259 Huawei Technologies CO,.LTD. 260 KuiKe Building, No.9 Xinxi Rd., 261 Shang-Di Information Industry Base, 262 Hai-Dian District Beijing P.R. China 100085 264 Email: mach@huawei.com 266 Intellectual Property Statement 268 The IETF takes no position regarding the validity or scope of any 269 Intellectual Property Rights or other rights that might be claimed to 270 pertain to the implementation or use of the technology described in 271 this document or the extent to which any license under such rights 272 might or might not be available; nor does it represent that it has 273 made any independent effort to identify any such rights. Information 274 on the procedures with respect to rights in RFC documents can be 275 found in BCP 78 and BCP 79. 277 Copies of IPR disclosures made to the IETF Secretariat and any 278 assurances of licenses to be made available, or the result of an 279 attempt made to obtain a general license or permission for the use of 280 such proprietary rights by implementers or users of this 281 specification can be obtained from the IETF on-line IPR repository at 282 http://www.ietf.org/ipr. 284 The IETF invites any interested party to bring to its attention any 285 copyrights, patents or patent applications, or other proprietary 286 rights that may cover technology that may be required to implement 287 this standard. Please address the information to the IETF at 288 ietf-ipr@ietf.org. 290 Disclaimer of Validity 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 295 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 296 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 297 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Copyright Statement 302 Copyright (C) The Internet Society (2006). 304 This document is subject to the rights, licenses and restrictions 305 contained in BCP 78, and except as set forth therein, the authors 306 retain all their rights. 308 Acknowledgment 310 Funding for the RFC Editor function is currently provided by the 311 Internet Society.