idnits 2.17.1 draft-ietf-idr-ls-trill-03.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 (October 3, 2017) is 2395 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' ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard W. Hao 3 Huawei 4 S. Hares 5 Hickory Hill Consulting 6 S. Gupta 7 IP Infusion 8 M. Durrani 9 Cisco 10 Y. Li 11 Huawei 12 Expires: April 2, 2018 October 3, 2017 14 Distribution of TRILL Link-State using BGP 15 17 Abstract 19 This draft describes a TRILL link state and MAC address reachability 20 information distribution mechanism using a BGP LS extension. 21 External components such as an SDN Controller can use the information 22 for topology visibility, troubleshooting, network automation, and the 23 like. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the authors or the IDR working group mailing list: idr@ietf.org. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Table of Contents 50 1. Introduction............................................3 51 2. Conventions used in this document.......................5 53 3. Carrying TRILL Link-State Information in BGP............6 54 3.1 Node Descriptors.......................................7 55 3.1.1 IGP Router-ID........................................8 56 3.2 MAC Address Descriptors................................8 57 3.2.1 MAC-Reachability TLV.................................9 58 3.3 The BGP-LS Attribute...................................9 59 3.3.1 Node Attribute TLVs..................................9 60 3.3.1.1 Node Flag Bits TLV................................10 61 3.3.1.2 Opaque Node Attribute TLV.........................10 62 3.3.2. Link Attribute TLVs................................11 64 4. Operational Considerations.............................12 66 5. Security Considerations................................13 67 6. IANA Considerations....................................13 69 Normative References......................................14 70 Informative References....................................14 71 Acknowledgments...........................................15 73 Authors' Addresses........................................16 75 1. Introduction 77 BGP has been extended to distribute IGP link-state and traffic 78 engineering information to some external components [RFC7752], such 79 as the PCE and ALTO servers. The information can be used by these 80 external components to compute a MPLS-TE path across IGP areas, 81 visualize and abstract network topology, and the like. 83 TRILL (Transparent Interconnection of Lots of Links) protocol 84 [RFC6325] provides a solution for least cost transparent routing in 85 multi-hop networks with arbitrary topologies and link technologies, 86 using [IS-IS] [RFC7176] link-state routing and a hop count. TRILL 87 switches are sometimes called RBridges (Routing Bridges). 89 The TRILL protocol has been deployed in many data center networks. 90 Data center automation is a vital step to increase the speed and 91 agility of business. An SDN controller as an external component 92 normally can be used to provide centralized control and automation 93 for the data center network. Making a holistic view of whole network 94 topology available to the SDN controller is an important part for 95 data center network automation and troubleshooting. 97 +-------------+ 98 | SDN | 99 --------| Controller |-------- 100 | +-------------+ | 101 | | 102 + + + + 103 + +-----------+ + 104 | | 105 +--------+ |IP Network | +--------+ 106 | | +----+ +----+ | | 107 +---+ +---+ | | | | | | | | +---+ +---+ 108 |ES1|-|RB1|-| Area 1 |-|BRB1| |BRB2|-| Area 2 |-|RB2|-|ES2| 109 +---+ +---+ | | +----+ +----+ | | +---+ +---+ 110 | | | | | | 111 +--------+ +-----------+ +--------+ 113 |<----TRILL ------>||<-----TRILL ----->| 115 Figure 1: TRILL interconnection 117 In Data Center interconnection scenario illustrated in Figure 1, a 118 single SDN Controller or network management system (NMS) can be used 119 for end-to-end network management. End-to-end topology visibility on 120 the SDN controller or NMS is very useful for whole network automation 121 and troubleshooting. BGP LS can be used by the external SDN 122 controller to collect multiple TRILL domain's link-state. 124 BGP LS also can be used for MAC address reachability information 125 synchronization across multiple TRILL domains. The transported MAC 126 reachability information and the like is for telemetry purposes and 127 for use by SDN controller(s) where the coordination or protocol 128 between the SDN controllers is out of scope. 130 This document describes the detailed BGP LS extension mechanisms for 131 TRILL link state and MAC address reachability information 132 distribution. 134 2. Conventions used in this document 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 BGP - Border Gateway Protocol 142 BGP-LS - BGP Link-State 144 Data label - VLAN or FGL (Fine Grained Label [RFC7172]) 146 IS - Intermediate System (for this document, all relevant 147 intermediate systems are RBridges) 149 NLRI - Network Layer Reachability Information 151 SDN - Software Defined Networking 153 RBridge - A device implementing the TRILL protocol 155 TRILL - Transparent Interconnection of Lots of Links 157 3. Carrying TRILL Link-State Information in BGP 159 In [RFC7752], four NLRI types are defined as follows: Node NLRI, Link 160 NLRI, IPv4 Topology Prefix NLRI and IPv6 Topology Prefix NLRI. For 161 TRILL link-state distribution, the Node NLRI and Link NLRI are 162 extended to carry layer 3 gateway role and link MTU information. 163 TRILL specific attributes are carried using opaque Node Attribute 164 TLVs, such as nickname, distribution tree number and identifiers, 165 interested VLANs/Fine Grained Label, and multicast group address, 166 etc. 168 To differentiate TRILL protocol from layer 3 IGP protocol, a new 169 TRILL Protocol-ID is defined. 171 +-------------+----------------------------------+ 172 | Protocol-ID | NLRI information source protocol | 173 +-------------+----------------------------------+ 174 | 1 | IS-IS Level 1 | 175 | 2 | IS-IS Level 2 | 176 | 3 | OSPFv2 | 177 | 4 | Direct | 178 | 5 | Static configuration | 179 | 6 | OSPFv3 | 180 | TBD | TRILL | 181 +-------------+----------------------------------+ 183 Table 1: Protocol Identifiers 185 ESADI (End Station Address Distribution Information) protocol 186 [RFC7357] is a per data label control plane MAC learning solution. 187 MAC address reachability information is carried in ESADI packets. 188 Compared with data plane MAC learning solution, ESADI protocol has 189 security and fast update advantage that are pointed out in [RFC7357]. 191 For an RBridge that is announcing participation in ESADI, the RBridge 192 can distribute MAC address reachability information to external 193 components using BGP. A new NLRI type of "MAC Reachability NLRI" is 194 requested for the MAC address reachability distribution. 196 +------+---------------------------+ 197 | Type | NLRI Type | 198 +------+---------------------------+ 199 | 1 | Node NLRI | 200 | 2 | Link NLRI | 201 | 3 | IPv4 Topology Prefix NLRI | 202 | 4 | IPv6 Topology Prefix NLRI | 203 | TBD | MAC Reachability NLRI | 204 +------+---------------------------+ 206 Table 2: NLRI Types 208 The MAC Reachability NLRI uses the format as shown in the following 209 Figure. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+ 214 | Protocol-ID | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Identifier | 217 | (64 bits) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 // Local Node Descriptor (variable) // 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 // MAC Address Descriptors (variable) // 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 2: The MAC Reachability NLRI format 226 3.1 Node Descriptors 228 The Node Descriptor Sub-TLV types include Autonomous System and BGP- 229 LS Identifier, IS-IS Area-ID and IGP Router-ID. TRILL uses a fixed 230 zero Area Address as specified in [RFC6325], Section 4.2.3. This is 231 encoded in a 4-byte Area Address TLV (TLV #1) as follows: 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | 0x01, Area Address Type | (1 byte) 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | 0x02, Length of Value | (1 byte) 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | 0x01, Length of Address | (1 byte) 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | 0x00, zero Area Address | (1 byte) 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 3: Area Address TLV 245 3.1.1 IGP Router-ID 247 Similar to layer 3 IS-IS, TRILL protocol uses 7-octet "IS-IS ID" as 248 the identity of an RBridge or a pseudonode, IGP Router ID sub-TLV in 249 Node Descriptor TLVs contains the 7-octet "IS-IS ID". In TRILL 250 network, each RBridge has a unique 48-bit (6-octet) IS-IS System ID. 251 This ID may be derived from any of the RBridge's unique MAC addresses 252 or configured. A pseudonode is assigned a 7-octet ID by the DRB 253 (Designated RBridge) that created it, the DRB is similar to the 254 "Designated Intermediate System" (DIS) corresponding to a LAN. 256 3.2 MAC Address Descriptors 258 The "MAC Address Descriptor" field is a set of Type/Length/Value 259 (TLV) triplets. "MAC Address Descriptor" TLVs uniquely identify an 260 MAC address reachable by a Node. The following attributes TLVs are 261 defined: 263 +--------------+-----------------------+----------+-----------------+ 264 | TLV Code | Description | Length | Value defined | 265 | Point | | | in: | 266 +--------------+-----------------------+----------+-----------------+ 267 | 1 | MAC-Reachability | variable | section 3.2.1 | 268 +--------------+-----------------------+----------+-----------------+ 270 Table 3: MAC Address Descriptor TLVs 272 3.2.1 MAC-Reachability TLV 274 +-+-+-+-+-+-+-+-+ 275 | Type= MAC-RI | (1 byte) 276 +-+-+-+-+-+-+-+-+ 277 | Length | (1 byte) 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+ 279 |V|F| RESV | Data Label | (4 bytes) 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | MAC (1) (6 bytes) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | ................. | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | MAC (N) (6 bytes) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 4: MAC-Reachability TLV format 290 Length is 4 plus a multiple of 6. 292 The bits of 'V' and 'F' are used to identify Data Label type and are 293 defined as follows: 295 +----------+-------------------------+ 296 | Bit | Description | 297 +----------+-------------------------+ 298 | 'V' | VLAN | 299 | 'F' | Fine Grained Label | 300 +----------+-------------------------+ 302 Table 4: Data Label Type Bits Definitions 304 Notes: If BGP LS is used for NVO3 network MAC address distribution 305 between external SDN Controller and NVE, Data Label can be used to 306 represent 24 bits VN ID. 308 3.3 The BGP-LS Attribute 310 3.3.1 Node Attribute TLVs 311 3.3.1.1 Node Flag Bits TLV 313 A new Node Flag bit is added as follows: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |O|T|E|B|G| Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 5: Node Flag Bits TLV format 325 The new bit and remaining reserved bits are defined as follows: 327 +----------+----------------------------+-----------+ 328 | Bit | Description | Reference | 329 +----------+----------------------------+-----------+ 330 | 'G' | Layer 3 Gateway Bit | [RFC7176] | 331 | Reserved | Reserved for future use | | 332 +----------+----------------------------+-----------+ 334 Table 5: Node Flag Bits Definitions 336 3.3.1.2 Opaque Node Attribute TLV 338 The Opaque Node Attribute TLV is used as the envelope to 339 transparently carry TRILL specific information. In [RFC7176], there 340 are the following Sub-TLVs in the Router Capability and MT- 341 Capability TLVs and the Group Address (GADDR) TLV that need to be 342 carried. Future possible TRILL TLVs/Sub-TLVs extension also can be 343 carried using the Opaque Node Attribute TLV. 345 Descriptions IS-IS TLV/Sub-TLV 346 ------------------------------------ 347 TRILL-VER 22/13 348 NICKNAME 22/6 349 TREES 22/7 350 TREE-RT-IDs 22/8 351 TREE-USE-IDs 22/9 352 INT-VLAN 22/10 353 VLAN-GROUP 22/14 354 INT-LABEL 22/15 355 RBCHANNELS 22/16 356 AFFINITY 22/17 357 LABEL-GROUP 22/18 358 GMAC-ADDR 142/1 359 GIP-ADDR 142/2 360 GIPV6-ADDR 142/3 361 GLMAC-ADDR 142/4 362 GLIP-ADDR 142/5 363 GLIPV6-ADDR 142/6 365 Table 6: TRILL TLVs/Sub-TLVs 367 3.3.2. Link Attribute TLVs 369 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 370 attribute with a link NLRI. Besides the TLVs that has been defined in 371 [RFC7752] section 3.3.2 Table 9, the following 'Link Attribute' TLV 372 is provided for TRILL. 374 +-----------+----------------+--------------+------------------+ 375 | TLV Code | Description | IS-IS TLV | Defined in: | 376 | Point | | /Sub-TLV | | 377 +-----------+----------------+--------------+------------------+ 378 | TBD | Link MTU | 22/28 | [RFC7176]/2.4 | 379 +-----------+----------------+--------------+------------------+ 381 Table 7: Link Attribute TLVs 383 4. Operational Considerations 385 This document does not require any MIB or Yang model to configure 386 operational parameters. 388 Any implementation of the protocol in this specification (i.e. that 389 distributes TRILL Link-State information using BGP), MUST do the 390 malformed attribute checks below, and if it detects a malformed 391 attribute, it should use the 'Attribute Discard' action per [I- 392 D.ietf.idr-error-handling] section 2. 394 An implementation MUST perform the following expanded BGP-LS 395 syntactic check for determining if the message is malformed: 397 o Does the sum of all TLVs found in the BGP LS attribute correspond 398 to the BGP LS path attribute length ? 400 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 401 correspond to the BGP MP_REACH_NLRI length ? 403 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 404 attribute correspond to the BGP MP_UNREACH_NLRI length ? 406 o Does the sum of all TLVs found in a Node-, Link, prefix (IPv4 or 407 IPv6) NLRI attribute correspond to the Node-, Link- or Prefix 408 Descriptors 'Total NLRI Length' field ? 410 o Does any fixed length TLV correspond to the TLV Length field in 411 this document ? 413 o Does the sum of MAC reachability TLVs equal the length of the 414 field? 416 In addition, the following checks need to be made for the fields 417 specific to the BGP LS for TRILL: 419 PROTOCOL ID is TRILL 421 NLRI types are valid per Table 2 423 MAC Reachability NLRI has correct format including: 425 o Identifier (64 bits), 427 o local node descriptor with AREA address TLV has the form 428 found in Figure 2 430 opaque TLV support the range of ISIS-TLV/SUB-TLV shown in Table 431 3, and link TLVs support the range in Figure 8. 433 5. Security Considerations 435 Procedures and protocol extensions defined in this document do not 436 affect the BGP security model. See [RFC6952] for details. 438 6. IANA Considerations 440 For all of the following assignments, [this document] is the 441 reference. 443 IANA is requested to assign one Protocol-ID for "TRILL" from the BGP- 444 LS registry of Protocol-IDs. 446 IANA is requested to assign one NLRI Type for "MAC Reachability" from 447 the BGP-LS registry of NLRI Types. 449 IANA is requested to assign one Node Flag bit for "Layer 3 Gateway" 450 from the BGP-LS registry of BGP-LS Attribute TLVs. 452 IANA is requested to assign one new TLV type for "Link MTU" from the 453 BGP-LS registry of BGP-LS Attribute TLVs. 455 Normative References 457 [I-D.ietf.idr-error-handling] - Enke, C., John, S., Pradosh, M., 458 Keyur,P., "Revised Error Handling for BGP UPDATE Messages", 459 draft-ietf-idr-error-handling-19(work in progress), April 2015. 461 [IS-IS] - International Organization for Standardization, 462 "Information technology -- Telecommunications and information 463 exchange between systems -- Intermediate System to Intermediate 464 System intra-domain routeing information exchange protocol for 465 use in conjunction with the protocol for providing the 466 connectionless-mode network service (ISO 8473)", ISO/IEC 467 10589:2002, Second Edition, November 2002. 469 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, March 1997. 472 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S.,and A. 473 Ghanwani, "Routing Bridges (RBridges): Base Protocol 474 Specification", RFC 6325, July 2011. 476 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 477 and D. Dutt, "Transparent Interconnection of Lots of Links 478 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 479 10.17487/RFC7172, May 2014, . 482 [RFC7176] - Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 483 Banerjee, A.," Transparent Interconnection of Lots of Links 484 (TRILL) Use of IS-IS", May 2014. 486 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 487 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 488 End Station Address Distribution Information (ESADI) Protocol", 489 RFC 7357, September 2014, . 492 [RFC7752] - Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., 493 and S. Ray, "North-Bound Distribution of Link-State and Traffic 494 Engineering (TE) Information Using BGP", RFC 7752, DOI 495 10.17487/RFC7752, March 2016, . 498 Informative References 500 [RFC6952] - Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 501 BGP, LDP, PCEP, and MSDP Issues According to the Keying and 502 Authentication for Routing Protocols (KARP) Design Guide", RFC 503 6952, DOI 10.17487/RFC6952, May 2013, 506 Acknowledgments 508 Authors like to thank Ross Callon, Andrew Qu, Jie Dong, Mingui Zhang, 509 Qin Wu, Shunwan Zhuang, Zitao Wang, Lili Wang for their valuable 510 inputs. 512 The document was prepared in raw nroff. All macros used were defined 513 within the source file. 515 Authors' Addresses 517 Weiguo Hao 518 Huawei Technologies 519 101 Software Avenue, 520 Nanjing 210012 521 China 523 Phone: +86-25-56623144 524 Email: haoweiguo@huawei.com 526 Donald E. Eastlake 527 Huawei Technologies 528 155 Beaver Street 529 Milford, MA 01757 USA 531 Phone: +1-508-333-2270 532 Email: d3e3e3@gmail.com 534 Susan K. Hares 535 Hickory Hill Consulting 536 7453 Hickory Hill 537 Saline, MI 48176 USA 539 Email: shares@ndzh.com 541 Sujay Gupta 542 IP Infusion 544 Email: sujay.gupta@ipinfusion.com 546 Muhammad Durrani 547 Cisco 548 Phone: +1-408-527-6921 549 Email: mdurrani@cisco.com 551 Yizhou Li 552 Huawei Technologies 553 101 Software Avenue, 554 Nanjing 210012, China 556 Phone: +86-25-56625375 557 Email: liyizhou@huawei.com 559 Copyright, Disclaimer, and Additional IPR Provisions 561 Copyright (c) 2017 IETF Trust and the persons identified as the 562 document authors. All rights reserved. 564 This document is subject to BCP 78 and the IETF Trust's Legal 565 Provisions Relating to IETF Documents 566 (http://trustee.ietf.org/license-info) in effect on the date of 567 publication of this document. Please review these documents 568 carefully, as they describe your rights and restrictions with respect 569 to this document. Code Components extracted from this document must 570 include Simplified BSD License text as described in Section 4.e of 571 the Trust Legal Provisions and are provided without warranty as 572 described in the Simplified BSD License. The definitive version of 573 an IETF Document is that published by, or under the auspices of, the 574 IETF. Versions of IETF Documents that are published by third parties, 575 including those that are translated into other languages, should not 576 be considered to be definitive versions of IETF Documents. The 577 definitive version of these Legal Provisions is that published by, or 578 under the auspices of, the IETF. Versions of these Legal Provisions 579 that are published by third parties, including those that are 580 translated into other languages, should not be considered to be 581 definitive versions of these Legal Provisions. For the avoidance of 582 doubt, each Contributor to the IETF Standards Process licenses each 583 Contribution that he or she makes as part of the IETF Standards 584 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 585 language to the contrary, or terms, conditions or rights that differ 586 from or are inconsistent with the rights and licenses granted under 587 RFC 5378, shall have any effect and shall be null and void, whether 588 published or posted by such Contributor, or included with or in such 589 Contribution.