idnits 2.17.1 draft-ietf-trill-rbridge-options-07.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 ([ExtendHeader]), 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 -- The document date (June 5, 2012) is 4315 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MoreISIS' Summary: 2 errors (**), 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 Dell 5 Vishwas Manral 6 HP Networking 7 Caitlin Bestler 8 Quantum 9 Expires: December 4, 2012 June 5, 2012 11 RBridges: Further TRILL Header Extensions 12 14 Abstract 16 The TRILL base protocol standard specifies minimal hooks to safely 17 support TRILL Header extensions. Initial extensions have been 18 specified in RFC [ExtendHeader]. This document specifies the format 19 for further such extensions and specifies some further specific 20 extensions. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the TRILL working group mailing list . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Conventions used in this document......................3 50 2. TRILL Header Options....................................4 51 2.1 RBridge Extension Handling Requirements................5 52 2.2 No Critical Surprises..................................6 53 2.3 Extensions Format......................................6 54 2.3.1 Flow ID Extension Word...............................7 55 2.3.2 TLV Extension Format.................................7 56 2.3.3 Marshaling of Extensions.............................9 57 2.4 Conflict of Extensions.................................9 59 3. The ECN Specific Extended Header Flags.................10 61 4. Specific TLV Extension.................................12 62 4.1 Test/Pad Extension....................................12 64 5. Additions to IS-IS.....................................13 65 6. IANA Considerations....................................13 66 7. Security Considerations................................14 67 8. Acknowledgements.......................................14 69 9. References.............................................15 70 9.1 Normative References..................................15 71 9.2 Informative References................................15 73 Change History............................................16 75 1. Introduction 77 The base TRILL protocol standard [RFC6325] provides a TRILL Header 78 extensions feature, called "options" in [RFC6325], and describes 79 minimal hooks to safely support header extensions. [ExtendHeader] 80 extends this by defining the first 32-bit word of the extensions 81 area, which consists of flags, and specifying an initial extended 82 header flag. This draft further specifies the format of and some 83 additional extensions: a special Flow ID field, ECN (Explicit 84 Congestion Notification) extended header flags, and a test/pad 85 extension. 87 Section 2 below describes the general principles, format, and 88 ordering of TRILL Header Extensions. 90 Section 3 describes the ECN specific extended flag extensions while 91 Section 4 describes a specific TLV encoded extension. 93 1.1 Conventions used in this document 95 The terminology and acronyms defined in [RFC6325] are used herein 96 with the same meaning. 98 In this documents, "IP" refers to both IPv4 and IPv6. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. TRILL Header Options 106 The base TRILL Protocol includes a feature for extension of the TRILL 107 Header (see [RFC6325] Sections 3.5 and 3.8). The 5-bit Op-Length 108 header field gives the length of the extension to the TRILL Header in 109 units of 4 octets, which allows up to 124 octets of header extension. 110 If Op-Length is zero there is no header extension present; else, this 111 area follows immediately after the Ingress Rbridge Nickname field of 112 the TRILL Header. The optional extensions area starts with a 4-octet 113 word of flags [ExtendHeader] possibly followed by additional 114 extension words and then TLV extensions. Each TLV extension present 115 is 32-bit aligned. 117 Provision is also made for both "critical" and "non-critical" 118 extensions. Any RBridge receiving a frame with a critical hop-by-hop 119 extension that it does not implement MUST discard the frame because 120 it is unsafe to process the frame without understanding the critical 121 extension. Any egress RBridge receiving a frame with a critical 122 ingress-to-egress extension it does not implement MUST drop the frame 123 if it is a known unicast frame; if it is a multi-destination TRILL 124 Data frame with a critical ingress-to-egress extension that the 125 RBridge does not implement, then it MUST NOT be egressed at that 126 RBridge but it is still forwarded on the distribution tree. Non- 127 critical extensions can be safely ignored. 129 Any extension indicating a significant change in the structure or 130 interpretation of later parts of the frame which, if the extension 131 were ignored, could cause a failure of service or violation of 132 security policy MUST be a critical extension. If such an extension 133 affects any fields that transit RBridges will examine, it MUST be a 134 hop-by-hop critical extension. 136 TLV extensions have a "mutability" flag that has a different meaning 137 for hop-by-hop extensions and for extensions other than hop-by-hop. 139 For extensions other than hop-by-hop, the mutability flag indicates 140 whether the value associated with the extension can change at a 141 transit RBridge (mutable extensions) or cannot so change (immutable 142 extensions). For example, an ingress-to-egress security extension 143 could protect the value of an immutable ingress-to-egress extension. 144 But such a security extension generally could not protect a mutable 145 value as a transit RBridge could change that value but might not have 146 the keys to recompute a signature or authentication code to take a 147 changed value into account. 149 For a non-critical hop-by-hop extension, the mutability flag 150 indicates whether a transit RBridge that does not implement the 151 extension is permitted (mutable) or not permitted (immutable) to 152 remove the extension. A transit RBridge is not required to remove a 153 hop-by-hop extension that it does not implement. 155 For critical hop-by-hop extensions, the mutability flag is 156 meaningless. If the RBridge does not implement the critical hop-by- 157 hop extension, it MUST drop the frame. If it does implement the 158 critical hop-by-hop extension, it will know whether or not it can 159 remove it. For critical hop-by-hop extensions, the mutability flag 160 is set to zero ("immutable") on transmission and ignored on receipt. 162 Note: Most RBridges implementations are expected to be optimized 163 for simple and common cases of frame forwarding and processing. 164 Although the hard limit on the header extensions area length, the 165 32-bit alignment of TLV extensions, and the presence of critical 166 extension summary bits, as described below, are intended to assist 167 in the efficient hardware based processing of frames with a TRILL 168 header extensions area, nevertheless the inclusion of extensions, 169 particularly TLV extensions, may cause frame processing using a 170 "slow path" with inferior performance to "fast path" processing. 171 Limited slow path throughput of such frames could cause them to be 172 discarded. 174 2.1 RBridge Extension Handling Requirements 176 These requirements are in addition to those in [ExtendHeader]. 178 All RBridges MUST be able to check whether there are any critical 179 extensions present that are necessarily applicable to their 180 processing of the frame. To assist in this task, critical summary 181 bits are provided that cover all extensions. If an RBridge does not 182 implement all such critical extensions present, it MUST discard the 183 frame or, in some circumstances as described above for certain multi- 184 destination frames, continue to forward the frame but MUST NOT egress 185 the frame. 187 Transit RBridges MUST be transparent to all immutable ingress-to- 188 egress and immutable reserved header extensions in frames that they 189 forward. Any changes made by a transit RBridge to a mutable ingress- 190 to-egress or reserved extension value MUST be a change permitted by 191 the specification of that extension. 193 In addition, a transit RBridge: 195 o MAY add, if space is available, or remove hop-by-hop extensions as 196 specified for such extensions; 197 o MAY change the value and/or length of a mutable ingress-to-egress 198 or reserved TLV extension as permitted by that extension's 199 specification and provided there is enough room if lengthening it; 200 o MUST adjust the length of the extensions area, including changing 201 Op-Length in the TRILL header, as appropriate for any changes it 202 has made; 204 o MUST NOT add, remove, or re-order ingress-to-egress or reserved 205 extensions. 206 o with regard to any non-critical hop-by-hop extensions that the 207 transit RBridge does not implement, it MAY remove them if they are 208 mutable but MUST transparently copy them when forwarding a frame 209 if they are immutable. 211 2.2 No Critical Surprises 213 RBridges advertise the ingress-to-egress and reserved extensions they 214 support in IS-IS PDUs [RFC6326bis] [MoreISIS] and advertise the hop- 215 by-hop extensions they support at a port on the link connected to 216 that port [MoreISIS]. An RBridge is not required to support any 217 extensions. 219 Unless an RBridge advertises support for a critical extension, it 220 will not normally receive frames with that extension. 222 An RBridge SHOULD NOT add a critical extension to a frame unless, 224 - for a critical hop-by-hop extensions, it has determined that the 225 next hop RBridge or RBridges that will accept the frame support 226 that extension, 227 - for a critical ingress-to-egress extensions, it has determined 228 that the RBridge or RBridges that will egress the frame support 229 that extension, or 230 - for a critical reserved extensions, it may add such an extension 231 only if it understands which RBridges it is applicable to and has 232 determined that those RBridges that will accept the frame support 233 that extension. 235 "SHOULD NOT" is specified since there may be cases where it is 236 acceptable for those frames, particularly for the multi-destination 237 case, to be discarded by any RBridges that do not implement the 238 extension. 240 2.3 Extensions Format 242 If any extensions are present in a TRILL Header, as indicated by a 243 non-zero Op-Length field, the first 32 bits of the extensions area 244 consist of extended header flags as specified in [ExtendHeader]. The 245 remainder of the extensions area, if any, after this initial 32, 246 consists of one extension word including a Flow ID field and then TLV 247 (Type Length Value) extensions aligned on 32-bit boundaries. Section 248 2.3.2 specifies the format of a TLV extension. Section 2.3.3 249 describes the marshaling of TLV extensions. 251 2.3.1 Flow ID Extension Word 253 In connection with the multi-pathing of frames, frames that are part 254 of the same order-dependent flow need to follow the same path. 255 Methods to determine flows are beyond the scope of the this document; 256 however, once the flow of a unicast frame has been determined, it can 257 be preserved and transmitted for use by subsequent RBridges. 259 A second extension word contains a Flow ID field is present if the 260 extension length TRILL Header field is 2 or larger. It is formatted 261 as follows: 263 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Reserved | Flow ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1. Flow ID Extension Word 271 The Reserved field in this extension word MUST be sent to zero, 272 transparently copied by transit RBridges, and ignored on receipt by 273 all RBridges. 275 The Flow ID can be considered a special hop-by-hop non-critical 276 option. It can be used for make ECMP forwarding decisions at any 277 transit RBridge. Because the ingress RBridge may know the most about 278 a frame, it is expected that this extension would most commonly be 279 added at the ingress RBridge but if not present, any transit RBridge 280 may add this extension. 282 When the Flow ID extension word is added, a preceding flags extension 283 word [ExtendHeader] must also be added. 285 2.3.2 TLV Extension Format 287 TRILL Header extensions, other than the extended header flags and 288 Flow ID extension word, are TLV encoded, with some flag bits in the 289 Type and Length octets, in the format show in Figure 2. 291 | 0 1 2 3 4 5 6 7 8 9|10| 11-15 | 292 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- 293 | APP |NC| Type |MU| Length | value... 294 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- 296 Figure 2. TLV Extension Structure 298 The APP field gives the applicability of the TLV as follows: 300 APP Description 301 =============== 303 0 Hop-by-hop: Extensions that are potentially applicable to 304 every RBridge that receives the frame. 306 1 Reserved1: Reserved for a class of RBridges to be specified. 308 2 Reserved2: Reserved for a class of RBridges to be specified. 310 3 Ingress-to-egress: Extensions that are only inserted at the 311 ingress and applicable at egress RBridges. Ingress-to-egress 312 extensions MAY also be examined and acted upon by transit 313 RBridges as specified in the particular extension. 315 For example, Reserved1 might in the future be specified to indicate 316 extensions applicable to multi-level IS-IS border RBridges 317 [MultiLevel] and Reserved2 to both border and egress RBridges. 319 Bit 2 in the first octet (NC) is zero for critical extensions and one 320 for non-critical extensions. 322 Bit 10 in the second octet (MU) is zero for immutable extensions and 323 one for mutable extensions. The APP, NC, Type, and MU fields 324 themselves MUST NOT be changed even for a mutable extension. 326 The seven-bit Type code extends from bit 3 through bit 9. The 327 extension Type may constrain the values of the APP, NC, and MU bits. 328 For example, a certain Type might require that the extension be 329 marked as a hop-by-hop, non-critical, mutable extension. If the APP, 330 NC, or MU bits have a value not permitted by the extension Type 331 specification for an extension that an RBridge must act on, the 332 RBridge MUST discard the frame. If these bits have a value not 333 permitted by the Type for an extension that an RBridge may ignore, 334 the RBridge MAY discard the frame. "MAY" is chosen in this case to 335 minimize the checking burden. 337 The Length field is an unsigned quantity giving the length of the 338 extension value in units of four octets. It gives the size of the 339 extension including the initial two Type and Length octets. The 340 Length field MUST NOT be such that the extension value extends beyond 341 the end of the total extensions area as specified by the TRILL Header 342 Op-Length. Thus, the value 31 is reserved and, when such a value is 343 noticed in a frame, the frame MUST be discarded. 345 2.3.3 Marshaling of Extensions 347 In a TRILL Header with extensions, those extensions start immediately 348 after the Ingress RBridge Nickname and fill the extensions area. TLV 349 extensions are 32-bit aligned. 351 TLV extensions start immediately after the initial four octets of 352 extended flags area [ExtendHeader] and the Flow ID extensions word 353 (see Section 2.3.1) and MUST appear in ascending order by the value 354 of the eleven high order bits (bits 0 through 10) of the Type and 355 Length octets considered as an unsigned integer in network byte 356 order. There MUST NOT be more than one extension in a frame with any 357 particular value of this eleven high order bits. Frames that violate 358 this paragraph are erroneous, will produce unspecified results, and 359 MAY be discarded. "MAY" is chosen to minimize the format-checking 360 burden on transit RBridges. 362 2.4 Conflict of Extensions 364 It is possible for extensions to conflict. Two or more extensions can 365 be present in a frame that direct an RBridge processing the frame to 366 do conflicting things or to change its interpretation of later parts 367 of the frame in conflicting ways. Such conflicts are resolved by 368 applying the following rules in the order given: 370 1. Any frame containing extensions that require mutually incompatible 371 changes in way later parts of the frame, after the extensions 372 area, are interpreted or structured MUST be discarded. (Such 373 extensions will be critical extensions, normally hop-by-hop 374 critical extensions.) 376 2. Critical extensions override non-critical extensions. 378 2. Within each of the two categories of critical and non-critical 379 extensions, the extension appearing first in lexical order in the 380 frame always overrides an extension appearing later in the frame. 381 For example a conflict between an extended flag and a TLV 382 extension is always resolved in favor of the extended flag. 384 3. The ECN Specific Extended Header Flags 386 RBridges MAY implement an ECN (Explicit Congestion Notification) 387 extension [RFC3168]. If implemented, it SHOULD be enabled by default 388 but can be disable on a per RBridge basis by configuration. 390 RBridges that do not implement this extension or on which it is 391 disabled simply (1) set bits 12 and 13 of the extended flags area to 392 zero when they add an extensions area to a TRILL Header and (2) 393 transparently copy those bits, if an extensions area is present, when 394 they forward a frame with a TRILL Header. 396 An RBridge that implements the ECN extension does the following, 397 which correspond to the recommended provisions of [RFC6040], when 398 that extension is enabled: 400 o When ingressing an IP frame that is ECN enabled (non-zero ECN 401 field), it MUST add an extensions area to the TRILL Header and 402 copy the two ECN bits from the IP header into extended header 403 flags 12 and 13. 404 o When ingressing a frame for a non-IP protocol, where that protocol 405 has a means of indicating ECN that is understood by the RBridge, 406 it MAY add an extensions area to the TRILL Header with the ECN 407 bits set from the ingressed frame. 408 o When forwarding a frame encountering congestion at an RBridge, if 409 an extensions area is present with extended flags 12 and 13 410 indicating ECN-capable transport, the RBridge MUST modify them to 411 the congestion experienced value. 412 o When egressing an IP frame, the RBridge MUST set the outgoing 413 native IP frame ECN field to the code point at the intersection of 414 the values for that field in the encapsulated IP frame (row) and 415 the TRILL extended Header ECN field (column) in Table 2 below or 416 drop the frame in the case where the TRILL header indicates 417 congestion experienced but the encapsulated native IP frame 418 indicates a not ECN-capable transport. (Such frame dropping is 419 necessary because IP transport that is not ECN-capable requires 420 dropped frames to sense congestion.) 421 o When egressing a non-IP protocol frame with a means of indicating 422 ECN that is understood by the RBridge, it MAY set the ECN 423 information in the egressed native frame by combining that 424 information in the TRILL extended header and the encapsulated non- 425 IP native frame as specified in Table 2. 427 The following table is modified from [RFC3168] and shows the meaning 428 of bit values in TRILL Header extended flags 12 and 13, bits 6 and 7 429 in the IPv4 TOS Byte, and bits 6 and 7 in the IPv6 Traffic Class 430 Octet: 432 Binary Meaning 433 ------ ------- 434 00 Not-ECT (Not ECN-Capable Transport) 435 01 ECT(1) (ECN-Capable Transport(1)) 436 10 ECT(0) (ECN-Capable Transport(0)) 437 11 CE (Congestion Experienced) 439 Table 1. ECN Field Bit Combinations 441 Table 2 below (adapted from [RFC6040]) shows how, at egress, to 442 combine the ECN information in the extended TRILL Header ECN field 443 with the ECN information in an encapsulated frame to produce the ECN 444 information to be carried in the resulting native frame. 446 +---------+-----------------------------------------------+ 447 | Inner | Arriving TRILL Header ECN Field | 448 | Native +---------+------------+------------+-----------+ 449 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 450 +---------+---------+------------+------------+-----------+ 451 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | (*) | 452 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 453 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 454 | CE | CE | CE | CE(*) | CE | 455 +---------+---------+------------+------------+-----------+ 457 Table 2: Egress ECN Behavior 459 An RBridge detects congestion either by monitoring its own queue 460 depths or from participation in a link-specific protocol. An RBridge 461 implementing the ECN extension MAY be configured to add congestion 462 experienced marking using ECN to any frame with a TRILL Header that 463 encounters congestion even if the frame was not previously marked as 464 ECN-capable or did not have an extensions area. 466 4. Specific TLV Extension 468 The table below shows the state of TRILL Header TLV extension Type 469 assignment. See Section 6 for IANA Considerations. 471 Type Purpose Section 472 --------------------------------------- 473 0x00 reserved 474 0x00-0x3F available 475 0x40 Test/Pad 4.1 476 0x41-0x7E available 477 0x7F reserved 479 Table 3. TLV Extension Types 481 The following subsection specifies a particular TRILL TLV extension. 483 4.1 Test/Pad Extension 485 This extension is intended for testing and padding. 487 A specific meaning for this extension with the critical flag set will 488 not be defined so, in that form, it MUST always be treated as an 489 unknown critical extension. If the critical flag is not set, the 490 extension does nothing. In either case, it may be any length that 491 will fit. Thus, for example, in the non-critical form, it can be used 492 to cause the encapsulated frame staring right after the extensions 493 area to be 64-bit aligned or for testing purposes. 495 o Type is 0x40. 496 o Length is variable. The value is ignored. 497 o IE may be zero or one. This extension has both hop-by-hop and 498 ingress-to-egress versions. 499 o NC is zero for the pad extension and one for the test 500 extension. 501 + The non-critical version of this extension does nothing. 502 + The critical version of this extension MUST always be 503 treated as an unknown critical extension. 504 o MU may be zero or one except that it must be zero if the other 505 flags indicate the extensions is a critical hop-by-hop 506 extension. This extension may be flagged as mutable or 507 immutable. 509 5. Additions to IS-IS 511 RBridges use IS-IS PDUs to inform other RBridges which extensions 512 they support. Support for extended header flags is indicated as 513 described in [RFC6326bis]. The specific IS-IS TLVs or sub-TLVs used 514 to encode and advertise support for TLV options will be specified in 515 a separate document. 517 6. IANA Considerations 519 IANA will create a subregistry within the TRILL registry for "TRILL 520 TLV Extension Types" that is initially populated as specified in 521 Table 3 in Section 4. References in that table to sections of this 522 document are to be replaced in the IANA subregistry by references to 523 this document as an RFC. 525 New TRILL TLV extension types are allocated by IETF Review [RFC5226]. 527 7. Security Considerations 529 For general TRILL protocol security considerations, see [RFC6325]. 531 In order to facilitate authentication, extensions SHOULD be specified 532 so they do not have alternative equivalent forms. Authentication of 533 anything with alternative equivalent forms almost always requires 534 canonicalization that an authenticating RBridge ignorant of the 535 extension would be unable to do and that may be complex and error 536 prone even for an RBridge knowledgeable of the extension. It is best 537 for any extension to have a unique encoding. 539 8. Acknowledgements 541 The following are thanked for their contributions: Bob Briscoe. 543 This document was prepared with basic NROFF. All macros used were 544 defined in the source file. 546 9. References 548 Normative and informative references for this document are given 549 below. 551 9.1 Normative References 553 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 557 of Explicit Congestion Notification (ECN) to IP", RFC 3168, 558 September 2001. 560 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 561 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 562 2008. 564 [RFC6040] - Briscoe, B., "Tunneling of Explicit Congestion 565 Notification", RFC 6040, November 2010 567 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 568 Ghanwani, "Routing Bridges (RBridges): Base Protocol 569 Specification", July 2011. 571 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 572 A. Ghanwani, "Transparent Interconnection of Lots of Links 573 (TRILL) Use of IS-IS", draft-eastlake-isis-rfc6326bis, work in 574 progress. 576 [ExtendHeader] - Eastlake, D., A. Ghanwani, V. Manral, C. Bestler, 577 draft-ietf-trill-rbridge-extension, work in progress. 579 [MoreISIS] - tbd 581 9.2 Informative References 583 [MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai, 584 "RBridges: Multilevel TRILL", draft-perlman-trill-rbridge- 585 multilevel, work in progress. 587 Change History 589 The sections below summarize changes between successive versions of 590 this draft. RFC Editor: Please delete this section before 591 publication. 593 Version 00 to 02 595 Change the requirement for TLV option ordering to be strictly ordered 596 by the value of the top nine bits of their first two bytes so that 597 the MU bit is included. 599 Specify meaning of mutability bit for hop-by-hop options. 601 Fix length of Flow ID Value at 2. 603 Require that options that may significantly affect the interpretation 604 or format of subsequent parts of the frame be critical options. 606 Version 02 to 03 608 Move Test/Pad extension into this document from the More Options 609 draft and move the More Flags option from this document into the More 610 Options draft. 612 Prohibit multiple occurrences of a TLV option in a frame. 614 Version 03 to 04 616 Restructure the bit encoded options area so that the initial 32 bits 617 include a 16-bit Flow ID, various TLV-option-present bits, and a more 618 extended flags bit that means another 32 bits of extended flags are 619 present. 621 Change the Length of TLV encoded options so that it is in units of 4 622 bytes, not 1, resulting in a bigger Type field. 624 Update Explicit Congestion Notification to follow RFC 6040. 626 Rename "bit encoded options" to be "extended header flags" or 627 "extended flags". 629 Version 04 to 05 631 Generally replace "option" with "extension". 633 Add the Alert critical hop-by-hop flag extension. 635 Replace MT with MU to avoid possible confusion with multiple 636 topologies. 638 Version 05 to 06 640 Update author info. 642 Update references for issuance of the TRILL base protocol as an RFC. 644 Remove material now in [ExtendHeader] and appropriately adjust 645 remaining material including adding references to [ExtendHeader]. 647 Expand the IE bit in the TLV extension header to the two-bit APP 648 field so as to add the "reserved" type and adjust other material for 649 the existing of the reserved type of RBridge, different from hop-by- 650 hop and ingress-to-egress. 652 Version 06 to 07 654 Update date and version. 656 Authors' Addresses 658 Donald Eastlake 659 Huawei Technologies 660 155 Beaver Street 661 Milford, MA 01757 USA 663 Phone: +1-508-333-2270 664 Email: d3e3e3@gmail.com 666 Anoop Ghanwani 667 Dell 668 350 Holger Way 669 San Jose, CA 95134 USA 671 Phone: +1-408-571-3500 672 Email: anoop@alumni.duke.edu 674 Vishwas Manral 675 HP Networking 676 19111 Pruneridge Avenue 677 Cupertino, CA 95014 USA 679 Tel: +1-408-477-0000 680 Email: vishwa.manral@hp.com 682 Caitlin Bestler 683 Quantum 684 1650 Technology Drive , Suite 700 685 San Jose, CA 95110 USA 687 Phone: +1-408-944-4000 688 Email: cait@asomi.com 690 Copyright and IPR Provisions 692 Copyright (c) 2012 IETF Trust and the persons identified as the 693 document authors. All rights reserved. 695 This document is subject to BCP 78 and the IETF Trust's Legal 696 Provisions Relating to IETF Documents 697 (http://trustee.ietf.org/license-info) in effect on the date of 698 publication of this document. Please review these documents 699 carefully, as they describe your rights and restrictions with respect 700 to this document. Code Components extracted from this document must 701 include Simplified BSD License text as described in Section 4.e of 702 the Trust Legal Provisions and are provided without warranty as 703 described in the Simplified BSD License. The definitive version of 704 an IETF Document is that published by, or under the auspices of, the 705 IETF. Versions of IETF Documents that are published by third parties, 706 including those that are translated into other languages, should not 707 be considered to be definitive versions of IETF Documents. The 708 definitive version of these Legal Provisions is that published by, or 709 under the auspices of, the IETF. Versions of these Legal Provisions 710 that are published by third parties, including those that are 711 translated into other languages, should not be considered to be 712 definitive versions of these Legal Provisions. For the avoidance of 713 doubt, each Contributor to the IETF Standards Process licenses each 714 Contribution that he or she makes as part of the IETF Standards 715 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 716 language to the contrary, or terms, conditions or rights that differ 717 from or are inconsistent with the rights and licenses granted under 718 RFC 5378, shall have any effect and shall be null and void, whether 719 published or posted by such Contributor, or included with or in such 720 Contribution.