idnits 2.17.1 draft-ietf-trill-rbridge-extension-05.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 (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- 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 (June 20, 2012) is 4327 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Anoop Ghanwani 4 Updates: 6325 Dell 5 Vishwas Manral 6 HP 7 Yizhou Li 8 Huawei 9 Caitlin Bestler 10 Quantum 11 Expires: December 19, 2012 June 20, 2012 13 TRILL: Header Extension 14 16 Abstract 18 The IETF TRILL (Transparent Interconnection of Lots of Links) base 19 protocol specifies minimal hooks to safely support TRILL Header 20 extensions. This document specifies an initial extension providing 21 additional flag bits and specifies some of those bits. It updates RFC 22 6325. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the TRILL working group mailing list . 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 1.1 Conventions used in this document......................3 52 2. TRILL Header Extensions.................................4 53 2.1 RBridge Extended Flag Handling Requirements............5 54 2.2 No Critical Surprises..................................5 55 2.3 Extended Header Flags..................................6 56 2.3.1 Critical Summary Bits................................7 57 2.4 Conflict of Extensions.................................8 59 3. Specific Extended Header Flags..........................9 60 3.1 The RBridge Channel Alert Extended Flags...............9 62 4. Additions to IS-IS.....................................10 64 5. IANA Considerations....................................10 65 6. Security Considerations................................11 66 7. Acknowledgements.......................................11 67 8. Normative References...................................12 68 9. Informative References.................................12 70 Change History............................................13 72 1. Introduction 74 The base IETF TRILL (Transparent Interconnection of Lots of Links) 75 protocol [RFC6325] [RFC6326bis] provides a TRILL Header extension 76 feature and describes minimal hooks to safely support header 77 extension. (This feature is called "options" in Section 3.8 of 78 [RFC6325].) But, except for the first two bits, the TRILL base 79 protocol document does not specify the structure of extensions to the 80 TRILL Header nor the details of any particular extension. 82 This document is consistent with [RFC6325] and provides further 83 details. It specifies an initial extension word providing additional 84 flag bits and specifies some of those bits. Additional extensions, 85 including TLV (Type, Length, Value) encoded options, may be specified 86 in later documents, for example [Options]. 88 Section 2 below describes some general principles of TRILL header 89 extensions and an initial extension. Section 3 specifies pair of 90 flags in this initial extension. 92 1.1 Conventions used in this document 94 The terminology and acronyms defined in [RFC6325] are used herein 95 with the same meaning. Devices implementing the TRILL protocol are 96 referred to as RBridges (Routing Bridges) or TRILL Switches. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. TRILL Header Extensions 104 The base TRILL Protocol includes a feature for extension of the TRILL 105 Header (see [RFC6325] Sections 3.5 and 3.8). The 5-bit Op-Length 106 header field gives the length of the extensions to the TRILL Header 107 in units of 4 octets, which allows up to 124 octets of header 108 extension. If Op-Length is zero there are no header extensions 109 present; else, the extension area follows immediately after the 110 Ingress RBridge (Routing Bridge) Nickname field of the TRILL Header. 111 The first 32-bit word of the optional extensions area consists of an 112 extended flags area and critical summary bits as specified in this 113 document. 115 As described below, provision is made for 117 o hop-by-hop flags, which might affect any RBridge that receives 118 a TRILL Data frame with such a flag set, 120 o ingress-to-egress flags, which would only necessarily affect 121 the RBridge(s) where a TRILL frame is decapsulated, 123 o flags affecting an as yet unspecified class of RBridges, for 124 example border RBridges in a TRILL campus extended to support 125 multi-level IS-IS (Intermediate System to Intermediate System) 126 [MultiLevel], and 128 o both "critical" and "non-critical" flags. 130 Any RBridge receiving a frame with a critical hop-by-hop extension 131 that it does not implement MUST discard the frame because it is 132 unsafe to process the frame without understanding such a critical 133 extension. 135 Any egress RBridge receiving a frame with a critical ingress-to- 136 egress extension it does not implement MUST drop the frame if it is a 137 unicast frame (TRILL Header M bit = 0); if it is a multi-destination 138 TRILL Data frame (M=1), then it MUST NOT be egressed at that RBridge 139 but the egress RBridge still forwards such a frame on the 140 distribution tree. 142 Non-critical extensions can be safely ignored. 144 Any extended flag indicating a significant change in the structure or 145 interpretation of later parts of the frame which, if the extended 146 flag were ignored, could cause a failure of service or violation of 147 security policy MUST be a critical extension. If such an extended 148 flag affects any fields that transit RBridges will examine, it MUST 149 be a hop-by-hop critical extended flag. 151 Note: Most RBridges implementations are expected to be optimized 152 for simple and common cases of frame forwarding and processing. 153 Although the hard limit on the header extensions area length, the 154 32-bit alignment of the extension area, and the presence of 155 critical extension summary bits, as described below, are intended 156 to assist in the efficient hardware processing of frames with a 157 TRILL header extensions area, nevertheless the inclusion of 158 extensions may cause frame processing using a "slow path" with 159 inferior performance to "fast path" processing. Limited slow path 160 throughput of such frames could cause some of them to be 161 discarded. 163 2.1 RBridge Extended Flag Handling Requirements 165 All RBridges MUST check whether there are any critical flags set that 166 are necessarily applicable to their processing of the frame. To 167 assist in this task, critical summary bits are provided that cover 168 not only the extended flags specified herein but will cover any 169 further extensions that may be specified in future documents, for 170 example [Options]. If an RBridge does not implement all critical 171 flags in a TRILL Data frame, it MUST treat the frame as having an 172 unimplemented critical extension as described in Section 2. A transit 173 or egress RBridge may assume that the critical summary bits are 174 correct. 176 In addition, a transit RBridge: 178 o MAY set or clear hop-by-hop flags as specified for such flags; 179 o MUST adjust the length of the extensions area, including changing 180 Op-Length in the TRILL header, as appropriate if it adds or 181 removes the word of extended header flags; 182 o MUST, if it adds the word of extended header flags or changes any 183 critical flags, correctly set the critical summary bits in the 184 extended header flags word; 185 o MUST NOT remove the extended header flags word unless it is all 186 zero (either on arrival or after permitted modifications); 187 o MUST NOT set or clear ingress-to-egress or reserved extended 188 header flags except as specifically permitted in the specification 189 of such flags. 191 2.2 No Critical Surprises 193 RBridges advertise the extended header flags they support in IS-IS 194 PDUs (Protocol Data Units) [RFC6326bis]. Unless an RBridge advertises 195 support for a critical extended header flag, it will not normally 196 receive frames with that flag set. An RBridge is not required to 197 support any extensions. 199 An RBridge SHOULD NOT set a critical extended flag in a frame unless, 201 - for a critical hop-by-hop extended header flag, it has determined 202 that the next hop RBridge or RBridges that will accept the frame 203 support that flag, 204 - for a critical ingress-to-egress extended header flag, it has 205 determined that the RBridge or RBridges that will egress the frame 206 support that flag, or 207 - for a critical reserved extended header flag, it may set such a 208 flag only if it understands which RBridges it is applicable to and 209 has determined that those RBridges that will accept the frame 210 support that flag. 212 "SHOULD NOT" is specified above since there may be cases where it is 213 acceptable for those frames, particularly for the multi-destination 214 case, to be discarded or not egressed by any RBridges that do not 215 implement the extended flag. 217 2.3 Extended Header Flags 219 If any extensions are present in a TRILL Header, as indicated by a 220 non-zero Op-Length field, the first 32 bits of the extensions area 221 consist of Extended Header Flags, as described below. The remainder 222 of the extensions area, if any, after this initial 32 bits, may be 223 specified in later documents [Options]. 225 Any RBridge adding an extensions area to a TRILL Header must set the 226 first 32 bits to zero except when permitted or required to set one or 227 more of those bits as specified. For TRILL Data frames with 228 extensions present, any transit RBridge that does not discard the 229 frame MUST transparently copy the extended flags word, except for 230 modifications permitted by an extension implemented by that RBridge. 232 The word of Extended Header Flags is illustrated below and the 233 meanings of these bits is further described in the list following the 234 figure. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | ... additional optional 32-bit aligned words of extension | 242 | possibly including TLV extensions ... 244 (The first two critical summary bits are as specified in [RFC6325]. 245 In this document an "S", for Summary, has been added at the end of 246 their acronyms. A third critical summary bit is also specified herein 247 and its acronym also ends with an "S" for consistency.) 249 Bit(s) Description 250 --------------------- 252 0-3 Crit.: Critical summary bits. 253 0 CHbHS: Critical Hop-by-Hop extension(s) are present. 254 1 CItES: Critical Ingress-to-Egress extension(s) are present. 255 2 CRSVS: Critical reserved extension(s) are present. 257 3-7 CHbH: Critical Hob-by-Hop extended Flag bits. 258 8-13 NCHbH: Non-critical Hop-by-Hop extended Flag bits. 260 14-16 CRSV: Critical Reserved extended Flag bits. 261 17-20 NCRSV: Non-critical Reserved extended Flag bits. 263 21-26 CItE: Critical Ingress-to-Egress extended Flag bits. 264 27-31 NCItE: Non-critical Ingress-to-Egress extended Flag bits. 266 2.3.1 Critical Summary Bits 268 The top three bits of the Extended Header Flags area, bits 0, 1, and 269 2 above, are called the critical summary bits. They summarize the 270 presence of critical extensions as follows: 272 CHbHS: If the CHbHS (Critical Hop by Hop Summary) bit is one, one or 273 more critical hop-by-hop extensions are present. These might be 274 critical hop-by-hop extended header flags or critical hop-by-hop 275 extensions after the first word in the extensions area. Transit 276 RBridges that do not support all of the critical hop-by-hop 277 extensions present, for example an RBridge that supported no 278 critical hop-by-hop extensions, MUST drop the frame. If the CHbHS 279 bit is zero, the frame is safe, from the point of view of 280 extensions processing, for a transit RBridge to forward, 281 regardless of what extensions that RBridge does or does not 282 support. 284 CItES: If the CItES (Critical Ingress to Egress Summary) bit is a 285 one, one or more critical ingress-to-egress extensions are 286 present. These might be critical ingress-to-egress extended header 287 flags or critical ingress-to-egress extensions after the first 288 word in the extensions area. If the CItES bit is zero, no such 289 extensions are present. If either CHbHS or CItES is non-zero, 290 egress RBridges that do not support all critical extensions 291 present, for example an RBridge that supports no critical 292 extensions, MUST drop the frame. If both CHbHS and CItES are 293 zero, the frame is safe, from the point of view of extensions, for 294 an egress RBridge to process, regardless of what extensions that 295 RBridge does or does not support. 297 CRSVS: If the CRSVS (Critical Reserved Summary) bit is a one, one or 298 more critical extensions are present that are reserved to apply to 299 a class of RBridges to be specified in the future, for example 300 border RBridges in a TRILL campus extended to support multi-level 301 IS-IS. This class will be a subset of transit RBridges. RBridges 302 in this class MUST drop frames with the CRSVS bit set unless they 303 implement all critical hop-by-hop and all critical reserved 304 extensions present in the frame. 306 The critical summary bits enable simple and efficient processing of 307 TRILL Data frames by egress RBridges that support no critical 308 extensions, by transit RBridges that support no critical hop-by-hop 309 extensions, and by RBridges in the reserved class that support no 310 critical hop-by-hop or reserved extensions. Such RBridges need only 311 check whether Op-Length is non-zero and, if it is, the top one, two, 312 or three bits just after the fixed portion of the TRILL Header. Based 313 on those three bits, such RBridges can decide whether to discard or 314 forward / process the frame. 316 2.4 Conflict of Extensions 318 Defining TRILL extensions including Extended Header Flags that 319 conflict with each other would be undesirable. Should conflicting 320 extensions appear in the same packet, the results would be 321 unpredictable, if different implementations processed them in 322 different orders. While rules could be defined to specify how to 323 predictably process conflicting extensions, such rules would also 324 limit implementation flexibility and could impose substantial 325 processing burdens. 327 Conflicting extensions SHOULD NOT be defined, but if they are, 328 careful thought should be given as to whether and how to specify the 329 handling of conflicting extensions. 331 3. Specific Extended Header Flags 333 The table below shows the state of TRILL Header extended flag 334 assignments. See Section 5 for IANA Considerations. 336 Bits Purpose Section 337 ------------------------------------------------------ 338 0-2 Critical Summary Bits 2.3.1 339 3-6 available critical hop-by-hop flags 340 7 Critical Channel Alert Flag 3.1 341 8 Non-critical Channel Alert Flag 3.1 342 9-13 available non-critical hop-by-hop flags 343 14-16 available critical reserved flags 344 17-20 available non-critical reserved flags 345 21-26 available critical ingress-to-egress flags 346 27-31 available non-critical ingress-to-egress flags 348 Table 1. Extended Header Flags Area 350 3.1 The RBridge Channel Alert Extended Flags 352 The RBridge Channel Alert Extended Flags indicates that the frame is 353 an RBridge Channel frame [Channel] that requests processing at each 354 hop. 356 If the critical Channel Alert flag (bit 7) is a one and the RBridge 357 does not implement the RBridge Channel feature or the particular 358 RBridge Channel protocol involved [Channel] or the frame does not 359 actually appear to be an RBridge Channel message, then the frame is 360 discarded. This permits implementation, for example, of a Channel 361 message requiring strict source routing or the like, with assurance 362 that it will be discarded rather than deviate from the directed path. 364 If the frame is not discarded as above then the presence of either 365 the Critical or Non-critical hop-by-hop Channel Alert flag alerts 366 transit RBridges to the presence of an RBridge Channel message 367 [Channel] that may require special handling. The non-critical alert 368 flag supports, for example, an RBridge Channel protocol message 369 including a "record route" function where not recording transit 370 RBridges that do not support this function is acceptable. 372 4. Additions to IS-IS 374 RBridges use IS-IS LSP PDUs to inform other RBridges which Extended 375 Header Flags they support. The IS-IS PDU(s), TLV(s), or sub-TLV(s) 376 used to encode and advertise this information are specified in a 377 separate document [RFC6326bis]. 379 5. IANA Considerations 381 IANA is requested to create a subregistry within the TRILL Parameters 382 registry: The "TRILL Extended Header Flags" subregistry, that is 383 initially populated as specified in Table 1 in Section 3. References 384 in that table to sections of this document are to be replaced in the 385 IANA subregistry by references to this document as an RFC. 387 New TRILL Extended Header Flags are allocated by IETF Review 388 [RFC5226]. 390 6. Security Considerations 392 For general TRILL protocol security considerations, see [RFC6325]. 394 For security considerations related to extended header flags, see the 395 document where the flag is specified. 397 It is important that the critical summary bits in the Extended Header 398 Flags word be set properly. If set when critical extensions of the 399 appropriate category are not present, frames may be unnecessarily 400 discarded. If not set when critical extensions are present, frames 401 may be mishandled or corrupted and intended security policies may be 402 violated. 404 The RBridge Channel Alert extended flags have the following security 405 considerations. Implementations should keep in mind that they might 406 be erroneously set in a frame. If either RBridge Channel Alert flag 407 is found set in a frame that is not an RBridge Channel message 408 [Channel], the flag MAY be cleared and should have no effect except, 409 possibly, delaying processing of the frame. If either Channel Alert 410 flag is erroneously omitted from a frame, desired per hop processing 411 for the frame may not occur. 413 7. Acknowledgements 415 The following, listed in alphabetic order, are thanked for their 416 valuable contributions: Ben Campbell, Adrian Farrel, Barry Leiba, 417 and Thomas Narten. 419 This document was produced with raw nroff. All macros used were 420 defined in the source file 422 8. Normative References 424 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 428 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 429 2008. 431 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 432 Ghanwani, "Routing Bridges (RBridges): Base Protocol 433 Specification", July 2011. 435 [Channel] - draft-ietf-trill-rbridge-channel, work in progress. 437 [RFC6326bis] - draft-eastlake-isis-rfc6326bis, work in progress. 439 9. Informative References 441 [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in 442 progress. 444 [Options] - draft-ietf-trill-rbridge-options, work in progress. 445 - draft-eastlake-trill-rbridge-more-options, work in progress. 447 Change History 449 The sections below summarize changes between successive versions of 450 this draft. RFC Editor: Please delete this section before 451 publication. 453 Version 00 of this draft is an extract and simplification of draft- 454 ietf-trill-rbridge-options-05.txt as discussed at the TRILL Working 455 Group meeting at IETF 81 and on the TRILL WG mailing list. 457 From -00 to -01 459 1. Update Author Addresses. 461 2. Assorted editorial changes. 463 From -01 to -02 465 1. Addition of the Critical RBridge Channel Alert Flag. 467 2. Assorted editorial and author changes. 469 From -02 to -03 471 1. Replacement of Section 2.4 to eliminate detailed constraints on 472 the processing of conflicting extensions and to warn against the 473 future specification of conflicting options. 475 2. Minor editorial changes. 477 From -03 to -04 479 Editorial changes including the deletion of Section 2.3.2 that was 480 completely redundant with earlier parts of Section 2.3. 482 From -04 to -05 484 1. Add "Updates: 6325" to the first page header as this document 485 provides more details on the TRILL Header options area. 487 2. Expand first use of some acronyms and other editorial changes. 489 3. Change criteria for allocation of extended header flags from 490 Standards Action to IETF Review. 492 4. Editorial changes primarily based on IESG review. 494 Authors' Addresses 496 Donald Eastlake 497 Huawei R&D USA 498 155 Beaver Street 499 Milford, MA 01757 USA 501 Phone: +1-508-333-2270 502 email: d3e3e3@gmail.com 504 Anoop Ghanwani 505 Dell 506 350 Holger Way 507 San Jose, CA 95134 USA 509 Phone: +1-408-571-3500 510 Email: anoop@alumni.duke.edu 512 Vishwas Manral 513 HP Networking 514 19111 Pruneridge Avenue 515 Cupertino, CA 95014 USA 517 Phone: +1-408-477-0000 518 EMail: vishwas.manral@hp.com 520 Yizhou Li 521 Huawei Technologies 522 101 Software Avenue, 523 Nanjing 210012, China 525 Phone: +86-25-56622310 526 Email: liyizhou@huawei.com 528 Caitlin Bestler 529 Quantum 530 1650 Technology Drive , Suite 700 531 San Jose, CA 95110 USA 533 Phone: +1-408-944-4000 534 email: cait@asomi.com 536 Copyright and IPR Provisions 538 Copyright (c) 2012 IETF Trust and the persons identified as the 539 document authors. All rights reserved. 541 This document is subject to BCP 78 and the IETF Trust's Legal 542 Provisions Relating to IETF Documents 543 (http://trustee.ietf.org/license-info) in effect on the date of 544 publication of this document. Please review these documents 545 carefully, as they describe your rights and restrictions with respect 546 to this document. Code Components extracted from this document must 547 include Simplified BSD License text as described in Section 4.e of 548 the Trust Legal Provisions and are provided without warranty as 549 described in the Simplified BSD License. The definitive version of 550 an IETF Document is that published by, or under the auspices of, the 551 IETF. Versions of IETF Documents that are published by third parties, 552 including those that are translated into other languages, should not 553 be considered to be definitive versions of IETF Documents. The 554 definitive version of these Legal Provisions is that published by, or 555 under the auspices of, the IETF. Versions of these Legal Provisions 556 that are published by third parties, including those that are 557 translated into other languages, should not be considered to be 558 definitive versions of these Legal Provisions. For the avoidance of 559 doubt, each Contributor to the IETF Standards Process licenses each 560 Contribution that he or she makes as part of the IETF Standards 561 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 562 language to the contrary, or terms, conditions or rights that differ 563 from or are inconsistent with the rights and licenses granted under 564 RFC 5378, shall have any effect and shall be null and void, whether 565 published or posted by such Contributor, or included with or in such 566 Contribution.