idnits 2.17.1 draft-ietf-idr-bgp-attribute-announcement-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The second least significant bit ("C") is defined as the Member-AS Scope bit, which is used to indicate that an optional attribute cannot be announced outside a given Member-AS boundary. When set, the given optional attribute MUST be filtered by the sending BGP speaker at a Member-AS boundary. If the "C" bit is set then the "O" bit defined in BGP Path Attribute Flag field MUST be set. Otherwise a BGP speaker MUST consider an attribute as an error and malformed. "C" bit SHOULD only be set when an Autonomous System is configured as a BGP Confederation. A BGP speaker MUST not transmit an attribute with "C" bit set to peers that are not members of the local confederation. Otherwise a BGP speaker MUST consider an attribute as an error and malformed. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2016) is 2848 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) == Missing Reference: 'RFC4724' is mentioned on line 353, but not defined == Missing Reference: 'RFC3392' is mentioned on line 345, but not defined ** Obsolete undefined reference: RFC 3392 (Obsoleted by RFC 5492) == Missing Reference: 'RFC4486' is mentioned on line 349, but not defined Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Uttaro 5 Expires: January 9, 2017 ATT 6 B. Decraene 7 Orange 8 W. Henderickx 9 Alcatel Lucent 10 J. Haas 11 Juniper Networks 12 July 8, 2016 14 Constrain Attribute announcement within BGP 15 draft-ietf-idr-bgp-attribute-announcement-00.txt 17 Abstract 19 [RFC4271] defines four different categories of BGP Path attributes. 20 The different Path attribute categories can be identified by the 21 attribute flag values. These flags help identify if an attribute is 22 optional or well-known, Transitive or non-Transitive, Partial, or of 23 an Extended length type. BGP attribute announcement depends on 24 whether an attribute is a well-known or optional, and whether an 25 attribute is a transitive or non-transitive. BGP implementations 26 MUST recognize all well-known attributes. The well-known attributes 27 are always Transitive. It is not required for BGP implementations to 28 recognise all the Optional attributes. The Optional attributes could 29 be Transitive or Non-Transitive. BGP implementations MUST store and 30 forward any Unknown Optional Transitive attributes and ignore and 31 drop any Unknown Optional Non-Transitive attributes. 33 Currently, there is no way to confine the scope of Path attributes 34 within a given Autonomous System (AS) or a given BGP member-AS in 35 Confederation. This draft defines attribute extensions that help 36 confine the scope of Optional attributes within a given AS or a given 37 BGP member-AS in Confederation 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 9, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 87 2. Path Attribute Format . . . . . . . . . . . . . . . . . . . . 4 88 3. Extended Path Attribute Flags . . . . . . . . . . . . . . . . 4 89 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 92 6.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 7 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 95 7.2. Information References . . . . . . . . . . . . . . . . . 8 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 98 1. Introduction 100 [RFC4271] defines four different categories of BGP Path attributes. 101 The different Path attribute categories can be identified by the 102 attribute flag values. These flags help identify if an attribute is 103 optional or well-known, Transitive or non-Transitive, Partial, or of 104 an Extended length type. BGP attribute announcement depends on 105 whether an attribute is a well-known or optional, and whether an 106 attribute is a transitive or non-transitive. BGP implementations 107 MUST recognize all well-known attributes. The well-known attributes 108 are always Transitive. It is not required for BGP implementations to 109 recognise all the Optional attributes. The Optional attributes could 110 be Transitive or Non-Transitive. BGP implementations MUST store and 111 forward any Unknown Optional Transitive attributes and ignore and 112 drop any Unknown Optional Non-Transitive attributes. 114 Optional Transitive attributes help foster partial deployments of 115 newer BGP features. Alternatively, Optional Non-Transitive 116 attributes are drop by BGP speakers that do not recognise the 117 attribute. The optional attributes in their current definition do 118 not provide any automated attribute level filtering to control the 119 scope of announcements within a given AS or a BGP member-AS in 120 Confederation. Scoped announcements of attributes may be needed in 121 certain scenarios. Announcing attributes beyond their intended scope 122 MAY result in breakage of functionalities or leaking of any undesired 123 information. 125 This draft defines new attribute extensions that help confine the 126 scope of Path attributes; in particular Optional attributes within a 127 given Autonomous System or a given BGP member-AS in confederation or 128 a given Administrative domain. Note that "BGP Member-AS in 129 Confederation" and "Member-AS" are used entirely interchangeably 130 thoughout this document. 132 As part of new attribute extensions, this draft defines a new 133 attribute format to incorporate the scoping information. The new 134 attribute format applies to all the new attribute types that will be 135 defined moving forward. The newly defined attribute scoping is 136 specifically for newer attributes that explicitly state their use of 137 such scoping bits. These newly defined attributes would be either an 138 Optional transitive attributes (recognized and unrecognized) or any 139 recognized optional non-transtitive attributes. For any well-known 140 attributes or unrecognized optional non-transtive attributes, the 141 standard rules mentioned in [RFC4271] applies. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2. Path Attribute Format 151 [RFC4271] defines path attribute format as a triple [attribute type, 152 attribute length, attribute value] of a variable length. The 153 attribute value field is of a variable length. This draft augments 154 the path attribute value field and reserves first four bytes of path 155 attribute value field as path attribute extended flags field. All 156 the path attributes carrying extended flags field will have a minumum 157 attribute length of 4 bytes. The augmented path attribute format 158 applies to all the current undefined attributes types (30-39, 41-127, 159 129-254). Any attribute specific data follows the path attribute 160 extended flags field. 162 3. Extended Path Attribute Flags 164 [RFC4271] defines four type of BGP Path attributes using the 165 attribute Flags field as follows: 167 Path Attribute flags: 169 0 1 2 3 4 5 6 7 170 +-+-+-+-+-+-+-+-+ 171 |O|T|P|E| R | (R = MUST Be Zero) 172 +-+-+-+-+-+-+-+-+ 174 O Optional or a Well-known as defined in [RFC4271] 176 T Transitive or Non-Transtive as defined in [RFC4271] 178 P Partial as defined in [RFC4271] 180 E Extended Length type as defined in [RFC4271] 182 This draft introduces new Flags field known as Extended Path 183 Attribute Flags. The Extended Path Attribute Flags field is defined 184 as first 4 bytes of the Path Attribute's value field. This draft 185 introduces three new Extended Path Attributes flags as follows: 187 Path Attribute flags: 189 0 1 2 3 190 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | R |C|A| 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 (R = MUST Be Zero) 197 A AS Wide Scope 199 C Member-AS in Confederation Scope 201 M Multi-AS Scope 203 The first least significant bit ("A") is defined as the AS Wide Scope 204 bit, which is used to indicate that an optional attribute cannot be 205 announced outside a given AS boundary. When set, the given optional 206 attribute MUST be filtered by the sending BGP speaker at an AS 207 boundary. If the "A" bit is set then the "O" bit defined in BGP Path 208 Attribute Flag field MUST be set. Otherwise a BGP speaker MUST 209 consider an attribute as an error and malformed. 211 The second least significant bit ("C") is defined as the Member-AS 212 Scope bit, which is used to indicate that an optional attribute 213 cannot be announced outside a given Member-AS boundary. When set, 214 the given optional attribute MUST be filtered by the sending BGP 215 speaker at a Member-AS boundary. If the "C" bit is set then the "O" 216 bit defined in BGP Path Attribute Flag field MUST be set. Otherwise 217 a BGP speaker MUST consider an attribute as an error and malformed. 218 "C" bit SHOULD only be set when an Autonomous System is configured as 219 a BGP Confederation. A BGP speaker MUST not transmit an attribute 220 with "C" bit set to peers that are not members of the local 221 confederation. Otherwise a BGP speaker MUST consider an attribute as 222 an error and malformed. 224 Both the first and the second most least significant bit together is 225 defined as the Multiple AS Scope within a Single Administration. 226 When both the first and the second bits are set, optional attribute 227 can be traversed across multiple AS and filtered by the sending BGP 228 speaker at the Administration boundary. 230 The handling of malformed attributes SHOULD follow the procedures 231 mentioned in [RFC7606]. For any malformed attribute that is handled 232 by the "attribute discard" instead of the "treat-as-withdraw" 233 approach, it is critical to consider the potential impact. In 234 particular, if the attribute has an impact on the route selection or 235 installation process, then the presumption is that "attribute 236 discard" is unsafe and "treat-as-withdraw" procedure SHOULD be 237 considered. Otherwise, "attribute discard" procedure SHOULD be used. 239 4. Operation 241 When originating a well-known Path attribute, a BGP speaker MUST set 242 both the AS Wide Scope and Member-AS Scope bit to 0. When 243 originating an optional Path attribute, a BGP speaker SHOULD use and 244 set AS Wide Scope bit if it wants to restrict the announcement within 245 a AS. Similarly, when originating an optional Path attribute, a BGP 246 speaker SHOULD use and set Member-AS Scope bit if it wants to 247 restrict the announcement with a Member-AS. When originating an 248 optional Path attribute, a BGP speaker SHOULD use and set both 249 Member-AS Scope bit and AS Wide Scope bit if it wants to restrict the 250 announcement within a single administration composed of multiple 251 ASes. 253 When a BGP speaker receives or originates a route that includes any 254 well-known Path attribute with either a AS Wide Scope bit set or a 255 Member-AS Scope bit set then it SHOULD consider the attribute as 256 malformed. The handling of malformed attributes SHOULD follow the 257 procedures mentioned in [RFC7606]. 259 When a BGP speaker receives or originates a route that includes an 260 optional Path attribute with a AS Wide Scope bit set and a Member-AS 261 Scope bit cleared, it MUST remove that Path attribute when announcing 262 the route to any of its EBGP speakers. To deal with partial 263 deployments it is suggested that a BGP speaker SHOULD quietly ignore 264 and not pass along to other BGP peers any Path attribute received 265 from its EBGP peers with a AS Wide Scope bit set and a Member-AS 266 Scope bit cleared unless configured explicitly using a policy. 268 When a BGP speaker receives or originates a route that includes an 269 optional Path attribute with a Member-AS Scope bit set and a AS Wide 270 Scope bit cleared, it MUST remove that Path attribute when announcing 271 the route to any of its BGP speakers outside its Member-AS. To deal 272 with partial deployments it is suggested that a BGP speaker SHOULD 273 quietly ignore and not pass along to other BGP peers any Path 274 attribute received from its BGP peers with a Member-AS Scope bit set 275 and a AS Wide Scope bit cleared unless configured explicitly as a 276 policy. 278 When a BGP speaker receives or originates a route with an optional 279 path attribute that has both, the AS Wide Scope bit set and the 280 Member-AS Scope bit set, it MUST announce it to all its EBGP peers 281 within its administrative domain. Such an attribute MUST be filtered 282 when the attribute is announced outside its admistrative domain. The 283 BGP peering boundaries for an admistrative domain is a matter of a 284 policy and is set by the operators. 286 Any implementation that supports the extensions defined in this draft 287 MUST support the Enhanced Error handling defined in [RFC7606]. 288 Enhanced Error handling allows any error condition that MAY occur 289 during the parsing and processing of new attribute flags to be 290 treated according to the procedures of [RFC7606]. Furthermore, it is 291 assumed that the BGP network is enabled with Enhanced Error Handling 292 feature. This allows BGP speakers not implementing the draft 293 extensions to apply the procedures of [RFC7606]. 295 5. IANA Considerations 297 This draft define a new path attribute format for all undefined 298 attribute types. We request IANA to record the use of new path 299 attribute format for the following undefined attribute types (30-39, 300 41-127, 129-254). 302 This draft defines two new Extended Path attribute flags. We request 303 IANA to create a new registry for BGP Extended Path Attribute Flags 304 under BGP Path attributes as follows: 306 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 307 Extended Path Attributes Flags" Reference: draft-keyupate-idr-bgp- 308 attribute-annoucement-01 Registration Procedures as follows: 310 Bit Value (LSB) Type Reference 311 1 AS Wide Scope Current Draft 312 2 Member-AS in Confederation Current Draft 314 6. Security Considerations 316 This extension to BGP does not change the underlying security issues 317 inherent in the existing [RFC4724] and [RFC4271]. 319 6.1. Acknowledgements 321 The authors would like to thank John Scudder, Jakob Heitz, Shyam 322 Seturam, Juan Alcaide and Acee Lindem for the review and comments. 324 7. References 326 7.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 334 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 335 DOI 10.17487/RFC4271, January 2006, 336 . 338 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 339 Patel, "Revised Error Handling for BGP UPDATE Messages", 340 RFC 7606, DOI 10.17487/RFC7606, August 2015, 341 . 343 7.2. Information References 345 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 346 with BGP-4", RFC 3392, DOI 10.17487/RFC3392, November 347 2002, . 349 [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease 350 Notification Message", RFC 4486, DOI 10.17487/RFC4486, 351 April 2006, . 353 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 354 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 355 DOI 10.17487/RFC4724, January 2007, 356 . 358 Authors' Addresses 360 Keyur Patel 361 Cisco Systems 362 170 W. Tasman Drive 363 San Jose, CA 95134 364 USA 366 Email: keyupate@cisco.com 367 James Uttaro 368 ATT 369 200 S. Laurel Ave 370 Middletown, NJ 07748 371 USA 373 Email: uttaro@att.com 375 Bruno Decraene 376 Orange 378 Email: bruno.decraene@orange.com 380 Wim Henderickx 381 Alcatel Lucent 382 Copernicuslaan 50 383 Antwerp 2018 384 Belgium 386 Email: wim.henderickx@alcatel-lucent.com 388 Jeff Haas 389 Juniper Networks 390 1194 N. Mathilda Ave. 391 Sunnyvale, CA 94089 392 USA 394 Email: jhaas@juniper.net