idnits 2.17.1 draft-ietf-idr-ls-trill-05.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 13, 2018) is 2020 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 Updates: 7752 Y. Li 4 Huawei 5 S. Gupta 6 IP Infusion 7 M. Durrani 8 Equinix 9 Expires: April 12, 2018 October 13, 2018 11 Distribution of TRILL Link-State using BGP 12 14 Abstract 16 This draft describes a TRILL link state and MAC address reachability 17 information distribution mechanism using a BGP LS extension. 18 External components such as an SDN Controller can use the information 19 for topology visibility, troubleshooting, network automation, and the 20 like. This document updates RFC 7752. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors or the IDR working group mailing list: idr@ietf.org. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 2. Conventions used in this document.......................5 50 3. Carrying TRILL Link-State Information in BGP............6 51 3.1 Node Descriptors.......................................6 52 3.1.1 IGP Router-ID........................................7 53 3.2 MAC Address Descriptors................................7 54 3.2.1 MAC-Reachability TLV.................................8 55 3.3 The BGP-LS Attributes..................................8 56 3.3.1 Node Attribute TLVs..................................8 57 3.3.1.1 Node Flag Bits TLV.................................9 58 3.3.1.2 Opaque Node Attribute TLV..........................9 59 3.3.2. Link Attribute TLVs.................................9 61 4. Operational Considerations.............................10 62 5. Security Considerations................................11 63 6. IANA Considerations....................................12 65 Normative References......................................13 66 Informative References....................................14 68 Acknowledgments...........................................14 69 Authors' Addresses........................................15 71 1. Introduction 73 BGP has been extended to distribute IGP link-state and traffic 74 engineering information to some external components [RFC7752], such 75 as the PCE and ALTO servers. The information can be used by these 76 external components to compute a MPLS-TE path across IGP areas, 77 visualize and abstract network topology, and the like. 79 TRILL (Transparent Interconnection of Lots of Links) protocol 80 [RFC6325] [RFC7780] provides a solution for least cost transparent 81 routing in multi-hop networks with arbitrary topologies and link 82 technologies, using [IS-IS] [RFC7176] link-state routing and a hop 83 count. TRILL switches are sometimes called RBridges (Routing 84 Bridges). 86 The TRILL protocol has been deployed in many data center networks. 87 Data center automation is a vital step to increase the speed and 88 agility of business. An SDN controller as an external component 89 normally can be used to provide centralized control and automation 90 for the data center network. Providing a holistic view of whole 91 network topology to the SDN controller is an important part of data 92 center network automation and troubleshooting. 94 +-------------+ 95 | SDN | 96 --------| Controller |-------- 97 | +-------------+ | 98 | | 99 + + + + 100 + +-----------+ + 101 | | 102 +--------+ |IP Network | +--------+ 103 | | +----+ +----+ | | 104 +---+ +---+ | | | | | | | | +---+ +---+ 105 |ES1|-|RB1|-| Area 1 |-|BRB1| |BRB2|-| Area 2 |-|RB2|-|ES2| 106 +---+ +---+ | | +----+ +----+ | | +---+ +---+ 107 | | | | | | 108 +--------+ +-----------+ +--------+ 110 |<----TRILL ------>||<-----TRILL ----->| 112 Figure 1: TRILL interconnection 114 In Data Center interconnection scenario illustrated in Figure 1, a 115 single SDN Controller or network management system (NMS) can be used 116 for end-to-end network management. End-to-end topology visibility on 117 the SDN controller or NMS is very useful for whole network automation 118 and troubleshooting. BGP LS can be used by the external SDN 119 controller to collect multiple TRILL domain's link-state. 121 BGP LS also can be used for MAC address reachability information 122 synchronization across multiple TRILL domains. The transported MAC 123 reachability information and the like is for telemetry purposes and 124 for use by SDN controller(s) where the coordination or protocol 125 between the SDN controllers is out of scope. 127 This document describes the detailed BGP LS extension mechanisms for 128 TRILL link state and MAC address reachability information 129 distribution. This document updated [RFC7752] by creating a new IANA 130 registry for BGP-LS Node Descriptor Flag Bits. 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 BGP - Border Gateway Protocol 142 BGP-LS - BGP Link-State 144 Data label - VLAN or FGL (Fine Grained Label [RFC7172]) 146 IGP - Interior Gateway Protocol 148 IS - Intermediate System (for this document, all relevant 149 intermediate systems are RBridges) 151 LS - Link State 153 NLRI - Network Layer Reachability Information 155 SDN - Software Defined Networking 157 RBridge - A device implementing the TRILL protocol 159 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 160 [RFC7176] [RFC7780] 162 3. Carrying TRILL Link-State Information in BGP 164 In [RFC7752], several BGP-LS NLRI types are defined. For TRILL link- 165 state distribution, the Node NLRI and Link NLRI are extended to carry 166 layer 3 gateway role and link MTU information. TRILL specific 167 attributes are carried using opaque Node Attribute TLVs. Examples of 168 such attributes are nickname, distribution tree number and 169 identifiers, interested VLANs/Fine Grained Label, and multicast group 170 address, etc. 172 To differentiate the TRILL protocol from layer 3 IGP protocols, a new 173 TRILL Protocol-ID = TBD1 is specified. 175 ESADI (End Station Address Distribution Information) protocol 176 [RFC7357] is a per data label control plane MAC learning solution. 177 MAC address reachability information is carried in ESADI packets. 178 Compared with data plane MAC learning solution, ESADI protocol has 179 security and fast update advantage that are pointed out in [RFC7357]. 181 For an RBridge that is announcing participation in ESADI, the RBridge 182 can distribute MAC address reachability information to external 183 components using BGP. A new "MAC Reachability NLRI" NLRI type TBD2 is 184 used for the MAC address reachability distribution. 186 The MAC Reachability NLRI uses the format as shown in the following 187 Figure. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+ 192 | Protocol-ID | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Identifier | 195 | (64 bits) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 // Local Node Descriptor (variable) // 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 // MAC Address Descriptors (variable) // 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: The MAC Reachability NLRI format 204 3.1 Node Descriptors 206 The Node Descriptor Sub-TLV types include Autonomous System and BGP- 207 LS Identifier, IS-IS Area-ID and IGP Router-ID. TRILL uses a fixed 208 zero Area Address as specified in [RFC6325], Section 4.2.3. This is 209 encoded in a 4-byte Area Address TLV (TLV #1) as follows: 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | 0x01, Area Address Type | (1 byte) 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | 0x02, Length of Value | (1 byte) 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | 0x01, Length of Address | (1 byte) 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | 0x00, zero Area Address | (1 byte) 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 3: Area Address TLV 223 3.1.1 IGP Router-ID 225 Similar to layer 3 IS-IS, TRILL protocol uses 7-octet "IS-IS ID" as 226 the identity of an RBridge or a pseudonode, IGP Router ID sub-TLV in 227 Node Descriptor TLVs contains the 7-octet "IS-IS ID". In TRILL 228 network, each RBridge has a unique 48-bit (6-octet) IS-IS System ID. 229 This ID may be derived from any of the RBridge's unique MAC addresses 230 or configured. A pseudonode is assigned a 7-octet ID by the DRB 231 (Designated RBridge) that created it, the DRB is similar to the 232 "Designated Intermediate System" (DIS) corresponding to a LAN. 234 3.2 MAC Address Descriptors 236 The "MAC Address Descriptor" field is a set of Type/Length/Value 237 (TLV) triplets. "MAC Address Descriptor" TLVs uniquely identify an 238 MAC address reachable by a Node. The following attributes TLVs are 239 defined: 241 +--------------+---------------------+----------+-----------------+ 242 | TLV Code | Description | Length | Value defined | 243 | Point | | | in: | 244 +--------------+---------------------+----------+-----------------+ 245 | 1 | MAC-Reachability | variable | section 3.2.1 | 246 +--------------+---------------------+----------+-----------------+ 248 Table 1: MAC Address Descriptor TLVs 250 3.2.1 MAC-Reachability TLV 252 +-+-+-+-+-+-+-+-+ 253 | Type= MAC-RI | (1 byte) 254 +-+-+-+-+-+-+-+-+ 255 | Length | (1 byte) 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+ 257 |V|F| RESV | Data Label | (4 bytes) 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | MAC (1) (6 bytes) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | ................. | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | MAC (N) (6 bytes) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 4: MAC-Reachability TLV format 268 Length is 4 plus a multiple of 6. 270 The bits of 'V' and 'F' are used to identify Data Label type and are 271 defined as follows: 273 +----------+-------------------------+ 274 | Bit | Description | 275 +----------+-------------------------+ 276 | 'V' | VLAN | 277 | 'F' | Fine Grained Label | 278 +----------+-------------------------+ 280 Table 2: Data Label Type Bits Definitions 282 Notes: If BGP LS is used for NVO3 network MAC address distribution 283 between an external SDN Controller and NVE, Data Label can be used to 284 represent 24 bits VN ID. 286 3.3 The BGP-LS Attributes 288 3.3.1 Node Attribute TLVs 289 3.3.1.1 Node Flag Bits TLV 291 A new Node Flag bit TBD4 is added to the Node Flag Bits TLV. This 292 flag indicates that the node is a distributed Layer 3 gateway 293 [RFC7956]. 295 3.3.1.2 Opaque Node Attribute TLV 297 The Opaque Node Attribute TLV is used as the envelope to 298 transparently carry TRILL specific information. In most cases, this 299 information is encoded as sub-TLVs within the IS-IS Router Capability 300 and MT-Capability TLVs or as the Group Address (GADDR) TLV. Many of 301 these are specified in [RFC7176] but additional sub-TLVs have been 302 specified and may be specified in the future that also can be carried 303 using the Opaque Node Attribute TLV. 305 3.3.2. Link Attribute TLVs 307 Link attribute TLVs are TLVs that may be encoded in the BGP-LS 308 attribute with a link NLRI. Besides the TLVs that has been defined in 309 [RFC7752] section 3.3.2 Table 9, the following 'Link Attribute' TLV 310 is provided for TRILL. 312 +----------+--------------+------------+-----------------------+ 313 | TLV Code | Description | IS-IS TLV | Defined in: | 314 | Point | | /Sub-TLV | | 315 +----------+--------------+------------+-----------------------+ 316 | TBD3 | Link MTU | 22/28 | [RFC7176] Section 2.4 | 317 +----------+--------------+------------+-----------------------+ 319 Table 7: Link Attribute TLVs 321 4. Operational Considerations 323 This document does not require any MIB or YANG model to configure 324 operational parameters. 326 Any implementation of this specification (i.e. that distributes TRILL 327 Link-State information using BGP), MUST do the malformed attribute 328 checks below, and if it detects a malformed attribute, it should use 329 the 'Attribute Discard' action per [I-D.ietf.idr-error-handling] 330 section 2. 332 An implementation MUST perform the following expanded BGP-LS 333 syntactic check for determining if the message is malformed: 335 o Does the sum of all TLVs found in the BGP LS attribute correspond 336 to the BGP LS path attribute length ? 338 o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute 339 correspond to the BGP MP_REACH_NLRI length ? 341 o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI 342 attribute correspond to the BGP MP_UNREACH_NLRI length ? 344 o Does the sum of all TLVs found in a Node-, Link, prefix (IPv4 or 345 IPv6) NLRI attribute correspond to the Node-, Link- or Prefix 346 Descriptors 'Total NLRI Length' field ? 348 o Does every fixed length TLV correspond to the TLV Length field in 349 this document ? 351 o Does the sum of MAC reachability TLVs equal the length of the 352 field? 354 In addition, the following checks need to be made for the fields 355 specific to the BGP LS for TRILL: 357 PROTOCOL ID is TRILL 359 NLRI types are valid 361 MAC Reachability NLRI has correct format including: 363 o Identifier (64 bits), 365 o local node descriptor with AREA address TLV has the form 366 found in Figure 2 368 5. Security Considerations 370 Procedures and protocol extensions defined in this document do not 371 affect the BGP security model. See [RFC6952] for details. 373 6. IANA Considerations 375 For all of the following assignments, [this document] is the 376 reference. 378 IANA is requested to assign one Protocol-ID TBD1 for "TRILL" from the 379 BGP-LS registry of Protocol-IDs. 381 IANA is requested to assign one NLRI Type TBD2 for "MAC Reachability" 382 from the BGP-LS registry of NLRI Types. 384 IANA is requested to assign one new TLV type TBD3 for "Link MTU" from 385 the BGP-LS registry of BGP-LS Attribute TLVs. 387 IANA is requested to create a registry for BGP-LS Node Descriptor 388 Flag Bits and to assign one Node Flag bit TBF4 [bit 6 suggested] for 389 "Layer 3 Gateway". This new registry is to be added to the IANA 390 Border Gateway Protocol - Link State (BGP-LS) Parameters web page as 391 follows: 393 Name: BGP-LS Node Descriptor Flag Bits 394 Registration Procedure: Expert Review 395 Reference: [RFC7752] 396 Note: These bits are in the payload of the Node Flag Bits TLV. 397 The bit array is variable length so the maximum bit value 398 assignable is very large; however, length of the TLV grows 399 linearly with the highest numbered flag bit used and there 400 may be practical limits on the length of the TLV. 402 Bit Letter Description Reference 403 ---- ------ -------------- ------------ 404 0 O Overload Bit [ISO10589] 405 1 T Attached Bit [ISO10589] 406 2 E External Bit [RFC2328] 407 3 B ABR Bit [RFC2328] 408 4 R Router Bit [RFC5340] 409 5 V V6 Bit [RFC5340] 410 6 G L3 Gateway Bit [this document][RFC7956] 411 7-up - Unassigned 413 Normative References 415 [I-D.ietf.idr-error-handling] - Enke, C., John, S., Pradosh, M., 416 Keyur,P., "Revised Error Handling for BGP UPDATE Messages", 417 draft-ietf-idr-error-handling-19(work in progress), April 2015. 419 [IS-IS] - International Organization for Standardization, 420 "Information technology -- Telecommunications and information 421 exchange between systems -- Intermediate System to Intermediate 422 System intra-domain routeing information exchange protocol for 423 use in conjunction with the protocol for providing the 424 connectionless-mode network service (ISO 8473)", ISO/IEC 425 10589:2002, Second Edition, November 2002. 427 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 431 Ghanwani, "Routing Bridges (RBridges): Base Protocol 432 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 433 . 435 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 436 and D. Dutt, "Transparent Interconnection of Lots of Links 437 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 438 10.17487/RFC7172, May 2014, . 441 [RFC7176] - Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 442 Banerjee, A.," Transparent Interconnection of Lots of Links 443 (TRILL) Use of IS-IS", May 2014. 445 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 446 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 447 End Station Address Distribution Information (ESADI) Protocol", 448 RFC 7357, September 2014, . 451 [RFC7752] - Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., 452 and S. Ray, "North-Bound Distribution of Link-State and Traffic 453 Engineering (TE) Information Using BGP", RFC 7752, DOI 454 10.17487/RFC7752, March 2016, . 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 [RFC7956] - Hao, W., Li, Y., Qu, A., Durrani, M., and P. Sivamurugan, 464 "Transparent Interconnection of Lots of Links (TRILL) 465 Distributed Layer 3 Gateway", RFC 7956, DOI 10.17487/RFC7956, 466 September 2016, . 468 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 469 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 470 2017, . 472 Informative References 474 [ISO10589] - SO, "Intermediate System to Intermediate System intra- 475 domain routeing information exchange protocol for use in 476 conjunction with the protocol for providing the connectionless- 477 mode network service (ISO 8473)", International Standard 478 10589:2002, Second Edition, 2002. 480 [RFC2328] - Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 481 10.17487/RFC2328, April 1998, . 484 [RFC5340] - Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 485 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 486 . 488 [RFC6952] - Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 489 BGP, LDP, PCEP, and MSDP Issues According to the Keying and 490 Authentication for Routing Protocols (KARP) Design Guide", RFC 491 6952, DOI 10.17487/RFC6952, May 2013, 494 Acknowledgments 496 Authors thank Susan Hares, John Scudder, Ross Callon, Andrew Qu, Jie 497 Dong, Mingui Zhang, Qin Wu, Shunwan Zhuang, Zitao Wang, Lili Wang for 498 their valuable inputs. 500 Authors' Addresses 502 Weiguo Hao 503 Huawei Technologies 504 101 Software Avenue, 505 Nanjing 210012, China 507 Phone: +86-25-56623144 508 Email: haoweiguo@huawei.com 510 Donald E. Eastlake 511 Huawei Technologies 512 1424 Pro Shop Court 513 Davenport, FL 33896 USA 515 Phone: +1-508-333-2270 516 Email: d3e3e3@gmail.com 518 Yizhou Li 519 Huawei Technologies 520 101 Software Avenue, 521 Nanjing 210012, China 523 Phone: +86-25-56625375 524 Email: liyizhou@huawei.com 526 Sujay Gupta 527 IP Infusion 529 Email: sujay.gupta@ipinfusion.com 531 Muhammad Durrani 532 Equinix 534 Email: mdurrani@equinix.com 536 Copyright, Disclaimer, and Additional IPR Provisions 538 Copyright (c) 2018 IETF Trust and the persons identified as the 539 document authors. All rights reserved. 541 This document is subject to BCP 78 and the IETF Trust's Legal 542 Provisions Relating to IETF Documents 543 (http://trustee.ietf.org/license-info) in effect on the date of 544 publication of this document. Please review these documents 545 carefully, as they describe your rights and restrictions with respect 546 to this document. Code Components extracted from this document must 547 include Simplified BSD License text as described in Section 4.e of 548 the Trust Legal Provisions and are provided without warranty as 549 described in the Simplified BSD License. The definitive version of 550 an IETF Document is that published by, or under the auspices of, the 551 IETF. Versions of IETF Documents that are published by third parties, 552 including those that are translated into other languages, should not 553 be considered to be definitive versions of IETF Documents. The 554 definitive version of these Legal Provisions is that published by, or 555 under the auspices of, the IETF. Versions of these Legal Provisions 556 that are published by third parties, including those that are 557 translated into other languages, should not be considered to be 558 definitive versions of these Legal Provisions. For the avoidance of 559 doubt, each Contributor to the IETF Standards Process licenses each 560 Contribution that he or she makes as part of the IETF Standards 561 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 562 language to the contrary, or terms, conditions or rights that differ 563 from or are inconsistent with the rights and licenses granted under 564 RFC 5378, shall have any effect and shall be null and void, whether 565 published or posted by such Contributor, or included with or in such 566 Contribution.