idnits 2.17.1 draft-eastlake-trill-ecn-support-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 date (July 8, 2016) is 2849 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 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 Bob Briscoe 4 Simula Research Lab 5 Expires: January 7, 2017 July 8, 2016 7 TRILL: ECN (Explicit Congestion Notification) Support 8 10 Abstract 12 Explicit congestion notification (ECN) allows a forwarding element to 13 notify downstream devices, including the destination, of the onset of 14 congestion without having to drop packets. This document extends this 15 capability to TRILL switches, including integration with IP ECN. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Distribution of this document is unlimited. Comments should be sent 23 to the TRILL working group mailing list . 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Conventions used in this document......................4 45 2. The ECN Specific Extended Header Flags..................5 47 3. ECN Support.............................................6 48 3.1 Ingress ECN Support....................................6 49 3.2 Transit ECN Support....................................6 50 3.3 Egress ECN Support.....................................7 52 4. TRILL Support for ECN Variants..........................9 53 4.1 Pre-Congestion Notification (PCN)......................9 54 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......10 56 5. IANA Considerations....................................11 58 6. Security Considerations................................12 59 7. Acknowledgements.......................................12 61 Normative References......................................13 62 Informative References....................................13 64 Appendix A. TRILL Transit RBridge Behavior to Support L4S.15 66 Authors' Addresses........................................17 68 1. Introduction 70 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 71 element, such as a router, to notify downstream devices, including 72 the destination, of the onset of congestion without having to drop 73 packets. Instead, the forwarding element can explicitly mark a 74 proportion of packets in an ECN field. For example, a two-bit field 75 is available for ECN marking in IP headers. 77 ............................. 78 . . 79 +---------+ . 80 +------+ | Ingress | . 81 |Source| +->| RBridge | . +----------+ 82 +---+--+ | | RB1 | . |Forwarding| 83 | | +------+--+ +----------+ . | Element | 84 v | . | | Transit | . | Y | 85 +-------+--+ . +---->| RBridges | . +--------+-+ 86 |Forwarding| . | RBn | . ^ | 87 | Element | . +-------+--+ +---------+ | v 88 | X | . | | Egress | | +-----------+ 89 +----------+ . +---->| RBridge +-+ |Destination| 90 . | RB9 | +-----------+ 91 . TRILL +---------+ 92 . campus . 93 ............................. 95 Figure 1. Example Path Forwarding Nodes 97 In [RFC3168] it was recognized that tunnels and lower layer protocols 98 would need to support ECN, and ECN markings would need to be 99 propagated, as headers were encapsulated and decapsulated. 100 [ECNencapGuide] gives guidelines on the addition of ECN to protocols 101 like TRILL that often encapsulate IP packets, including propagation 102 from and to IP. 104 In the figure above, assuming IP traffic, RB1 is an encapsulator and 105 RB9 a decapsulator. Traffic from Source to RB1 might or might not get 106 marked as having experienced congestion in forwarding elements, such 107 as X, before being encapsulated at ingress RB1. Any such ECN marking 108 is encapsulated with a TRILL Header. 110 This specification provides for any ECN marking in the traffic at the 111 ingress to be copied into the TRILL Extension Header Flags Word. It 112 also enables a congested transit RBridge such as RBn or RB1 above to 113 introduce congestion marking into the Extension Header Flags Word. 115 At RB9, the TRILL egress, it specifies how any ECN markings in the 116 TRILL Header Flags Word and in the encapsulated traffic are combined 117 so that subsequent forwarding elements, such as Y and the 118 Destination, can see if congestion was experienced at any previous 119 point in the path from Source. 121 A large part of the guidelines for adding ECN to lower layer 122 protocols [ECNencapGuide] concerns safe propagation of congestion 123 notifications in scenarios where some of the nodes do not support or 124 understand ECN. Whichever Rbridges do not support ECN, this 125 specification ensures congestion notification will propagate safely 126 to Destination, as dropped rather than marked packets where 127 necessary. 129 1.1 Conventions used in this document 131 The terminology and acronyms defined in [RFC6325] are used herein 132 with the same meaning. 134 In this documents, "IP" refers to both IPv4 and IPv6. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 Acronyms: 142 AQM - Active Queue Management 144 CCE - Critical Congestion Experienced 146 CE - Congestion Experienced 148 CItE - Critical Ingress-to-Egress 150 ECN - Explicit Congestion Notification 152 ECT - ECN Capable Transport 154 L4S - Low Latency, Low Loss, Scalable throughput 156 NCHbH - Non-Critical Hop-by-Hop 158 NCCE - Non-Critical Congestion Experienced 160 Not-ECT - Not ECN-Capable Transport 162 PCN - Pre-Congestion Notification 164 2. The ECN Specific Extended Header Flags 166 The extension header fields for explicit congestion notification 167 (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit 168 Critical Congestion Experienced (CCE) field in the TRILL Header 169 Extension Flags Word [RFC7780]. 171 These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN 172 field consists of bits 12 and 13, which are in the range reserved for 173 non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 174 26, which is in the range reserved for Critical Ingress-to-Egress 175 (CItE) bits. See [RFC7780] and [RFC7179] for the meaning of the other 176 bits. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 182 |.....|.........|...........|.....|.......|...........|.........| 183 |C|C|C| |C|N| | | | | | | | | 184 |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | 185 |H|I|R| |C|C| | | Hop | | |C|Clr| | 186 |b|t|s| |A|A| | | Cnt | | |E| | | 187 |H|E|v| |F|F| | | | | | | | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 2 The ECN and CCE TRILL Header Extension Flags Word Fields 192 Table 1 shows the meaning of the codepoints in the TRILL-ECN field. 193 Note that the first three have the same meaning as the corresponding 194 ECN field codepoints in the IPv4 or IPv6 header as defined in 195 [RFC3168]. However codepoint 11 is called Non-Critical Congestion 196 Experienced (NCCE) to distinguish it from Congestion Experienced in 197 IP. 199 Binary Name Meaning 200 ------ ------- ----------------------------------- 201 00 Not-ECT Not ECN-Capable Transport 202 01 ECT(1) ECN-Capable Transport (1) 203 10 ECT(0) ECN-Capable Transport (0) 204 11 NCCE Non-Critical Congestion Experienced 206 Table 1. TRILL-ECN Field Codepoints 208 3. ECN Support 210 The subsections below describe the required behavior to support ECN 211 at TRILL ingress, transit, and egress. The ingress behavior logically 212 occurs as a native frame is encapsulated with a TRILL Header to 213 produce a TRILL Data packet. The transit behavior logically occurs in 214 all RBridges where TRILL Data packets are queues, usually at the 215 output port. The egress behavior logically occurs as a TRILL Data 216 packet is decapsulated and output as a native frame through an 217 RBridge port. 219 An RBridge that supports ECN MUST behave as described in the relevant 220 subsections below, which correspond to the recommended provisions of 221 [ECNencapGuide]. Nonetheless, the scheme is designed to safely 222 propagate some form of congestion notification even if some RBridges 223 in the path followed by a TRILL Data packet support ECN and others do 224 not. 226 3.1 Ingress ECN Support 228 The ingress behavior is as follows: 230 o When encapsulating an IP frame, the ingress RBridge MUST: 232 + set the F flag in the main TRILL header [RFC7780]; 233 + create a Flags Word as part of the TRILL Header; 234 + copy the two ECN bits from the IP header into the TRILL-ECN 235 field (Flags Word bits 12 and 13) 236 + ensure the CCE flag is cleared to zero (Flags Word bit 26). 238 o When encapsulating a frame for a non-IP protocol, where that 239 protocol has a means of indicating ECN that is understood by the 240 ingress RBridge, it MUST follow the guidelines in [ECNencapGuide] 241 to add a Flags Word to the TRILL Header. For a non-IP protocol 242 with a similar ECN field to IP, this would be achieved by copying 243 the TRILL-ECN field from the encapsulated native frame. 245 3.2 Transit ECN Support 247 The transit behavior is as follows: 249 o An RBridge that supports ECN MUST implement some form of active 250 queue management (AQM) according to the guidelines of [RFC7567]. 251 The RBridge detects congestion either by monitoring its own queue 252 depth or by participating in a link-specific protocol. 254 o If the TRILL header Flags Word is present, whenever the AQM 255 algorithm decides to indicate congestion on a TRILL Data packet it 256 MUST set the CCE flag (Flags Word bit 26). 258 o If the TRILL header Flags Word is not present, to indicate 259 congestion the RBridge will either drop the packet or it MAY do 260 all of the following instead: 262 + set the F flag in the main TRILL header; 263 + add a Flags Word; 264 + set the TRILL-ECN field to Not-ECT (00); 265 + and set the CCE flag and the Ingress-to-Egress critical summary 266 bit (CRIbE). 268 Note that a transit RBridge that supports ECN does not refer to the 269 TRILL-ECN field before signalling CCE in a packet. It signals CCE 270 irrespective of whether the packet indicates that the transport is 271 ECN-capable. The egress/decapsulation behavior (described next) 272 ensures that a CCE indication is converted to a drop if the transport 273 is not ECN-capable. 275 3.3 Egress ECN Support 277 If the egress RBridge does not support ECN, it will ignore bits 12 278 and 13 of any Flags Word that is present, because it does not contain 279 any special ECN logic. Nonetheless, if a transit RBridge has set the 280 CCE flag, the egress will drop the packet. This is because drop is 281 the default behavior for an RBridge decapsulating a Critical Ingress- 282 to-Egress flag when it has no specific logic to understand it. Drop 283 is the intended behavior for such a packet, as required by 284 [ECNencapGuide]. 286 If an RBridge supports ECN, the egress behavior is as follows: 288 o When decapsulating an inner IP packet, the RBridge sets the ECN 289 field of the outgoing native IP packet using Table 2. It MUST set 290 the ECN field of the outgoing IP packet to the codepoint at the 291 intersection of the row for the arriving encapsulated IP packet 292 and the column for 3-bit ECN codepoint in the arriving outer TRILL 293 Data packet header. 294 The name of the TRILL 3-bit ECN codepoint is defined using the 295 combination of the TRILL-ECN and CCE fields in Table 3. 296 Specifically, the TRILL 3-bit ECN codepoint is called CE if either 297 NCCE or CCE is set in the TRILL Header Extension Flags Word. 298 Otherwise it has the same name as the 2-bit TRILL-ECN codepoint. 299 In the case where the TRILL 3-bit ECN codepoint indicates 300 congestion experienced (CE) but the encapsulated native IP frame 301 indicates a not ECN-capable transport (Not-ECT), it can be seen 302 that the RBridge MUST drop the packet. Such packet dropping is 303 necessary because a transport above the IP layer that is not ECN- 304 capable will have no ECN logic, so it will only understand dropped 305 packets as an indication of congestion. 307 o When decapsulating a non-IP protocol frame with a means of 308 indicating ECN that is understood by the RBridge, it MUST follow 309 the guideines in [ECNencapGuide] when setting the ECN information 310 in the decapsulated native frame. For a non-IP protocol with a 311 similar ECN field to IP, this would be achieved by combining the 312 information in the TRILL Header flags word with the encapsulated 313 non-IP native frame, as specified in Table 2. 315 +---------+-----------------------------------------------+ 316 | Inner | Arriving TRILL 3-bit ECN Codepoint Name | 317 | Native +---------+------------+------------+-----------+ 318 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 319 +---------+---------+------------+------------+-----------+ 320 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | 321 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 322 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 323 | CE | CE | CE | CE(*) | CE | 324 +---------+---------+------------+------------+-----------+ 326 Table 2: Egress ECN Behavior 328 An asterisk in the above table indicates a currently unused 329 combination that SHOULD be logged. In contrast to [RFC6040], in TRILL 330 the drop condition is the result of a valid combination of events and 331 need not be logged. 333 +------------+-----+---------------------+ 334 | TRILL-ECN | CCE | Arriving TRILL 3-bit| 335 | | | ECN codepoint name | 336 +------------+-----+---------------------+ 337 | Not-ECT 00 | 0 | Not-ECT | 338 | ECT(1) 01 | 0 | ECT(1) | 339 | ECT(0) 10 | 0 | ECT(0) | 340 | NCCE 11 | 0 | CE | 341 | Not-ECT 00 | 1 | CE | 342 | ECT(1) 01 | 1 | CE | 343 | ECT(0) 10 | 1 | CE | 344 | NCCE 11 | 1 | CE | 345 +------------+-----+---------------------+ 347 Table 3: Mapping of TRILL-ECN and CCE Fields to TRILL 3-bit ECN 348 Codepoint Name 350 4. TRILL Support for ECN Variants 352 This section is informative, not normative. 354 Section 3 specifies interworking between TRILL and the original 355 standardized form of ECN in IP [RFC3168]. 357 The ECN wire protocol for TRILL (Section 2) has been designed to 358 support the other known variants of ECN, as detailed below. New 359 variants of ECN will have to comply with the guidelines for defining 360 alternative ECN semantics [RFC4774]. It is expected that the TRILL 361 ECN wire protocol is generic enough to support such potential future 362 variants. 364 4.1 Pre-Congestion Notification (PCN) 366 The PCN wire protocol [RFC6660] is recognised by the use of a PCN- 367 compatible Diffserv codepoint in the IP header and a non-zero IP-ECN 368 field. For TRILL or any lower layer protocol, equivalent traffic 369 classification codepoints would have to be defined, but that is 370 outside the scope of the current document. 372 The PCN wire protocol is similar to ECN, except it indicates 373 congestion with two levels of severity. It uses: 375 o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) 376 codepoint 378 o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked 379 (ThM) codepoint. 381 To implement PCN on a transit RBridge would require a detailed 382 specification. But in brief: 384 o the TRILL Critical Congestion Experienced (CCE) flag would be used 385 for the Excess-Traffic-Marked (ETM) codepoint; 387 o ECT(1) in the TRILL-ECN field would be used for the Threshold- 388 Marked codepoint. 390 Then the ingress and egress behaviors defined in Section 3 would not 391 need to be altered to ensure support for PCN as well as ECN. 393 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) 395 L4S is currently only a proposal being considered for adoption onto 396 the IETF's experimental track. An outline of how a transit TRILL 397 RBridge would support L4S [ECNL4S] is given in Appendix A. 399 5. IANA Considerations 401 IANA is requested to update the TRILL Extended Header Flags registry 402 by replacing the lines for bits 9-13 and for bits 21-26 with the 403 following: 405 Bits Purpose Reference 406 ----- ------- --------- 407 9-11 available non-critical hop-by-hop flags 408 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 410 21-25 available critical ingress-to-egress flags 411 26 Critical Congestion Experienced (CCE) [this doc] 413 6. Security Considerations 415 TBD 417 For ECN tunneling security considerations, see [RFC6040]. 419 For general TRILL protocol security considerations, see [RFC6325]. 421 7. Acknowledgements 423 This document was prepared with basic NROFF. All macros used were 424 defined in the source file. 426 Normative References 428 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 430 March 1997, . 432 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 433 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 434 10.17487/RFC3168, September 2001, . 437 [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the 438 Explicit Congestion Notification (ECN) Field", BCP 124, RFC 439 4774, DOI 10.17487/RFC4774, November 2006, . 442 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 443 Ghanwani, "Routing Bridges (RBridges): Base Protocol 444 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 445 . 447 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 448 C. Bestler, "Transparent Interconnection of Lots of Links 449 (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 450 2014, . 452 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 453 Recommendations Regarding Active Queue Management", BCP 197, 454 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 457 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 458 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 459 Lots of Links (TRILL): Clarifications, Corrections, and 460 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 461 . 463 [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, 464 "Guidelines for Adding Congestion Notification to Protocols 465 that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, 466 work in progress. 468 Informative References 470 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 471 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 472 . 474 [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 475 Pre-Congestion Notification (PCN) States in the IP Header Using 476 a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 477 10.17487/RFC6660, July 2012, . 480 [ECNL4S] - K. De Schepper, B. Briscoe, I. Tsang, "Identifying 481 Modified Explicit Congestion Notification (ECN) Semantics for 482 Ultra-Low Queueing Delay", draft-briscoe-tsvwg-ecn-l4s-id, work 483 in progress. 485 Appendix A. TRILL Transit RBridge Behavior to Support L4S 487 An initial specification of the Low Latency, Low Loss, Scalable 488 throughput (L4S) wire protocol for IP is given in [ECNL4S]. It is 489 similar to the original ECN wire protoocl for IP [RFC3168], except: 491 o An AQM that supports L4S classifies packets with ECT(1) or CE in 492 the IP header into an L4S queue and a "Classic" queue otherwise. 494 o the meaning of CE markings applied by an L4S queue is not the same 495 as the meaning of a drop by a "Classic" queue (contrary to the 496 original requirement for ECN [RFC3168]). Instead the likelihood 497 that the Classic queue drops packets is defined as the square of 498 the likelihood that the L4S queue marks packets (e.g. when there 499 is a drop probability of 0.0009 (0.09%) the L4S marking 500 probability will be 0.03 (3%)). 502 This seems to present a problem for the way that a transit TRILL 503 RBridge defers the choice between marking and dropping to the egress. 504 Nonetheless, the following pseudocode outlines how a transit TRILL 505 RBridge can implement L4S marking in such a way that the egress 506 behavior already described in Section 3.3 for Classic ECN [RFC3168] 507 will produce the desired outcome. 509 /* p is an internal variable calculated by any L4S AQM 510 * dependent on the delay being experienced in the Classic queue. 511 */ 513 % Classic Queue on TRILL transit 514 if (p > max(random(), random()) ) 515 mark(CCE) % likelihood: p^2 517 % L4S Queue on TRILL transit 518 if (p > max(random()) ) { 519 if (p > max(random()) ) 520 mark(CCE) % likelihood: p^2 521 else 522 mark(NCCE) % likelihood: p - p^2 523 } 525 With the above transit behavior, an egress that supports ECN (Section 526 3.3) will drop packets or propagate their ECN markings depending on 527 whether the arriving inner header is from a non-ECN-capable or ECN- 528 capable transport. 530 Even if an egress has no L4S-specific logic of its own, it will drop 531 packets with the square of the probability that an egress would if it 532 did support ECN, for the following reasons: 534 o Egress with ECN support: 536 + L4S: propagates both the Critical and Non-Critical CE marks 537 (CCE & NCCE) as a CE mark. 539 Likelihood: p^2 + p - p^2 = p 541 + Classic: Propagates CCE marks as CE or drop, depending on 542 inner. 544 Likelihood: p^2 546 o Egress without ECN support: 548 + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. 550 Likelihood: p^2 552 + Classic: drops CCE marks. 554 Likelihood: p^2 556 Authors' Addresses 558 Donald E. Eastlake, 3rd 559 Huawei Technologies 560 155 Beaver Street 561 Milford, MA 01757 USA 563 Tel: +1-508-333-2270 564 Email: d3e3e3@gmail.com 566 Bob Briscoe (editor) 567 Simula Research Lab 569 Email: ietf@bobbriscoe.net 570 URI: http://bobbriscoe.net/ 572 Copyright and IPR Provisions 574 Copyright (c) 2016 IETF Trust and the persons identified as the 575 document authors. All rights reserved. 577 This document is subject to BCP 78 and the IETF Trust's Legal 578 Provisions Relating to IETF Documents 579 (http://trustee.ietf.org/license-info) in effect on the date of 580 publication of this document. Please review these documents 581 carefully, as they describe your rights and restrictions with respect 582 to this document. Code Components extracted from this document must 583 include Simplified BSD License text as described in Section 4.e of 584 the Trust Legal Provisions and are provided without warranty as 585 described in the Simplified BSD License. The definitive version of 586 an IETF Document is that published by, or under the auspices of, the 587 IETF. Versions of IETF Documents that are published by third parties, 588 including those that are translated into other languages, should not 589 be considered to be definitive versions of IETF Documents. The 590 definitive version of these Legal Provisions is that published by, or 591 under the auspices of, the IETF. Versions of these Legal Provisions 592 that are published by third parties, including those that are 593 translated into other languages, should not be considered to be 594 definitive versions of these Legal Provisions. For the avoidance of 595 doubt, each Contributor to the IETF Standards Process licenses each 596 Contribution that he or she makes as part of the IETF Standards 597 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 598 language to the contrary, or terms, conditions or rights that differ 599 from or are inconsistent with the rights and licenses granted under 600 RFC 5378, shall have any effect and shall be null and void, whether 601 published or posted by such Contributor, or included with or in such 602 Contribution.