idnits 2.17.00 (12 Aug 2021) /tmp/idnits45378/draft-haas-idr-extended-experimental-01.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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 1, 2017) is 1900 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PEN' ** Downref: Normative reference to an Informational RFC: RFC 2042 == Outdated reference: A later version (-02) exists of draft-ietf-idr-bgp-attribute-announcement-00 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Haas 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track March 1, 2017 5 Expires: September 2, 2017 7 Extended Experimental Path Attributes for BGP 8 draft-haas-idr-extended-experimental-01 10 Abstract 12 BGP's primary feature extension mechanism, Optional-Transitive Path 13 Attributes, has proven to be a successful mechanism to permit BGP to 14 be extended. In order to ease various issues during the development 15 of new BGP features, this document proposes an extended experimental 16 Path Attribute to carry prototype features. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 22 be interpreted as described in [RFC2119] only when they appear in all 23 upper case. They may also appear in lower or mixed case as English 24 words, without normative meaning. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 2, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Extended Experimental Path Attribute . . . . . . . . . . . . 3 62 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Moving to an Allocated Code Point . . . . . . . . . . . . . . 4 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 8.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Appendix A. Comparisons to Other Features . . . . . . . . . . . 6 71 Appendix B. Discussion to this Date . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 BGP's [RFC4271] primary feature extension mechanism, Optional- 77 Transitive Path Attributes, has proven to be a successful mechanism 78 to permit BGP to be extended. It permits implementations to 79 propagate unknown Path Attributes without understanding their 80 contents, so long as they are syntactically valid. 82 Path Attributes are encoded in BGP UPDATE messages using a single 83 octet code-point. While this code-point space is relatively small, 84 the rate at which new BGP features are introduced has proven to be 85 slow enough that the potential for exhaustion has not been a 86 significant concern more than twenty years into the deployment of 87 BGP-4. This code point space is managed by IANA under the Standards 88 Action policy [RFC5226], one of the more restrictive policies in 89 IETF's repertoire. Early allocation [RFC7120] provides some latitude 90 for allocation of these code points compared to the original RFC 5226 91 policy, but is reserved for features that are considered 92 appropriately stable. 94 Development work on the BGP protocol often requires a code point be 95 assigned to a feature in progress. While code point 255 has been 96 reserved to be Experimental ([RFC2042]), developers will often face 97 collisions when attempting to do development on more than a single 98 in-progress feature. Once the feature has reached a level of 99 stability, early allocation should be strongly pursued. It may take 100 some time, however, for features to reach that level of stability. 102 Due to the general difficulty of getting a public code point during 103 the development process, code point "squatting" (use of a code point 104 that has not been officially allocated) is unfortunately common. In 105 many cases, this is done completely internally and has no impact on 106 the Internet. But sometimes accidents happen and pre-release 107 features ship. Prior to the deployment of the Revised BGP Error 108 Handling Procedures [RFC7606], this could often be disastrous as 109 different features, or different versions of the same feature, 110 collided with each other and were interpreted as syntax errors and 111 caused BGP peering sessions to reset per RFC 4271 error handling 112 procedures. While it is less disastrous for such collisions to 113 happen in terms of stability of the Internet, what's needed is a way 114 for BGP protocol development to proceed with a little more safety. 116 This document proposes a new BGP Path Attribute, the BGP Extended 117 Experimental Path Attribute. This Attribute is intended to be used 118 solely for BGP Protocol development and is not intended to replace 119 the allocation policies for the BGP Protocol. 121 2. Extended Experimental Path Attribute 123 The Extended Experimental Path Attribute is an Optional-Transitive 124 Path Attribute with a code of TBD. Its contents are a series of TLVs 125 in the following format: 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Implementor IANA Private Enterprise Number (4 octets) | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Implementor Feature Code Point Number (4 octets) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Version Number (2 octets) | Feature Length (2 octets) | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Feature Data (0 or more octets) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 o Implementor IANA Private Enterprise Number is a Private Enterprise 139 Number (PEN) assigned by IANA. [IANA-PEN] 140 o Feature Code Point Number is a code point space under the control 141 of the holder of the PEN. 142 o Version Number is an unsigned number intended to convey the 143 version of the feature covered by the Feature Code Point Number 144 for the implementor. Implementors are encouraged to sequentially 145 number versions of their feature beginning at 1. 146 o Feature Length is the length of the Feature Data. 147 o Feature Data will be encoded as a BGP Path Attribute value for the 148 experimental feature. 150 3. Usage 152 A BGP implementor intending to introduce a new standards oriented 153 Path Attribute will select a code point number for their new Path 154 Attribute and assign an initial Version Number. Whenever the format 155 of the feature needs to change, the Version Number MUST also change. 156 This prevents implementations understanding different versions of a 157 pre-standards feature from improperly parsing the attribute. 159 BGP Experimental features MUST require explicit configuration to 160 recognize a specific Feature Code Point Number, for a given Version 161 Number, for a given PEN. If such configuration is not present, the 162 TLV MUST be ignored. 164 BGP Experimental features SHOULD NOT carry more than one Version 165 Number of the same Feature Code Point in a given UPDATE. 166 Implementations are encouraged to strip inconsistent Version Numbered 167 TLVs for a given feature when appropriate. For example, if the BGP 168 speaker is configured to support Version Number 2 of an experimental 169 feature, it may discard all TLVs for the Feature Code Point Number 170 that are not 2. 172 BGP implementations supporting the Extended Experimental Path 173 Attribute SHOULD strip this attribute by default on external BGP 174 sessions. Explicit configuration SHOULD be required to permit a 175 given PEN+FCPN+VN tuple into the network. 177 4. Error Handling 179 If the Extended Experimental Path Attribute is determined to be 180 syntactically invalid, the Attribute discard behavior from [RFC7606] 181 MUST be used. 183 5. Moving to an Allocated Code Point 185 Once an evolving BGP protocol feature reaches a reasonable level of 186 stability, implementations MUST move to a Path Attribute Code Point 187 allocated using the IETF sanctioned procedures. Implementors that 188 publish their PEN+FCN+VN allocations for a given version of their 189 feature in progress are recommended to publish this binding as part 190 of their allocation request to enable short term backward 191 compatibility with their experimental work. 193 While it is possible for implementations of a new feature to rely on 194 experimental deployment for some time, the procedures noted in 195 Section 3 are intended to discourage this behavior by making inter- 196 domain distribution of the experiment fail by default. 198 6. Security Considerations 200 This document does not introduce any new security considerations into 201 the BGP-4 protocol. While the injection of unknown or badly 202 formatted Optional-Transitive Path Attributes has been and remains an 203 issue impacting the stability of the Internet, this proposal doesn't 204 increase exposure to that issue. It is rather expected that this 205 proposal helps remediate the accidental attack surface that 206 incremental BGP protocol work exposes to the Internet at large. 208 [RFC7606] has mitigated the majority of the issues mentioned in the 209 prior paragraph. See that RFC for further information on the history 210 of the problem. 212 7. IANA Considerations 214 This document is primarily about issues related to IANA 215 Considerations. At some point, IANA will be requested to assign a 216 BGP Path Attribute Code number, referenced as TBD early in the 217 document. 219 8. References 221 8.1. Normative References 223 [IANA-PEN] 224 "IANA Private Enterprise Number", . 226 [RFC2042] Manning, B., "Registering New BGP Attribute Types", 227 RFC 2042, DOI 10.17487/RFC2042, January 1997, 228 . 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 236 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 237 DOI 10.17487/RFC4271, January 2006, 238 . 240 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 241 Patel, "Revised Error Handling for BGP UPDATE Messages", 242 RFC 7606, DOI 10.17487/RFC7606, August 2015, 243 . 245 8.2. Informative References 247 [I-D.ietf-idr-bgp-attribute-announcement] 248 Patel, K., Uttaro, J., Decraene, B., Henderickx, W., and 249 J. Haas, "Constrain Attribute announcement within BGP", 250 draft-ietf-idr-bgp-attribute-announcement-00 (work in 251 progress), July 2016. 253 [ietf-97-idr-code-point-management-slides] 254 Haas, J., "Code Point Management - IETF 97 Slides", 255 November 2016, 256 . 259 [ietf-97-idr-extended-experimental-path-attribute-slides] 260 Haas, J., "Extended Experimental Path Attributes - IETF 97 261 Slides", November 2016, 262 . 265 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 266 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 267 DOI 10.17487/RFC5226, May 2008, 268 . 270 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 271 Yamagata, "Internal BGP as the Provider/Customer Edge 272 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", 273 RFC 6368, DOI 10.17487/RFC6368, September 2011, 274 . 276 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 277 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 278 2014, . 280 Appendix A. Comparisons to Other Features 282 Astute readers will note that this is not the first time BGP Path 283 Attributes have been "tunneled" inside of other Path Attributes. 284 [RFC6368] provided a mechanism by which an entire set of Path 285 Attributes could be tunneled inside of attribute 128 for purposes of 286 transparently passing received BGP Path Attributes in an Internet 287 Layer 3 VPN context from one Customer Edge (CE) router to another. 289 [RFC6368] suffered from two issues: 291 1. During its initial development, 4-byte AS numbers were starting 292 to be deployed. This lead to a change in the packet format of 293 the feature to accommodate the 4-byte ASes instead of the 294 previous 2-byte versions. 295 2. While this feature was intended solely to be used in a VPN 296 context, implementations that did not understand it similarly did 297 not strip it. This caused the VPN routes to carry attribute 128 298 in an Internet context after they were delivered to the target CE 299 router. 301 Due to these two issues, routes containing one version of this 302 feature that "escaped into the wild" eventually to be received by 303 other BGP speakers supporting a different version of the feature. 304 Each version would treat their opposite's encoding as a syntax error. 305 This resulted in BGP peering sessions being reset. This, and other 306 similar issues, was a motivation for [RFC6368]. 308 The second issue noted above is the motivation for 309 [I-D.ietf-idr-bgp-attribute-announcement]. 311 Appendix B. Discussion to this Date 313 This proposal was originally well-received on the IDR mailing list 314 and during its presentation at IETF. Comments included comparison to 315 existing mechanisms in LDP and IS-IS; Hannes Gredler notes that the 316 IS-IS feature is not used. 318 Another set of comments revolved around the structured format of the 319 PEN+FCN+VN and "why couldn't we simply have a very large first-come, 320 first-served code space". While the author agrees that this would 321 serve a very similar behavior, the author's belief after further 322 consideration is that: 324 o Involving IANA, even when the process is very light weight, is 325 part of our existing issue. The Enterprise numbering space 326 permits completely internal management during development of new 327 features. 328 o There is no fundamental "burden" of multiple implementors 329 rendezvousing around a common PEN+FCN+VN during interoperability 330 testing. The motivation after such testing should be to request a 331 valid BGP Path Attribute code point using existing IETF 332 procedures. 334 Another comment was about the possibility of utilizing this mechanism 335 as a long-term private BGP Path Attribute feature. Such behavior may 336 be a valid use case, however, there remains a need to provide for 337 automatic filtering of experimental work. 339 This brings the final comment that both this new Path Attribute and 340 potentially each of the experiments in the Feature Data should be 341 covered by [I-D.ietf-idr-bgp-attribute-announcement] or something 342 similar. This would include additional procedure to provide for 343 remote filtering of the TLVs defined in this document. Progressing 344 this document, and the use case of long term private Path Attributes 345 as noted in the prior section, should be considered after the 346 attribute-announcement draft receives further feedback. 348 Author's Address 350 Jeffrey Haas 351 Juniper Networks, Inc. 352 1133 Innovation Way 353 Sunnyvale, CA 94089 354 US 356 Email: jhaas@juniper.net