idnits 2.17.1 draft-perlman-trill-rbridge-af-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2011) is 4775 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT Intel Labs 3 Intended status: Proposed Standard Donald Eastlake 3rd 4 Updates: RFCtrill Huawei 5 Ayan Banerjee 6 Cisco 7 Hu Fangwei 8 ZTE 9 Expires: September 28, 2011 March 29, 2011 11 RBridges: Appointed Forwarders 12 14 Abstract 16 The IETF TRILL protocol provides optimal pair-wise data forwarding 17 without configuration, safe forwarding even during periods of 18 temporary loops, and support for multipathing of both unicast and 19 multicast traffic. TRILL accomplishes this by using IS-IS link state 20 routing and by encapsulating traffic using a header that includes a 21 hop count. Devices that implement TRILL are called RBridges. 23 TRILL supports multi-access LAN links that can have multiple end 24 stations and RBridges attached. Where multiple RBridges are attached 25 to a link, native traffic to and from end stations on that link is 26 handled by a subset of those RBridges called Appointed Forwarders, 27 with the intent that native traffic in each VLAN be handled by at 28 most one RBridge. The purpose of this document is to improve the 29 documentation of the Appointed Forwarder mechanism. 31 Status of This Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. Distribution of this document is 35 unlimited. Comments should be sent to the TRILL working group 36 mailing list . 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Acknowledgements 55 The authors of [RFCtrill] and [RFCadj] and those listed in the 56 Acknowledgements section of [RFCtrill] and [RFCadj] are hereby 57 acknowledged by reference. 59 Table of Contents 61 1. Introduction............................................4 62 1.1 Terminology and Acronyms...............................5 64 2. Appointed Forwarders and Their Appointment..............6 65 2.1 Appointment Effects of DRB Elections...................6 66 2.2 Appointment and Removal by the DRB.....................7 67 2.2.1 Processing Forwarder Appointments....................7 68 2.2.2 Frequency of Appointments............................8 69 2.2.3 Appointed Forwarders Limit...........................8 71 3. The Inhibition Mechanism...............................10 72 4. Inhibited Appointed Forwarder Behavior.................12 73 5. Multiple Ports on the Same Link........................13 74 6. Security Considerations................................14 75 7. IANA Considerations....................................14 77 8. References.............................................15 78 8.1 Normative References..................................15 79 8.2 Informative References................................15 81 1. Introduction 83 The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data 84 frame forwarding without configuration, safe forwarding even during 85 periods of temporary loops, and support for multipathing of both 86 unicast and multicast traffic. TRILL accomplishes this by using [IS- 87 IS] [RFC1195] link state routing and encapsulating traffic using a 88 header that includes a hop count. The design supports VLANs and 89 optimization of the distribution of multi-destination frames based on 90 VLANs and IP derived multicast groups. Devices that implement TRILL 91 are called RBridges. 93 Section 2 of [RFCadj] explains the environment for which the TRILL 94 protocol is designed and the differences between that environment and 95 the typical Layer 3 routing environment. 97 TRILL supports multi-access LAN links that can have multiple end 98 stations and RBridges attached. Where multiple RBridges are attached 99 to a link, native traffic to and from end stations on that link is 100 handled by a subset of those RBridges called Appointed Forwarders, 101 with the intent that native traffic in each VLAN be handled by at 102 most one RBridge. An RBridge can be Appointed Forwarder for many 103 VLANs. 105 The purpose of this document is to improve the documentation of the 106 Appointed Forwarder mechanism. It includes reference implementation 107 details. Alternative implementations that interoperate on the wire 108 are permitted. 110 The Appointed Forwarder mechanism is irrelevant to any link on which 111 end station service is not offered. This includes links configured as 112 point-to-point and any link with all RBridge ports on that link 113 configured as trunk ports. (In TRILL, configuration of a port as a 114 "trunk port" just means that no end station service will be provided. 115 It does not imply that all VLANs are enabled on that port.) 117 The Appointed Forwarder mechanism has no affect on the formation of 118 adjacencies, the election of the DRB for a link, MTU matching, or 119 pseudonode formation. Those topics are covered in [RFCadj]. 120 Furthermore, Appointed Forwarder status has no effect on the handling 121 of TRILL Data frames. It only affects the handling of native frames. 123 For other aspects of the TRILL base protocol see [RFCtrill] and 124 [RFCadj]. Familiarity with [RFCtrill] and [RFCadj] is assumed in this 125 document. In case of conflict between this document and [RFCtrill], 126 this document prevails. 128 1.1 Terminology and Acronyms 130 This document uses the acronyms defined in [RFCtrill]. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 2. Appointed Forwarders and Their Appointment 139 The Appointed Forwarder on a link for VLAN-x is the RBridge that 140 ingresses native frames from the link and egresses native frames to 141 the link in VLAN-x. By default, the DRB on a link is in charge of 142 native traffic for all VLANs on the link. The DRB may, if it wishes, 143 act as Appointed Forwarder for any VLAN and it may appoint other 144 RBridges that have ports on the link as Appointed Forwarder for one 145 or more VLANs. 147 It is important that there not be two Appointed Forwarders on a link 148 that are ingressing and egressing native frames for the same VLAN at 149 the same time. Should this occur, it could form a loop where frames 150 are not protected by a TRILL Hop Count for part of the loop. While 151 TRILL tries to avoid such a situation, for loop safety there is also 152 an "inhibition" mechanism (see Section 3) that can cause an RBridge 153 that is Appointed Forwarder to not ingress or egress native frames. 155 As discussed in Section 5, an RBridge may have multiple ports on a 156 link. As discussed in [RFCadj], if there are multiple ports with the 157 same MAC address on a link, all but one will be suspended. While the 158 cases of multiple ports on a link for one RBridge and multiple ports 159 with the same MAC address are fully accommodated, multiple ports on a 160 link for one RBridge is expected to be a rare condition and duplicate 161 MAC addresses are not recommended by either TRILL or IEEE 802.1 162 standards. 164 Appointed Forwarder status has no affect on the handling of TRILL 165 Data frames. It only affects the handling of native frames. 167 There are two mechanisms by which an RBridge can be appointed or un- 168 appointed as Appointed Forwarder, as a result of DRB elections 169 [RFCadj] as discussed in Section 2.1, or as a result of action by the 170 DRB as discussed in Section 2.2. 172 2.1 Appointment Effects of DRB Elections 174 When an RBridge believes that it has become the DRB on a link, by 175 default it can act as Appointed Forwarder for any VLANs on that link 176 that it chooses as long as that VLAN is enabled on its port, or at 177 least one of its ports if it has more than one port on the link. 179 When an RBridge believes that it has lost DRB status on a link or it 180 observes a change in the RBridge that is DRB for the link without 181 itself becoming DRB, it loses all Appointed Forwarder status. 183 In the rare corner case where an RBridge has more than one port on a 184 link, one of which was previously the DRB election winner but that 185 port has just lost the DRB election to a different port of the same 186 RBridge (possibly due to management configuration of port 187 priorities), there is no change in which RBridge is DRB. Therefore 188 neither of the above points applies and there is no change in 189 Appointed Forwarder status. 191 2.2 Appointment and Removal by the DRB 193 The DRB may appoint other RBridges on the link through inclusion of 194 one or more Appointed Forwarders sub-TLVs [RFCtisis] in a TRILL Hello 195 it sends on the Designated VLAN out the port that won the DRB 196 election. When the DRB sends any appointments in a TRILL Hello, it 197 must send all appointments for that link in that Hello. Any previous 198 appointment not included is implicitly revoked. 200 The DRB MUST NOT send any appointments on a link until its DRB 201 inhibition timer (see Section 3) for that link has expired. 203 How the DRB decides what other RBridges on the link, if any, to 204 appoint forwarder for which VLANs is beyond the scope of this 205 document. 207 2.2.1 Processing Forwarder Appointments 209 When a non-DRB RBridge that can offer end station service on a link 210 receives a TRILL Hello from the DRB on the Designated VLAN sent from 211 the port that won the DRB election, that RBridge examines the Hello 212 for Appointed Forwarder sub-TLVs. If none are present, there is no 213 change in the receiver's Appointed Forwarder status. If one or more 214 Appointed Forwarder sub-TLVs are present and none of them appoints 215 the receiving RBridge, then it loses all Appointed Forwarder status 216 and is no longer Appointed Forwarder for any VLAN. If one or more 217 Appointed Forwarder sub-TLVs are present that appoint the receiving 218 RBridge they are handled as described below. 220 An appointment in an Appointed Forwarder sub-TLV is for a specific 221 RBridge and a contiguous interval of VLAN IDs; however, it actually 222 appoints that RBridge forwarder only for the VLAN(s) in that range 223 that are enabled on one or more ports that RBridge has on the link. 224 The RBridge becomes Appointed Forwarder for all such VLANs in all 225 such Appointed Forwarder sub-TLVs in the Hello PDU and, if it was 226 Appointed Forwarder for any additional VLANs, it loses Appointed 227 Forwarder status for such additional VLANs. 229 Since the network manager normally controls what VLANs are enabled on 230 RBridge ports, they can appoint an RBridge forwarder for an arbitrary 231 set of VLANs by enabling only those VLANs on the relevant port (or 232 ports) and then having the DRB send an appointment that appears to 233 appoint the target RBridge forwarder for all VLANs. However, to 234 facilitate inter-RBridge communication, the Designated VLAN for a 235 link SHOULD be enabled on RBridge ports on that link and it may not 236 be desired to appoint the RBridge forwarder for the Designated VLAN. 237 Thus, in the general case, it would require two appointments, 238 although it would still only require one appointment if the 239 Designated VLAN were an extreme low or high value, that is, VLAN 1 or 240 VLAN 0xFFE. 242 For example, assume the DRB wants RB2 to be Appointed Forwarder for 243 all even numbered VLANs and the Designated VLAN for the link is VLAN 244 101. The network manager could cause all even numbered VLANs plus 245 VLAN 101 to be enabled on the relevant port of RB2 and then, with the 246 desired effect, cause the DRB to send appointments to RB2 appointing 247 it forwarder for all VLANs from 1 through 100 and from 102 through 248 4,095. 250 2.2.2 Frequency of Appointments 252 It is not necessary for the DRB to include the forwarder appointments 253 in every TRILL Hello that it sends on the designated VLAN. For loop 254 safety, every RBridge is required to indicate, in every TRILL Hello 255 it sends in VLAN-x to a link, whether it is acting as the Appointed 256 Forwarder for VLAN-x for that link (see item 4 in Section 3). And it 257 is RECOMMENDED that the DRB have all VLANs for which end station 258 service will be offered on the link, as well as the Designated VLAN, 259 enabled. Thus the DRB will generally be informed by other RBridges on 260 the link of the VLANs for which they believe they are Appointed 261 Forwarder. If this matches the appointments the DRB wishes to make, 262 it is not required to re-send its forwarder appointments; however, 263 for robustness, especially in cases such as VLAN misconfigurations in 264 a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder 265 appointments once per Holding Time. 267 2.2.3 Appointed Forwarders Limit 269 The mechanism of DRB forwarder appointment and the limited length of 270 TRILL Hellos imposes a limit on the number of RBridges on a link that 271 can be Appointed Forwarders. To obtain a conservative estimate, 272 assume that no more than 1000 bytes are available in a TRILL Hello 273 for such appointments. Assume it is desired to appoint various 274 RBridges on a link forwarders for arbitrary non-intersecting sets of 275 VLANs. Using the technique discussed above would generally require 276 two appointments, or 12 bytes, per RBridge. With allowance for sub- 277 TLV and TLV overhead, appointments for 83 RBridges would fit in under 278 1000 bytes. Including the DRB, this implies a link with 84 or more 279 RBridges attached. Links with more than a hand full of RBridges 280 attached are expected to be very rare. 282 (If the Designated VLAN were an extreme low or high value, such as 283 VLAN 1, which is the default and may be a common value in practice, 284 only 6 bytes per RBridge would be required. This would permit twice 285 as many different Appointed Forwarder RBridges than indicated by the 286 general analysis above or, alternatively, take only half as much 287 space to appoint the same number of Appointed Forwarders.) 289 Unnecessary changes in the DRB and unnecessary changes in Appointed 290 Forwarders SHOULD NOT be made as they result in transient lack of end 291 station service. Large numbers of Appointed Forwarders on a link (in 292 excess of 65) are NOT RECOMMENDED due to the complexity of their 293 establishment and maintenance. 295 3. The Inhibition Mechanism 297 An RBridge has, for every link on which it can offer end station 298 service (that is every link for which it can act as an Appointed 299 Forwarder), the following timers denominated in seconds: 301 a DRB inhibition timer, 303 a root change inhibition timer, and 305 up to 4,094 VLAN inhibition timers, one for each legal VLAN ID. 307 The DRB and root change inhibition timers MUST be implemented. 309 The loss of native traffic due to inhibition will be minimized by 310 logically implementing a VLAN inhibition timer per each VLAN for 311 which end station service will ever be offered on the link by the 312 RBridge and this SHOULD be done. However, if implementation 313 limitations make a full set of such timers impractical, the VLAN 314 inhibition timers for more than one VLAN can, with care, be merged 315 into one timer. In particular, an RBridge MUST NOT merge the VLAN 316 inhibition timers for together for two VLANs if it is Appointer 317 Forwarder for one and not for the other as this can lead to 318 unnecessary and indefinitely prolonged inhibition. In the limit, 319 there will be safe operations, albeit with more native frame loss 320 than would otherwise be required, even if only two VLAN inhibition 321 timers are provided, one for VLANs for which the RBridge is Appointed 322 Forwarder and one for all other VLANs. Where a VLAN inhibition timer 323 represents more than one VLAN, an update or test that would have be 324 done to the timer for any of the VLANs is performed on the merged 325 timer. 327 These timers are set as follows: 329 1. On booting or management reset, each port will have its own set 330 of timers, as even if two or more are on the same link the 331 RBridge will not have had a chance to learn that yet. All 332 inhibition timers are set to expired except the DRB inhibition 333 timer that, because each port will initially believe it is DRB, 334 is set in accordance with item 2 below. 336 2. When an RBridge believes that it has become DRB on a link, it 337 sets the DRB inhibition timer to the Holding Time of its port 338 on that link (or the largest Holding Time of any of its ports 339 on that link if it knows it has more than one). 341 3. When an RBridge believes that it has lost DRB status on a link, 342 it sets the DRB inhibition timer to expired. 344 Note: In the rare corner case where one port of an RBridge was 345 the DRB election winner but later loses the DRB election to a 346 different port of the same RBridge on that link (perhaps due to 347 management configuration of port priority), neither 2 nor 3 348 above applies and the DRB timer is not changed. 350 4. When an RBridge RB1 receives a TRILL Hello on VLAN-x from some 351 other RBridge RB2 and RB2 asserts in the Hello that it is 352 Appointed Forwarder, then RB1 sets the VLAN-x inhibition timer 353 for that link to the maximum of its existing value and the 354 Holding Time in the received Hello. An RBridge MUST maintain 355 VLAN inhibition timers for a link to which it connects if it 356 can offer end station service on that link even if it is not 357 currently Appointed Forwarder for any VLAN on that link. 359 5. When an RBridge RB1 enables VLAN-x on a port connecting to a 360 link and VLAN-x was previously disabled on all of RB1's ports 361 on that link, it sets the VLAN inhibition timer for VLAN-x for 362 that link to its Holding Time for that port. 364 6. When an RBridge detects a spanning tree root bridge change on a 365 port, it sets the root change inhibition timer for the link to 366 an amount of time that defaults to 30 seconds and is 367 configurable to any value from 30 down to zero seconds. This 368 condition will not occur unless the RBridge is receiving BPDUs 369 on the port from an attached bridged LAN. It is safe to 370 configure this inhibition time to the settling time of an 371 attached bridged LAN. For example, if it is known that Rapid 372 Spanning Tree Protocol (RSTP [802.1Q-2005]) is running 373 throughout the attached bridged LAN, it should be safe to 374 configure this inhibition time to 4 seconds. Note that, while 375 an RBridge could determine what version of spanning tree is 376 running on the physical link between it and any directly 377 connected bridge by examination of the BPDUs it receives, it 378 could not tell if inter-bridge links beyond those directly 379 connected bridges were running classic Spanning Tree Protocol 380 (STP), which might require the root change inhibition timer to 381 be set to 30 seconds for safety. 383 7. When an RBridge decides that one of its ports (or a set of its 384 ports) P1 is on the same link as another of its ports (or set 385 of its ports) P2, then the inhibition timers are merged to a 386 single set of inhibition timers by using the maximum value of 387 the corresponding timers. 389 8. When an RBridge decides that a set of its ports that it had 390 been treating as being on the same link are no longer on the 391 same link, those ports will necessarily be on two or more links 392 (one link per port in the limit). This is handled by cloning a 393 copy of the timers for each of the two or more links the 394 RBridge has decided these ports connect to. 396 4. Inhibited Appointed Forwarder Behavior 398 An Appointed Forwarder for a link is inhibited for VLAN-x unless (1) 399 its DRB inhibition timer for that link, (2) its root inhibition time 400 for that link, and (3) its VLAN inhibition timer for that link for 401 VLAN-x, are all three expired. 403 If a VLAN-x Appointed Forwarder for a link is inhibited and receives 404 a TRILL Data frame whose encapsulated frame is in VLAN-x and would 405 normally be egressed to that link, it decapsulates the native frame 406 as usual. However, it does not output it to or queue it for that link 407 although, if appropriate, it may output it to or queue it for other 408 links. 410 If a VLAN-x Appointed Forwarder for a link is inhibited and receives 411 a native frame in VLAN-x that would normally be ingressed from that 412 link, the native frame is ignored. 414 An RBridge with an un-expired VLAN inhibition timer for VLAN-x is 415 still required to indicate in TRILL Hellos it sends on VLAN-x whether 416 it is Appointed Forwarder for that VLAN. 418 Inhibition has no effect on the receipt or forwarding of TRILL Data 419 frames. 421 5. Multiple Ports on the Same Link 423 An RBridge may have multiple ports on the same link. Some of these 424 ports may be suspended due to MAC address duplication as described in 425 [RFCadj]. Suspended ports never ingress or egress native frames. 427 If an RBridge has one or more non-suspended ports on a link and those 428 ports offer end station service, that is, those ports are not 429 configured as point-to-point or trunk ports, then that RBridge is 430 eligible to be an Appointed Forwarder. It can become Appointed 431 Forwarder either by default because it is DRB, or by appointment by 432 the DRB as described in Sections 2.1 and 2.2. 434 If an RBridge which is Appointed Forwarder for VLAN-x on a link has 435 multiple non-suspended ports on that link, it may load share the task 436 of ingressing and egressing VLAN-x native frames across those ports 437 however it chooses, as long as there is no case in which a frame it 438 egresses onto the link from one port can be ingressed on another 439 port, creating a loop. If the RBridge is Appointed Forwarder for 440 multiple VLANs, a straightforward thing to do would be to partition 441 those VLANs among the ports it has on the link. 443 6. Security Considerations 445 This memo provides improved documentation of the TRILL Appointed 446 Forwarder mechanism. It does not change the security considerations 447 of the TRILL base protocol. See Section 6 of [RFCtrill]. 449 7. IANA Considerations 451 This document requires no IANA actions. RFC Editor: Please delete 452 this section before publication. 454 8. References 456 Normative and Informational references for this document are listed 457 below. 459 8.1 Normative References 461 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 462 Intermediate System Intra-Domain Routing Exchange Protocol for 463 use in Conjunction with the Protocol for Providing the 464 Connectionless-mode Network Service (ISO 8473)", 2002. 466 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 467 dual environments", RFC 1195, December 1990. 469 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [RFCtisis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A. 473 Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill-05, in 474 RFC Editor's queue. 476 [RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 477 Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- 478 trill-rbridge-protocol-16.txt, in RFC Editor's queue. 480 [RFCadj] - Eastlake, D., R. Perlman, A. Ghanwani, D. Dutt, V. Manral, 481 "RBridges: Adjacency", draft-ietf-trill-adj, work in progress. 483 8.2 Informative References 485 None. 487 Authors' Addresses 489 Radia Perlman 490 Intel Labs 491 2200 Mission College Blvd. 492 Santa Clara, CA 95054 USA 494 Phone: +1-408-765-8080 495 Email: Radia@alum.mit.edu 497 Donald Eastlake 3rd 498 Huawei Technologies 499 155 Beaver Street 500 Milford, MA 01757 USA 502 Phone: +1-508-333-2270 503 Email: d3e3e3@gmail.com 505 Ayan Banerjee 506 Cisco Systems 507 170 West Tasman Drive 508 San Jose, CA 95134 USA 510 Email: ayabaner@cisco.com 512 Fangwei Hu 513 ZTE Corporation 514 889 Bibo Road 515 Shanghai 201203 516 China 518 Phone: +86-21-68896273 519 Email: hu.fangwei@zte.com.cn 521 Copyright and IPR Provisions 523 Copyright (c) 2011 IETF Trust and the persons identified as the 524 document authors. All rights reserved. 526 This document is subject to BCP 78 and the IETF Trust's Legal 527 Provisions Relating to IETF Documents 528 (http://trustee.ietf.org/license-info) in effect on the date of 529 publication of this document. Please review these documents 530 carefully, as they describe your rights and restrictions with respect 531 to this document. Code Components extracted from this document must 532 include Simplified BSD License text as described in Section 4.e of 533 the Trust Legal Provisions and are provided without warranty as 534 described in the BSD License. The definitive version of an IETF 535 Document is that published by, or under the auspices of, the IETF. 536 Versions of IETF Documents that are published by third parties, 537 including those that are translated into other languages, should not 538 be considered to be definitive versions of IETF Documents. The 539 definitive version of these Legal Provisions is that published by, or 540 under the auspices of, the IETF. Versions of these Legal Provisions 541 that are published by third parties, including those that are 542 translated into other languages, should not be considered to be 543 definitive versions of these Legal Provisions. For the avoidance of 544 doubt, each Contributor to the IETF Standards Process licenses each 545 Contribution that he or she makes as part of the IETF Standards 546 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 547 language to the contrary, or terms, conditions or rights that differ 548 from or are inconsistent with the rights and licenses granted under 549 RFC 5378, shall have any effect and shall be null and void, whether 550 published or posted by such Contributor, or included with or in such 551 Contribution.