idnits 2.17.1 draft-ietf-trill-parent-selection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 577 lines 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 (October 6, 2017) is 2387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 508 looks like a reference -- Missing reference section? 'RFC6325' on line 513 looks like a reference -- Missing reference section? 'RFC7780' on line 518 looks like a reference -- Missing reference section? 'RFC7783' on line 524 looks like a reference -- Missing reference section? 'RFC4971' on line 529 looks like a reference -- Missing reference section? 'RFC7176' on line 503 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL WG R. Parameswaran, 2 INTERNET-DRAFT Brocade Communications, Inc. 3 Intended Status:Informational October 6, 2017 4 Expires: April 09, 2018 6 TRILL: Parent node Shifts in Tree Construction, Mitigation. 7 8 Abstract 10 This draft documents a known problem in the TRILL tree construction 11 mechanism and offers an approach requiring no change to the TRILL 12 protocol in order to solve the problem. 14 Status of This Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Distribution of this document is unlimited. Comments should be sent 20 to the authors or the TRILL working group mailing list: 21 trill@ietf.org. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 35 Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Terminology and Acronyms. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC2119]. 44 Table of Contents 46 1. Introduction...............................................1 47 2. Tree construction in TRILL.................................2 48 3. Issues with the TRILL tree construction algorithm..........2 49 4. Solution using the Affinity sub-TLV........................4 50 5. Network wide selection of computation algorithm............7 51 6. Relationship to draft-ietf-trill-resilient-trees...........7 52 7. Security Considerations....................................9 53 8. IANA Considerations........................................9 54 9. Informative References.....................................9 56 1. Introduction. 58 TRILL is a data center technology that uses link-state routing 59 mechanisms in a layer 2 setting, and serves as a replacement 60 for spanning-tree. TRILL uses trees rooted at pre-determined nodes 61 as a way to distribute multi-destination traffic. Multi-destination 62 traffic includes traffic such as layer-2 broadcast frames, unknown 63 unicast flood frames, and layer 2 traffic with multicast MAC 64 addresses (collectively referred to as BUM traffic). Multi-destination 65 traffic is typically hashed onto one of the available trees and sent 66 over the tree, potentially reaching all nodes in the network (hosts 67 behind which may own/need the packet in question). 69 2. Tree construction in TRILL. 71 Tree construction in TRILL is defined by [RFC6325], with additional 72 corrections defined in [RFC7780]. 74 The tree construction mechanism used in TRILL codifies 75 certain tree construction steps which make the resultant trees 76 very brittle. Specifically, the parent selection mechanism in TRILL 77 causes problems in case of node failures. TRILL uses the following rule 78 - when constructing an SPF tree, if there are multiple possible 79 parents for a given node (i.e. if multiple upstream nodes can 80 potentially pull in a given node during SPF, all at the same 81 cumulative cost, then the parent selection is imposed in the 82 following manner): 84 [RFC6325]: 85 "When building the tree number j, remember all possible 86 equal cost parents for node N. After calculating the entire 'tree' 87 (actually, directed graph), for each node N, if N has 'p' parents, 88 then order the parents in ascending order according to the 89 7-octet IS-IS ID considered as an unsigned integer, and number them 90 starting at zero. For tree j, choose N's parent as choice j mod p." 92 There is an additional correction posted to this in [RFC7780]: 94 [RFC7780], Section 3.4: 96 "Section 4.5.1 of [RFC6325] specifies that, when building 97 distribution tree number j, node (RBridge) N that has multiple 98 possible parents in the tree is attached to possible parent 99 number j mod p. Trees are numbered starting with 1, but possible 100 parents are numbered starting with 0. As a result, if there are 101 two trees and two possible parents, then in tree 1 parent 1 will 102 be selected, and in tree 2 parent 0 will be selected. 104 This is changed so that the selected parent MUST be (j-1) mod p. As 105 a result, in the case above, tree 1 will select parent 0, and tree 2 106 will select parent 1. This change is not backward compatible with 107 [RFC6325]. If all RBridges in a campus do not determine distribution 108 trees in the same way, then for most topologies, the RPFC will drop 109 many multi-destination packets before they have been properly 110 delivered." 112 3. Issues with the TRILL tree construction algorithm. 114 With this tree construction mechanism in mind,let's look at 115 the Spine-Leaf topology presented below and consider the 116 calculation of Tree number 2 in TRILL. Assume all the links in the tree 117 are at the same cost. 119 A-- --B 120 / \ \/ /\ 121 / \/\ _/_ \ 122 /__ _/\ / \\ 123 // \/ \\ 124 1 2 3 125 \ | / 126 \ | / 127 \ | / 128 \ | / 129 \ | / 130 \ | / 131 \ |/ 132 C 134 Assume that in the above topology, when ordered by 7-octet ISIS-id, 135 1 < 2 < 3 holds and that the root for Tree number 2 is A. Given the 136 ordered set {1, 2, 3} , these nodes have the following indices (with a 137 starting index of 0): 139 Node Index 140 1 0 141 2 1 142 3 2 144 Given the SPF constraint and that the tree root is A, the parent for 145 nodes 1,2, and 3 will be A. However, when the SPF algorithm tries to 146 pull B or C into the tree, we have a choice of parents, namely 1, 2, 147 or 3. 149 Given that this is tree 2, the parent will be the one with index 150 (2-1) mod 3 (which is equal to 1). Hence the parent for node B will be 151 node 2. 152 A 153 /|\ 154 / | \ 155 / | \ 156 1 2 3 157 /\ 158 / \ 159 B C 161 However, due to TRILL's parent selection algorithm, the sub-tree 162 rooted at Node 2 will be impacted even if Node 1 or Node 3 163 go down. 165 Take the case where Node 1 goes down. Tree 2 must now be 166 re-computed (this is normal) - but now, when the SPF computation is 167 underway, when the SPF process tries to pull in B, the list of 168 potential parents for B now are {2 and 3}. So, after ordering these 169 by ISIS-Id as {2, 3} (where 2 is considered to be at index of 0 and 3 170 is considered to be at index 1), for tree 1, we apply TRILL's formula 171 of: 173 Parent's index = (TreeNumber-1) mod Number_of_parents. 174 = (2-1) mod 2 175 = 1 mod 2 176 = 1 (which is the index of Node 3) 178 The re-calculated tree now looks as shown below. The shift in 179 parent nodes (for B) may cause disruption to live traffic in the 180 network, and is unnecessary in absolute terms because the existing 181 parent for node B, node 2, was not perturbed in any way. 183 A 184 / \ 185 / \ 186 / \ 187 2 3 188 /\ 189 / \ 190 B C 192 Aside from the disruption posed by the change in the tree links, 193 depending upon how the concerned rbridges stripe vlans/FGLs across 194 trees and how they may prune these, additional disruption is possible 195 if the forwarding state on the new parent rbridge is not primed to 196 match the new tree structure. This churn could simply be avoided 197 with a better approach. 199 The parent shift issue noted above can be solved by using 200 the Affinity sub-TLV. 202 While the technique identified in this draft has an immediate benefit 203 when applied to spine/leaf networks popular in data-center designs, 204 nothing in the approach outlined below assumes a spine-leaf network. 205 The technique presented below will work on any connected graph. 206 Furthermore, no directional symmetry in link-cost is assumed. 208 4. Solution using the Affinity sub-TLV. 210 At a high level, this problem can be solved by having the affected 211 parent send out an Affinity sub-TLV identifying the children for 212 which it wants to preserve the parent-child relationship, subject to 213 network events which may change the structure of the tree. The 214 affected parent node would send out an Affinity sub-TLV with 215 multiple Affinity records, one per child node, listing the 216 concerned tree number. 218 It would be sufficient to have a local configuration option (e.g. 219 a CLI) at one of the nodes which is deemed to be the parent of 220 choice (referred to as designated parent below). The following steps 221 provide a way to implement this proposal: 223 a. The operator locally configures the designated parent to indicate 224 its stickiness in tree construction for a specific tree number 225 and tree root via the Affinity sub-TLV. This can be done before 226 tree construction if the operator consults the 7 octet ISIS-ID 227 relative ordering of the concerned nodes and decides up-front which 228 of the potential parent nodes should become the parent node for a 229 given set of children on that tree number under the TRILL tree 230 construction mechanism. The operator MUST configure the 231 designated parent stickiness on only one node amongst a set of 232 sibling (potential parent) nodes relative to the tree root for 233 that tree number. It is suggested that the parent stickiness be 234 configured on the node that would have been selected as the 235 parent under default Trill parent selection rules. Parent 236 stickiness MUST NOT be configured on the root of the tree, or 237 if configured previously on a non-root node with the root for 238 that tree shifting to that node subsequently, such configuration 239 MUST be ignored on the root node. 241 b. On any subsequent SPF calculation after the operator configures 242 the designated parent as indicated above, when the designated 243 parent node finds that it could be a potential parent for one or 244 more child nodes during tree construction, it declares itself to be 245 the parent for the concerned child nodes, over-riding the default 246 TRILL parent selection rules. The configured node advertises its 247 parent preference via the Affinity sub-TLV when it completes a 248 tree calculation, and finds itself the parent of one or more child 249 nodes per the SPF tree calculation. The Affinity sub-TLV MUST 250 reflect the appropriate tree number and the child nodes for which 251 the concerned node is a parent node. The Affinity sub-TLV SHOULD 252 be published when the tree computation is deemed to have 253 converged (more on this under d. below). 255 c. Likewise, when any change event happens in the network, one which 256 forces a tree re-calculation for the concerned tree, the designated 257 parent node should run through the normal TRILL tree calculation 258 agnostic of the fact that it has published an Affinity sub-TLV as 259 well as agnostic of the default TRILL tree selection rules i.e the 260 node asserts its right to be a parent without directly referencing 261 either the default Trill parent selection rules or its own 262 published Affinity sub-TLV in establishing parent relationships. 264 d. During the SPF tree calculation, the designated parent node should 265 react in the following manner: 267 i. If the node is a potential parent for some of the 268 children identified in an existing Affinity sub-TLV, if any, 269 after convergence of the tree computation, the node MUST send 270 out an (updated) Affinity sub-TLV identifying the correct 271 sub-set of children for which the node aspires to 272 establish/continue the parent relationship. This case would 273 also apply if there are new child nodes for which the node is 274 now a parent (however, see the conflicted Affinity sub-TLV 275 rules in vii and j. below). 277 For its own tree computation, the designated parent node 278 MUST use itself as parent in order to pull the set of children 279 identified during the SPF run into the tree, barring a 280 conflicting affinity sub-TLV seen from another node (see 281 vii. below for handling this case). 283 ii. If the tree structure changes such that the designated node is 284 no longer a potential parent for any of the child nodes in the 285 advertised Affinity sub-TLV, then it SHOULD retract the 286 Affinity sub-TLV, upon convergence of the tree computation. 287 In this case, the default TRILL tie-break rule would need to be 288 used during SPF construction for the nodes that were children 289 of this designated node previously. One specific case may be 290 worth high-lighting - if a parent-child relationship inverts 291 i.e. if the designated parent becomes a child of its former 292 child node due to a change in the tree structure, it MUST 293 exclude that child from its Affinity sub-TLV. In such case, if 294 the designated parent node cannot maintain a parent 295 relationship with any of its prior child nodes, then it MUST 296 retract any previously published affinity sub-TLV. 298 iii. Nodes SHOULD use a convergence timer to track completion 299 of the tree computation. If there are any additional tree 300 computations while the convergence timer is running, the 301 timer SHOULD be re-started/extended in order to absorb the 302 interim network events. It is possible that the intended action 303 at the expiration of the timer may change meanwhile. The 304 timer needs to be large enough to absorb multiple network 305 events that may happen due to a change in the physical state 306 of the network, and yet short enough to avoid delaying the 307 update of the Affinity sub-TLV. 309 iv. At the expiration of the convergence timer, the existing state 310 of the tree MUST be compared with the existing Affinity 311 sub-TLV and the intended change in the status of the Affinity 312 sub-TLV is carried out e.g. a fresh publication, or an update 313 to the list of children, or a retraction. 315 v. Alternately, the above steps (re-examination of the Affinity 316 sub-TLV and update) MAY be tied to/triggered from the download 317 of the tree routes to the L2 RIB, since that typically happens 318 upon a successful computation of the complete tree. An 319 additional stabilization timer could be used to counteract 320 back-to-back L2 RIB downloads due to repeated computations of 321 the tree due to a burst of network events. 323 vi. Note that this approach may cause an additional tree computation 324 at remote nodes once the updated Affinity sub-TLV (or lack of 325 it) is received/perceived, beyond the network events which led 326 up to the change in the tree. In the case where an operator 327 introduced a designated parent configuration on an existing 328 tree, then remote nodes would need to receive the Affinity 329 sub-TLV indicating the designated parent's Affinity for its 330 children before the remote nodes shift away from the default 331 TRILL parent selection rules. However, in most cases, in steady 332 state, this mechanism should cause very little tree churn unless 333 a designated parent configuration was introduced, removed, or 334 a link between the designated parent and its children changed 335 state. In cases where the network change event originated on 336 the designated parent node, it may be possible to optimize on 337 the churn by packing both the data bearing the network change 338 event and the Affinity sub-TLV into the same link-state update 339 packet. 341 vii. In situations where the designated parent node would 342 normally originate an affinity sub-TLV to indicate affinity 343 to a specific set of child nodes, it MUST NOT originate an 344 Affinity sub-TLV if it sees an Affinity sub-TLV from some 345 other node for the same tree number and for all of the same 346 child-nodes, such that the other node's Affinity sub-TLV would 347 win using the conflict tie-break rules in section 5.3 of 348 [RFC7783]. Any existing Affinity sub-TLV already published 349 by this node in such a situation MUST be retracted. If only 350 some of the child nodes overlap between the two conflicting 351 Affinity sub-TLVs, then this designated parent node MAY 352 continue to publish its affinity sub-TLV listing its child 353 nodes that are not in conflict with the other Affinity sub-TLV. 354 Other guide-lines listed in [RFC7783] MUST be adhered to as 355 well - the originator of the Affinity sub-TLV must name only 356 directly adjacent nodes as children, and must not name the 357 tree root as a child. 359 e. Situations where the node advertising the Affinity sub-TLV dies 360 or restarts SHOULD be handled using the normal handling for such 361 scenarios relating to the parent Router Capability TLV, and as 362 specified in [RFC4971]. 364 f. Situations where a parent-child link directly connected to the 365 designated parent node constantly flaps, MUST be handled 366 by having the designated parent node retract the Affinity 367 sub-TLV, if it affects the parent-child relationships in 368 consideration. The long-term state of the Affinity sub-TLV can 369 be monitored by the designated parent node to see if it is being 370 published and retracted repeatedly in multiple iterations or 371 if a specific set of children are being constantly added and 372 removed. The designated parent may resume publication of the 373 Affinity sub-TLV once it perceives the network to be stable 374 again in the future. 376 g. If the designated parent node is forced to retract its Affinity 377 sub-TLV due to a change in the tree structure, it can then repeat 378 these steps in a subsequent tree construction, if the same node 379 becomes a parent again, so long as it perceives its parent-child 380 links to be stable (free of link/node flaps). 382 h. In terms of nodes that do not support this draft, they are 383 expected to seamlessly inter-operate with this draft, so long as 384 they understand and honor the Affinity sub-TLV. The draft assumes 385 that most TRILL implementations now support the Affinity sub-TLV. 386 In any case, the guide-lines specified in section 4.1 of [RFC7783] 387 MUST be used i.e. if all nodes in the network do not support the 388 Affinity sub-TLV then the network must default to the Trill parent 389 selection rules. 391 i. Remote nodes MUST default to the Trill parent selection rules 392 if they do not see an Affinity sub-TLV sent by any node in the 393 network. 395 j. At remote nodes, conflicting Affinity sub-TLVs from different 396 originators for the same tree number and child node MUST be 397 handled as specified in section 5.3 of [RFC7783], namely by 398 selecting the Affinity sub-TLV originated by the node with the 399 highest priority to be a tree root, with System-ID as tie-breaker. 401 5. Network wide selection of computation algorithm. 403 The proposed solution above does not need any operational change to the 404 TRILL protocol, beyond the usage of the Affinity sub-TLV (which is 405 already in the proposed standard) for the use case identified in 406 this draft. 408 6. Relationship to draft-ietf-trill-resilient-trees. 410 Given that both draft-ietf-trill-resilient-trees, and 411 draft-rp-trill-parent-selection-03 drafts use the Affinity sub-TLV, 412 it is worthwhile to examine if there is any functional overlap 413 between the two drafts. At a high level, the two drafts have different 414 goals and appear to solve unrelated problems. 416 draft-ietf-trill-resilient-trees relates to link protection, and 417 defines the notion of a primary distribution tree and a backup 418 distribution tree (DT), where these trees are intentionally kept link 419 disjoint to the extent possible, and the backup tree is pre-programmed 420 in the hardware, and activated either up front or upon failure of the 421 primary distribution tree. 423 On the other hand, draft-rp-trill-parent-selection-03 protects 424 parent-child relationships of interest on the primary DT, and has 425 no direct notion of a backup DT. 427 draft-ietf-trill-resilient-trees considers the following algorithmic 428 approaches to the building the backup distribution tree (section 429 numbers listed below are from draft-ietf-trill-resilient-trees): 431 1. Operator hand-configuration for links on the backup DT/manual 432 generation of Affinity sub-TLV - this is very tedious and unlikely 433 to scale or be implemented in practice, and hence is disregarded 434 in the analysis here. 436 2. Section 3.2.1.1a: Use of MRT algorithms (which will produce conjugate 437 trees - link disjoint trees with roots for primary and backup trees 438 that are coincident on the same rBridge). 440 3. Section 3.2.1.1b: Once the primary DT is constructed, the links 441 used in the primary DT are additively cost re-weighted, and a 442 second SPF is run to derive the links comprising the backup DT. 443 Affinity sub-TLV is used to mark links on the back-up DT which are 444 not also on the primary DT. This approach can handle conjugate 445 trees as well as non-conjugate trees (link disjoint trees that are 446 rooted at different rBridges). 448 4. Section 3.2.2: A variation on the section 3.2.1.1b approach, but 449 without Affinity sub-TLV advertisement. Once the primary DT is 450 constructed, costs for links on the primary DT are multiplied by a 451 fixed multiplier to prevent them from being selected in a 452 subsequent SPF run, unless there is no other choice, and the 453 subsequent SPF yields links on the backup DT. 455 All of the approaches above yield maximally link disjoint trees, 456 when applied as prescribed. 458 Approach 4 above does not seem to use Affinity sub-TLVs and instead 459 seems to depend upon a network wide agreement on the alternative 460 tree computation algorithm being used. 462 Approaches 2 and 3 use Affinity sub-TLV on the backup DT, for links 463 that are not already on the primary DT. The primary DT does not 464 appear to use Affinity sub-TLVs. Additionally, from an end-to-end 465 perspective the backup DT comes into picture when the primary DT 466 fails (this is effectively true even in the 1+1 protection mechanism 467 and in the local protection case), and then again, only until the 468 primary DT is recalculated. Once the primary DT is recalculated, the 469 backup DT is recalculated as well, and can change corresponding to 470 the new primary DT. 472 draft-ietf-trill-resilient-trees cannot directly prevent/mitigate a 473 parent node shift on the primary DT at a given parent node, and while 474 usage of the Affinity sub-TLV on the backup DT might confer a parent 475 affinity on some nodes on the backup DT, these are not necessarily 476 the nodes on which the network operator may want/prefer an explicit 477 parent affinity. Further, the backup DT is only used on a transient 478 basis, from a forwarding perspective, until the primary DT is 479 recomputed. 481 However, a parent shift can be triggered by link or node failure. In 482 a situation where both drafts are active in the implementation, failure 483 of a specific link may cause the backup DT to kick in, but when the 484 primary DT is re-calculated, draft-rp-trill-parent-selection-03 can be 485 used to preserve parent-child relationships on the primary DT, to the 486 extent possible, during the re-calculation. So, there does not appear 487 to be a direct functional overlap in the simultaneous usage of these 488 drafts, and it ought to be possible to use both drafts simultaneously, 489 so long as the primary and back-up DTs can be uniquely 490 identified/differentiated. 492 7. Security Considerations. 494 The proposal primarily influences tree construction and tries to 495 preserve parent-child relationships in the tree from prior computations 496 of the same tree, without changing any of operational aspects of the 497 protocol. Hence, no new security considerations for TRILL are raised 498 by this proposal. 500 8. IANA Considerations. 502 No new registry entries are requested to be assigned by IANA. The 503 Affinity Sub-TLV has been defined in [RFC7176], and this proposal 504 does not change its semantics in any way. 506 9. Informative References. 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, 510 DOI 10.17487/RFC2119, March 1997, 511 . 513 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 514 Ghanwani, "Routing Bridges (RBridges): Base Protocol 515 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 516 . 518 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 519 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 520 Lots of Links (TRILL): Clarifications, Corrections, and 521 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 522 . 524 [RFC7783] Senevirathne, T., Pathangi, J., Hudson, J., "Coordinated 525 Multicast Trees (CMT) for Transparent Interconnection of 526 Lots of Links (TRILL)", RFC 7783, February 2016, 527 529 [RFC4971] Vasseur, JP., Shen, N., Aggarwal, R., "Intermediate 530 System to Intermediate System (IS-IS) Extensions for 531 Advertising Router Information", RFC 4971, July 2007, 532 534 Author's Address: 536 R. Parameswaran, 537 Brocade Communications, Inc. 538 120 Holger Way, 539 San Jose, CA 95134. 541 Email: parameswaran.r7@gmail.com 543 Copyright and IPR Provisions 545 Copyright (c) 2017 IETF Trust and the persons identified as the 546 document authors. All rights reserved. 548 This document is subject to BCP 78 and the IETF Trust's Legal 549 Provisions Relating to IETF Documents 550 (http://trustee.ietf.org/license-info) in effect on the date of 551 publication of this document. Please review these documents 552 carefully, as they describe your rights and restrictions with respect 553 to this document. Code Components extracted from this document must 554 include Simplified BSD License text as described in Section 4.e of 555 the Trust Legal Provisions and are provided without warranty as 556 described in the Simplified BSD License. The definitive version of 557 an IETF Document is that published by, or under the auspices of, the 558 IETF. Versions of IETF Documents that are published by third parties, 559 including those that are translated into other languages, should not 560 be considered to be definitive versions of IETF Documents. The 561 definitive version of these Legal Provisions is that published by, or 562 under the auspices of, the IETF. Versions of these Legal Provisions 563 that are published by third parties, including those that are 564 translated into other languages, should not be considered to be 565 definitive versions of these Legal Provisions. For the avoidance of 566 doubt, each Contributor to the IETF Standards Process licenses each 567 Contribution that he or she makes as part of the IETF Standards 568 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 569 language to the contrary, or terms, conditions or rights that differ 570 from or are inconsistent with the rights and licenses granted under 571 RFC 5378, shall have any effect and shall be null and void, whether 572 published or posted by such Contributor, or included with or in such 573 Contribution.