idnits 2.17.1 draft-ietf-trill-directory-assist-mechanisms-08.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 31, 2016) is 2731 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) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Linda Dunbar 3 Huawei 4 Radia Perlman 5 EMC 6 Yizhou Li 7 Huawei 8 Expires: April 30, 2017 October 31, 2016 10 TRILL: Edge Directory Assist Mechanisms 11 13 Abstract 14 This document describes mechanisms for providing directory service to 15 TRILL (Transparent Interconnection of Lots of Links) edge switches. 16 The directory information provided can be used in reducing multi- 17 destination traffic, particularly ARP/ND and unknown unicast 18 flooding. It can also be used to detect traffic with forged source 19 addresses. 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the TRILL working group mailing list. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................4 47 1.1 Uses of Directory Information..........................4 48 1.2 Terminology............................................5 50 2. Push Model Directory Assistance Mechanisms..............7 51 2.1 Requesting Push Service................................7 52 2.2 Push Directory Servers.................................7 53 2.3 Push Directory Server State Machine....................8 54 2.3.1 Push Directory States................................9 55 2.3.2 Push Directory Events and Conditions................11 56 2.3.3 State Transition Diagram and Table..................12 57 2.4 Additional Push Details...............................13 58 2.5 Primary to Secondary Server Push Service..............15 59 2.6 Push Directory Configuration..........................15 61 3. Pull Model Directory Assistance Mechanisms.............17 62 3.1 Pull Directory Message Common Format..................18 63 3.2 Pull Directory Query and Response Messages............19 64 3.2.1 Pull Directory Query Message Format.................19 65 3.2.2 Pull Directory Responses............................22 66 3.2.2.1 Pull Directory Response Message Format............23 67 3.2.2.2 Pull Directory Forwarding.........................25 68 3.3 Cache Consistency.....................................26 69 3.3.1 Update Message Format...............................29 70 3.3.2 Acknowledge Message Format..........................30 71 3.4 Summary of Records Formats in Messages................31 72 3.5 End Stations and Pull Directories.....................31 73 3.5.1 Pull Directory Hosted on an End Station.............32 74 3.5.2 Pull Directory Use by End Stations..................33 75 3.5.3 Native Pull Directory Messages......................34 76 3.6 Pull Directory Message Errors.........................34 77 3.6.1 Error Codes.........................................35 78 3.6.2 Sub-Errors Under Error Codes 1 and 3................36 79 3.6.3 Sub-Errors Under Error Codes 128 and 131............36 80 3.7 Additional Pull Details...............................37 81 3.8 The No Data Flag......................................37 82 3.9 Pull Directory Service Configuration..................38 84 4. Directory Use Strategies and Push-Pull Hybrids.........40 86 5. TRILL ES-IS............................................42 87 5.1 PDUs and System IDs...................................42 88 5.2 Adjacency, DRB Election, Hellos, TLVs, Etc............42 89 5.3 Link State............................................43 91 6. Security Considerations................................44 93 Table of Contents Continued 95 7. IANA Considerations....................................45 96 7.1 ESADI-Parameter Data Extensions.......................45 97 7.2 RBridge Channel Protocol Numbers......................46 98 7.3 The Pull Directory (PUL) and No Data (NOD) Bits.......46 99 7.4 TRILL Pull Directory QTYPEs...........................46 100 7.5 Pull Directory Error Code Registries..................47 101 7.6 TRILL-ES-IS MAC Address...............................47 103 Normative References......................................48 104 Informational References..................................49 106 Acknowledgments...........................................51 108 Authors' Addresses........................................52 110 1. Introduction 112 [RFC7067] gives a problem statement and high level design for using 113 directory servers to assist TRILL [RFC6325] [RFC7780] edge nodes in 114 reducing multi-destination ARP/ND [ARPND], reducing unknown unicast 115 flooding traffic, and improving security against address spoofing 116 within a TRILL campus. Because multi-destination traffic becomes an 117 increasing burden as a network scales up in number of nodes, reducing 118 ARP/ND and unknown unicast flooding improves TRILL network 119 scalability. This document describes specific mechanisms for TRILL 120 directory servers. 122 The information held by the Directory(s) is address mapping and 123 reachability information. Most commonly, what MAC (Media Access 124 Control) address [RFC7042] corresponds to an IP address within a Data 125 Label (VLAN or FGL (Fine Grained Label [RFC7172])) and the egress 126 TRILL switch (RBridge), and optionally what specific port on that 127 TRILL switch, from which that MAC address is reachable. But it could 128 be what IP address corresponds to a MAC address or possibly other 129 address mapping or reachability information. 131 In the data center environment, it is common for orchestration 132 software to know and control where all the IP addresses, MAC 133 addresses, and VLANs/tenants are in a data center. Thus such 134 orchestration software can be appropriate for providing the directory 135 function or for supplying the Directory(s) with directory 136 information. 138 Directory services can be offered in a Push Mode, Pull Mode, or both 139 [RFC7067] at the option of the server. Push Mode, in which a 140 directory server pushes information to TRILL switches indicating 141 interest, is specified in Section 2. Pull Mode, in which a TRILL 142 switch queries a server for the information it wants, is specified in 143 Section 3. More detail on modes of operation, including hybrid 144 Push/Pull, are provided in Section 4. 146 The mechanism used to initially populate directory data in primary 147 servers is beyond the scope of this document. A primary server can 148 use the Push Directory service to provide directory data to secondary 149 servers as described in Section 2.5. 151 1.1 Uses of Directory Information 153 A TRILL switch can consult Directory information whenever it wants, 154 by (1) searching through information that has been retained after 155 being pushed to it or pulled by it or (2) by requesting information 156 from a Pull Directory. However, the following are expected to be the 157 most common circumstances leading to directory information use. All 158 of these are cases of ingressing (or originating) a native frame. 160 1. ARP requests and replies [RFC826] are normally broadcast. But a 161 directory assisted edge TRILL switch could intercept ARP messages 162 and reply if the TRILL switch has the relevant information 163 [ARPND]. 165 2. IPv6 ND (Neighbor Discovery [RFC4861]) requests and replies are 166 normally multicast. Except in the case of Secure ND [RFC3971], 167 where possession of the right keying material might be required, a 168 directory assisted edge TRILL switch could intercept ND messages 169 and reply if the TRILL switch has the relevant information. 170 [ARPND] 172 3. Unknown destination MAC addresses. An edge TRILL switch ingressing 173 a native frame necessarily has to determine if it knows the egress 174 RBridge from which the destination MAC address of the frame (in 175 the frame's VLAN or FGL) is reachable. It might learn that 176 information from the directory or could query the directory if it 177 does not know. Furthermore, if the edge TRILL switch has complete 178 directory information, it can detect a forged source MAC or IP 179 address in the native frame and discard the frame if it finds such 180 a forged address. 182 4. RARP [RFC903] (Reverse ARP) is similar to ARP as above. 184 1.2 Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 The terminology and acronyms of [RFC6325] are used herein along with 191 the following: 193 CSNP Time: Complete Sequence Number PDU Time. See ESDADI [RFC7357] 194 and Section 7.1 below. 196 Data Label: VLAN or FGL. 198 ESADI: End Station Address Distribution Information [RFC7357]. 200 FGL: Fine Grained Label [RFC7172]. 202 FR: Flood Record flag bit. See Section 3.2.1. 204 Host: A physical server or a virtual machine. A host must have a MAC 205 address and usually has at least one IP address. 207 Interested Labels sub-TLV: Short for "Interested Labels and Spanning 208 Tree Roots sub-TLV" [RFC7176]. 210 Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning 211 Tree Roots sub-TLV" [RFC7176]. 213 IP: Internet Protocol. In this document, IP includes both IPv4 and 214 IPv6. 216 MAC: Media Access Control address [RFC7042] 218 MacDA: Destination MAC address. 220 OV: Overflow flag bit. See Section 3.2.2.1. 222 PDSS: Push Directory Server Status. See Sections 2 and 7.1 below. 224 PUL: Pull Directory flag bit. See Sections 3 and 7.3 below. 226 primary server: A Directory server that obtains the information it is 227 serving up by a reliable mechanism outside the scope of this 228 document designed to assure the freshness of that information. 229 (See secondary server.) 231 RBridge: An alternative name for a TRILL switch. 233 secondary server: A Directory server that obtains the information it 234 is serving up from one or more primary servers. 236 TLV: Type, Length, Value 238 TRILL: Transparent Interconnection of Lots of Links or Tunneled 239 Routing in the Link Layer. 241 TRILL switch: A device that implements the TRILL protocol. 243 2. Push Model Directory Assistance Mechanisms 245 In the Push Model [RFC7067], one or more Push Directory servers 246 reside at TRILL switches and push down the address mapping 247 information for the various addresses associated with end station 248 interfaces and the TRILL switches from which those interfaces are 249 reachable [RFC7961]. This service is scoped by Data Label (VLAN or 250 FGL [RFC7172]). A Push Directory also advertises whether or not it 251 believes it has pushed complete mapping information for a Data Label. 252 It might be pushing only a subset of the mapping and/or reachability 253 information for a Data Label. The Push Model uses the ESADI [RFC7357] 254 (End Station Address Distribution Information) protocol as its 255 distribution mechanism. 257 With the Push Model, if complete address mapping information for a 258 Data Label is being pushed, a TRILL switch (RBridge) that has that 259 complete information and is ingressing a native frame can simply drop 260 the frame if the destination unicast MAC address can't be found in 261 the mapping information available, instead of flooding the frame 262 (ingressing it as an unknown MAC destination TRILL Data frame). But 263 this will result in lost traffic if ingress TRILL switch's directory 264 information is incomplete. 266 2.1 Requesting Push Service 268 In the Push Model, it is necessary to have a way for a TRILL switch 269 to subscribe to information from the directory server(s). TRILL 270 switches simply use the ESADI [RFC7357] protocol mechanism to 271 announce, in their core IS-IS LSPs, the Data Labels for which they 272 are participating in ESADI by using the Interested VLANs and/or 273 Interested Labels sub-TLVs [RFC7176]. This will cause the Directory 274 information to be pushed to them for all such Data Labels that are 275 being served by the one or more Push Directory servers. 277 2.2 Push Directory Servers 279 Push Directory servers advertise, through ESADI, their availability 280 to push the mapping information for a particular Data Label by 281 setting the PDSS (Push Directory Server Status) in their ESADI 282 Parameter APPsub-TLV for that ESADI instance (see [RFC7357] and 283 Section 7.1) to a non-zero value. This PDSS field setting is visible 284 to other ESADI participants, including other Push Directory servers, 285 for that Data Label Each Push Directory server MUST participate in 286 ESADI for the Data Labels for which it will push mappings and set the 287 PDSS field in its ESADI-Parameters APPsub-TLV for that Data Label. 289 For robustness, it is useful to have multiple Push Directory Servers 290 for each Data Label. Each Push Directory server is configured with a 291 number N in the range 1 to 8, which defaults to 2, for each Data 292 Label for which it can push directory information (see 293 PushDirServers, Section 2.6). If the Push Directory servers for a 294 Data Label are configured consistently with the same N and at least N 295 servers are available, then N copies of that directory will be 296 pushed. 298 Each Push Directory server also has a configurable 8-bit priority 299 (PushDirPriority) to be Active, which defaults to 0x3F (see Section 300 2.6). This priority is treated as an unsigned integer where larger 301 magnitude means higher priority. This priority appears in its ESADI 302 Parameter APPsub-TLV (see Section 7.1). In case of a tie in this 303 configurable priority, the System ID of the TRILL switch acting as 304 the server is used as an unsigned 6-byte integer where larger 305 magnitude indicates higher priority. 307 For each Data Label it can serve, each Push Directory server checks 308 to see if there appear to be enough higher priority servers to push 309 the desired number of copies. It does this by ordering, by priority, 310 the Push Directory servers whose advertisements are present in the 311 ESADI link state database for that Data Label and that are data 312 reachable [RFC7780] as indicated by its IS-IS link state database. 313 The Push Directory server then determines its own position in that 314 order. If a Push Directory server's configuration indicates that N 315 copies of the mappings for a Data Label should be pushed and the 316 server finds that it is number K in the priority ordering (where the 317 1 is highest priority and the highest is lowest priority), then if K 318 is less than or equal to N the Push Directory server is Active. If K 319 is greater than N it is Stand-By. Active and Stand-By behavior are 320 specified below in Section 2.3. 322 For a Push Directory to reside on an end station, one or more TRILL 323 switches locally connected to that end station must proxy for the 324 Push Directory server and advertise themselves in ESADI as Push 325 Directory servers. It appears to the rest of the TRILL campus that 326 these TRILL switches (that are proxying for the end station) are the 327 Push Directory server(s). The protocol between such a Push Directory 328 end station and the one or more proxying TRILL switches acting as 329 Push Directory servers is beyond the scope of this document. 331 2.3 Push Directory Server State Machine 333 The subsections below describe the states, events, and corresponding 334 actions for Push Directory servers. 336 The meaning of the value of the PDSS field in a Push Directory's 337 ESADI Parameter APPsub-TLV is summarized in the table below. 339 PDSS Meaning 340 ---- ---------- 341 0 Not a Push Directory Server 342 1 Push Directory Server in Stand-By Mode 343 2 Push Directory Server in Active Mode but not complete 344 3 Push Directory Server in Active Mode that has pushed 345 complete data 347 2.3.1 Push Directory States 349 A Push Directory Server is in one of seven states, as listed below, 350 for each Data Label it can serve. The name of each state is followed 351 by a symbol that starts and ends with an angle bracket and represents 352 the state. The value that the Push Directory Server advertises in 353 PDSS is determined by the state. In addition, it has an internal 354 State-Transition-Time variable for each Data Label it serves that is 355 set at each state transition and which enables it to determine how 356 long it has been in its current state for that Data Label. 358 Down : A completely shut down virtual state defined for 359 convenience in specifying state diagrams. A Push Directory Server 360 in this state does not advertise any Push Directory data. It may 361 be participating in ESDADI [RFC7357] with the PDSS field zero in 362 its ESADI-Parameters or might be not participating in ESADI at 363 all. All states other than the Down state are considered to be Up 364 states and imply a non-zero PDSS field. 366 Stand-By : No Push Directory data is advertised. Any outstanding 367 EASDI-LSP fragments containing directory data are updated to 368 remove that data and, if the result is an empty fragment (contains 369 nothing except possibly an Authentication TLV), the fragment is 370 purged. The Push Directory participates in ESDADI [RFC7357] and 371 advertises its ESADI fragment zero that includes an ESADI- 372 Parameters APPsub-TLV with the PDSS field set to 1. 374 Active : The Push Directory participates in ESDADI [RFC7357] and 375 advertises its ESADI fragment zero that includes an ESADI- 376 Parameters APPsub-TLV with the PDSS field set to 2. It also 377 advertises its directory data and any changes through ESADI 378 [RFC7357] in its ESADI-LSPs using the Interface Addresses 379 [RFC7961] APPsub-TLV and updates that information as it changes. 381 Active Completing : Same behavior as the Active state except 382 that the server responds differently to events. The purpose of 383 this state is to be sure there has been enough time for directory 384 information to propagate to subscribing edge TRILL switches before 385 the Directory Server advertises that the information is complete. 387 Active Complete : The same behavior as Active except that the 388 PDSS field in the ESADI-Parameters APPsub-TLV is set to 3 and the 389 server responds differently to events. 391 Going Stand-By : The same behavior as Active except that the 392 server responds differently to events. The purpose of this state 393 is to be sure that the information, that the directory will no 394 longer be complete, has enough time to propagate to edge TRILL 395 switches before the Directory Server stops advertising updates to 396 the information. (See note below.) 398 Active Uncompleting : The same behavior as Active except that it 399 responds differently to events. The purpose of this state is to be 400 sure that the information, that the directory will no longer be 401 complete, has enough time to propagate to edge TRILL switches 402 before the Directory Server might stop advertising updates to the 403 information. (See note below.) 405 Note: It might appear that a Push Directory could transition 406 directly from Active Complete to Active, since Active state 407 continues to advertise updates, eliminating the need for the 408 Active Uncompleting transition state. But consider the case of 409 the Push Directory that was complete being configured to be 410 incomplete and then the Stand-By Condition (see Section 2.3.2) 411 occurring shortly thereafter. If the first of these two events 412 caused the server to transition directly to the Active state 413 then, when the Stand-By Condition occurred, it would 414 immediately transition to Stand-By and stop advertising updates 415 even though there might not have been enough time for knowledge 416 of its incompleteness to have propagated to all edge TRILL 417 switches. 419 The following table summarizes PDSS value for each state: 421 State PDSS 422 ---------- ------ 423 Down 0 424 Stand-By 1 425 Active 2 426 Active Completing 2 427 Active Complete 3 428 Going Stand-By 2 429 Active Uncompleting 2 431 2.3.2 Push Directory Events and Conditions 433 Three auxiliary conditions referenced later in this section are 434 defined as follows for convenience: 436 The Activate Condition: In order to have the desired number of Push 437 Directory servers pushing data for Data Label X, this Push 438 Directory server should be active. This is determined by the 439 server finding that (A) it is priority K among the data reachable 440 Push Directory servers (where highest priority server is 1) for 441 Data Label X, (B) it is configured that there should be N copies 442 pushed for Data Label X, and (C) K is less than or equal to N. For 443 example, if the Push Directory server is configured so that 2 444 copies should be pushed and finds that it is priority 1 or 2 among 445 the Push Directory servers that are visible in its ESADI link 446 state database and that are data reachable as indicated by its IS- 447 IS link state database. 449 The Stand-By Condition: In order to have the desired number of Push 450 Directory servers pushing data for Data Label X, this Push 451 Directory server should be stand-by (not active). This is 452 determined by the server finding that (A) it is priority K among 453 the data reachable Push Directory servers (where highest priority 454 server is 1) for Data Label X, (B) it is configured that there 455 should be N copies pushed for Data Label X, and (C) K is greater 456 than N. For example, the Push Directory server is configured that 457 2 copies should be pushed and finds that it is priority 3 or lower 458 priority (higher number) among the available Push directory 459 servers. 461 The Time Condition: The Push Directory server has been in its current 462 state for a configurable amount of time (PushDirTimer) that 463 defaults to twice its CSNP (Complete Sequence Number PDU) time 464 (see Sections 2.6 and 7.1).) 466 The events and conditions listed below cause state transitions in 467 Push Directory servers. 469 1. Push Directory server comes Up. 471 2. The Push Directory server or the TRILL switch on which it resides 472 is being shut down. 474 3. The Activate Condition is met and the server's configuration 475 indicates it does not have complete data. 477 4. The Stand-By Condition is met. 479 5. The Activate Condition is met and the server's configuration 480 indicates it has complete data. 482 6. The server's configuration is changed to indicate it does not have 483 complete data. 485 7. The Time Condition is met. 487 2.3.3 State Transition Diagram and Table 489 The state transition table is as follows: 491 State|Down|Stand-By|Active| Active | Active | Going | Active 492 -----+ | | |Completing|Complete|Stand-By|Uncompleting 493 Event|| | | | | | 494 -----+----+--------+------+----------+--------+---------+------------ 495 1 || N/A | N/A | N/A | N/A | N/A | N/A 496 2 || | | | | | 497 3 || | | | | | 498 4 || | | | | | 499 5 || | | | | | 500 6 || | | | | | 501 7 || | | | | | 503 The above state table is equivalent to the following transition 504 diagram: 506 +-----------+ 507 | Down |<---------+ 508 +-----------+ | 509 |1 ^ | 3,4,5,6,7 | 510 | | +------------+ 511 V |2 512 +---------------+ 513 | Stand-By |<------------------------------------------+ 514 +---------------+ ^ ^ ^ | 515 |5 |3 |1,4,6,7 | | | | 516 | | +---------+ | | | 517 | V |2,4 | | 518 | +---------------------+ | | 519 | | Active |<---------|-----------------+ | 520 | +---------------------+ ^ | | | 521 | |5 ^ |1,3,6,7 ^ | | | | 522 | | | | | | | | | 523 | | | +---------+ | | | | 524 | | | | | | | 525 V V |3,6 | | | | 526 +------------------------+ | | | | 527 | Active Completing |------------+ | | 528 +------------------------+ 2,4 | | | 529 |7 |1,5 ^ | | | 530 | | | | | | 531 | +-------+ | | | 532 | | | | 533 | +--------------------------------------+ | | 534 | | | | | | 535 V V |7 |5 |3 |7 536 +---------------+ 3,6 +----------------+ 4 +----------------+ 537 | Active |------->| Active |----->| Going | 538 | Complete | | Uncompleting | | Stand-By | 539 | |<-------| | | | 540 +---------------+ 5 +----------------+ +----------------+ 541 |1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^ 542 | | | | | | | | 543 +-------+ | +------------+ | +--------+ 544 | | 545 +------------------------------------+ 547 Figure 1. Push Server State Diagram 549 2.4 Additional Push Details 551 Push Directory mappings can be distinguished from other data 552 distributed through ESADI because mappings are distributed only with 553 the Interface Addresses APPsub-TLV [RFC7961] and are flagged in that 554 APPsub-TLV as being Push Directory data. 556 TRILL switches, whether or not they are a Push Directory server, MAY 557 continue to advertise any locally learned MAC attachment information 558 in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. 559 However, if a Data Label is being served by complete Push Directory 560 servers, advertising such locally learned MAC attachment generally 561 SHOULD NOT be done as it would not add anything and would just waste 562 bandwidth and ESADI link state space. An exception might be when a 563 TRILL switch learns local MAC connectivity and that information 564 appears to be missing from the directory mapping. 566 Because a Push Directory server needs to advertise interest in one or 567 more Data Labels even though it might not want to receive multi- 568 destination TRILL Data packets in those Data Labels, the No Data 569 (NOD) flag bit is provided as discussed in Section 3.8. 571 When a Push Directory server is no longer data reachable [RFC7780] as 572 indicated by the IS-IS link state database, other TRILL switches MUST 573 ignore any Push Directory data from that server because it is no 574 longer being updated and may be stale. 576 The nature of dynamic distributed asynchronous systems is such that 577 it is impossible for a TRILL switch receiving Push Directory 578 information to be absolutely certain that it has complete 579 information. However, it can obtain a reasonable assurance of 580 complete information by requiring two conditions to be met: 581 1. The PDSS field is 3 in the ESADI zero fragment from the server 582 for the relevant Data Label. 583 2. In so far as it can tell, it has had continuous data 584 connectivity to the server for a configurable amount of time 585 that defaults to twice the server's CSNP time (PushDirTimer, 586 see Section 2.6). 587 Condition 2 is necessary because a client TRILL switch might be just 588 coming up and receive an EASDI LSP meeting the requirement in 589 condition 1 above but has not yet received all of the ESADI LSP 590 fragments from the Push Directory server. 592 Likewise, due to various delays, when an end station connects to or 593 disconnects from the campus there are timing differences between such 594 connection or disconnection, the update of directory information at 595 the directory, and the update of directory information at any 596 particular RBridge in the TRILL campus. Thus, there is commonly a 597 small window during which the an RBridge using directory information 598 might either (1) drop or unnecessarily flood a frame as having an 599 unknown unicast destination or (2) encapsulate a frame to an edge 600 RBridge where the end station is not longer connected when the frame 601 arrives at that edge RBridge. 603 There may be conflicts between mapping information from different 604 Push Directory servers or conflicts between locally learned 605 information and information received from a Push Directory server. In 606 case of such conflicts, information with a higher confidence value 607 [RFC6325] [RFC7961] is preferred over information with a lower 608 confidence. In case of equal confidence, Push Directory information 609 is preferred to locally learned information and if information from 610 Push Directory servers conflicts, the information from the higher 611 priority Push Directory server is preferred. 613 2.5 Primary to Secondary Server Push Service 615 A secondary Push or Pull Directory server is one that obtains its 616 data from a primary directory server. Other techniques MAY be used 617 but, by default, this data transfer occurs through the primary server 618 acting as a Push Directory server for the Data Labels involved while 619 the secondary directory server takes the pushed data it receives from 620 the highest priority Push Directory server and re-originates it. Such 621 a secondary server may be a Push Directory server or a Pull Directory 622 server or both for any particular Data Label. Because the data from a 623 secondary server will necessarily be at least a little less fresh 624 than that from a primary server, it is RECOMMENDED that the re- 625 originated secondary server data be given a confidence level at least 626 one less than that of the data as received from the primary (or 627 unchanged if it is already of minimum confidence). 629 2.6 Push Directory Configuration 631 The following per Data Label configuration parameters are available 632 for controlling Push Directory behavior: 634 Name Range Default Section 635 --------------- -------- ------- ------- 636 PushDirService T/F F 2.2 637 PushDirServers 1 - 8 2 2.2 638 PushDirPriority 0 - 255 0x3F 2.2 639 PushDirComplete T/F F 2.3.1, 2.3.2 640 PushDirTimer 1 - 511 2*CSNP 2.3.2, 2.4 642 PushDirService is a boolean. When false, Push Directory service is 643 not provided; when true, it is. 645 PushDirComplete is a boolean. When false, the server never indicates 646 that the information it has pushed is complete; when true, it does so 647 indicate after pushing all the information it knows. 649 PushDirTimer defaults to two times the ESADI CSNP configuration value 650 but not less than 1 second. 652 3. Pull Model Directory Assistance Mechanisms 654 In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory 655 information from an appropriate Directory Server when needed. 657 A TRILL switch that makes use of Pull Directory services must 658 implement appropriate connections between its directory utilization 659 and its link state database and link state updating. For example, 660 Pull Directory servers for a particular Data Label X are found by 661 looking in the core TRILL IS-IS link state database for data 662 reachable [RFC7780] TRILL switches that advertise themselves by 663 having the Pull Directory flag (PUL) on in their Interested VLANs or 664 Interested Labels sub-TLV (see Section 7.3) for that Data Label. The 665 set of such switches can change with configuration changes by network 666 management, such as starting up or shutting down of Pull Directory 667 servers, or changes in network topology, such the connection or 668 disconnection of TRILL switches that are Pull Directory servers, or 669 network partition or merger. As described in Section 3.7, a TRILL 670 switch MUST notice if a Pull Directory from which it has cached data 671 is no longer data reachable so it can discard such cached data. 673 If multiple data reachable TRILL switches indicate in the link state 674 database that they are Pull Directory Servers for a particular Data 675 Label, pull requests can be sent to any one or more of them but it is 676 RECOMMENDED that pull requests be preferentially sent to the server 677 or servers that are lowest cost from the requesting TRILL switch. 679 Pull Directory requests are sent by enclosing them in an RBridge 680 Channel [RFC7178] message using the Pull Directory channel protocol 681 number (see Section 7.2). Responses are returned in an RBridge 682 Channel message using the same channel protocol number. See Section 683 3.2 for Query and Response Message formats. For cache consistency or 684 notification purposes, Pull Directory servers, under certain 685 conditions, MUST send unsolicited Update Messages to client TRILL 686 switches they believe may be holding old data and those clients can 687 acknowledge such updates, as described in Section 3.3. All these 688 messages have a common header as described in Section 3.1. Errors are 689 returned as described in Section 3.6. 691 The requests to Pull Directory Servers are typically derived from 692 ingressed ARP [RFC826], ND [RFC4861], or RARP [RFC903] messages, or 693 data frames with unknown unicast destination MAC addresses, 694 intercepted by an ingress TRILL switch, as described in Section 1.1. 696 Pull Directory responses include an amount of time for which the 697 response should be considered valid. This includes negative responses 698 that indicate no data is available. It is RECOMMENDED that both 699 positive responses with data and negative responses be cached and 700 used to locally handle ARP, ND, RARP, unknown destination MAC frames, 701 or the like, until the responses expire [ARPND]. If information 702 previously pulled is about to expire, a TRILL switch MAY try to 703 refresh it by issuing a new pull request but, to avoid unnecessary 704 requests, SHOULD NOT do so if it has not been recently used. The 705 validity timer of cached Pull Directory responses is NOT reset or 706 extended merely because that cache entry is used. 708 3.1 Pull Directory Message Common Format 710 All Pull Directory messages are transmitted as the Channel Protocol 711 specific payload of RBridge Channel messages [RFC7178]. Pull 712 Directory messages are formatted as described herein starting with 713 the following common 8-byte header: 715 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Ver | Type | Flags | Count | Err | SubErr | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Sequence Number | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type Specific Payload - variable length 723 +-+-+- ... 725 Ver: Version of the Pull Directory protocol as an unsigned 726 integer. Version zero is specified in this document. 728 Type: The Pull Directory message type as follows: 730 Type Section Name 731 ---- ------- -------- 732 0 - Reserved 733 1 3.2.1 Query 734 2 3.2.2 Response 735 3 3.3.1 Update 736 4 3.3.2 Acknowledge 737 5-14 - Unassigned 738 15 - Reserved 740 Flags: Four flag bits whose meaning depends on the Pull Directory 741 message Type. Flags whose meanings are not specified are 742 reserved, MUST be sent as zero, and MUST be ignored on receipt. 744 Count: Some Pull Directory message types specified herein have 745 zero or more occurrences of a Record as part of the type 746 specific payload. The Count field is the number of occurrences 747 of that Record as an unsigned integer. For any Pull Directory 748 messages not structured with such occurrences, this field MUST 749 be sent as zero and ignored on receipt. 751 Err, SubErr: The error and suberror fields are only used in 752 messages that are in the nature of replies. In messages that 753 are requests or updates, these fields MUST be sent as zero and 754 ignored on receipt. An Err field containing the value zero 755 means no error. The meaning of values in the SubErr field 756 depends on the value of the Err field but, in all cases, a zero 757 SubErr field is allowed and provides no additional information 758 beyond the value of the Err field. 760 Sequence Number: An identifying 32-bit quantity set by the TRILL 761 switch sending a request or other unsolicited message and 762 returned in every corresponding reply or acknowledgement. It is 763 used to match up responses with the message to which they 764 respond. 766 Type Specific Payload: Format depends on the Pull Directory 767 message Type. 769 3.2 Pull Directory Query and Response Messages 771 The format of Pull Directory Query and Response Messages is specified 772 below. 774 3.2.1 Pull Directory Query Message Format 776 A Pull Directory Query Message is sent as the Channel Protocol 777 specific content of an RBridge Channel message [RFC7178] TRILL Data 778 packet or as a native RBridge Channel data frame (see Section 3.5). 779 The Data Label of the packet is the Data Label in which the query is 780 being made. The priority of the channel message is a mapping of the 781 priority of the frame being ingressed that caused the query with the 782 default mapping depending, per Data Label, on the strategy (see 783 Section 4) or a configured priority (DirGenQPriority, Section 3.9) 784 for generated queries. (Generated queries are those not the result of 785 a mapping. For example, a query to refresh a cache entry.) The 786 Channel Protocol specific data is formatted as a header and a 787 sequence of zero or more QUERY Records as follows: 789 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Ver | Type | Flags | Count | Err | SubErr | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Sequence Number | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | QUERY 1 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 798 | QUERY 2 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 800 | ... 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 802 | QUERY K 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 805 Ver, Sequence Number: See 3.1. 807 Type: 1 for Query. Queries received by an TRILL switch that is not 808 a Pull Directory for the relevant Data Label result in an error 809 response (see Section 3.6) unless inhibited by rate limiting. 810 (See [RFC7178] for response if the Pull Directory RBridge 811 Channel protocol is not implemented or enabled.) 813 Flags, Err, and SubErr: MUST be sent as zero and ignored on 814 receipt. 816 Count: Number of QUERY Records present. A Query Message Count of 817 zero is explicitly allowed, for the purpose of pinging a Pull 818 Directory server to see if it is responding. On receipt of such 819 an empty Query Message, a Response Message that also has a 820 Count of zero is returned unless inhibited by rate limiting. 822 QUERY: Each QUERY Record within a Pull Directory Query Message is 823 formatted as follows: 825 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 826 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 827 | SIZE |FR| RESV | QTYPE | 828 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 829 If QTYPE = 1 830 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 831 | AFN | 832 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 833 | Query address ... 834 +--+--+--+--+--+--+--+--+--+--+--... 835 If QTYPE = 2 or 5 836 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 837 | Query frame ... 838 +--+--+--+--+--+--+--+--+--+--+--... 840 SIZE: Size of the QUERY Record in bytes as an unsigned integer 841 not including the SIZE field and following byte. A value of 842 SIZE so large that the material doesn't fit in the Query 843 Message indicates a malformed QUERY Record. The QUERY Record 844 with the illegal SIZE value and any subsequent QUERY Records 845 MUST be ignored and the entire Query Message MAY be ignored. 847 FR: The Flood Record flag that is ignored if QTYPE is zero. If 848 QTYPE is 2 or 5 and the directory information sought is not 849 found, the frame provided is flooded, otherwise it is not 850 forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or 851 5, the FR flag has no effect. 853 RESV: A block of three reserved bits. MUST be sent as zero and 854 ignored on receipt. 856 QTYPE: There are several types of QUERY Records currently 857 defined in two classes as follows: (1) a QUERY Record that 858 provides an explicit address and asks for all addresses for 859 the interface specified by the query address and (2) a QUERY 860 Record that includes a frame. The fields of each are 861 specified below. Values of QTYPE are as follows: 863 QTYPE Description 864 ----- ----------- 865 0 Reserved 866 1 Address query 867 2 Frame query 868 3-4 Unassigned 869 5 Unknown unicast MAC query frame 870 6-14 Unassigned 871 15 Reserved 873 AFN: Address Family Number of the query address. 875 Query Address: The query is asking for any other addresses, 876 and the nickname of the TRILL switch from which they are 877 reachable, that correspond to the same interface as this 878 address, within the Data Label of the query of the 879 address provided. A typically Query Address would be 880 something like the following: 881 (1) A 48-bit MAC address with the querying TRILL switch 882 primarily interested in either 883 (1a) the RBridge by which that MAC address is 884 reachable so that the querying RBridge can 885 forward an unknown (before the query) 886 destination MAC address native frame as a 887 unicast TRILL Data packet rather than flooding 888 it, or 889 (1b) the IP address corresponding to the MAC address 890 so that RBridge can locally respond to a RARP 891 [RFC903] native frame. 892 (2) An IPv4 or IPv6 address with the querying RBridge 893 interested in the corresponding MAC address so it can 894 locally respond to an ARP [RFC826] or ND [RFC4861] 895 native frame [ARPND]. 896 But the query address could be some other address type 897 for which an AFN has been assigned, such as a 64-bit MAC 898 address [RFC7042] or a CLNS address [X.233]. 900 Query Frame: Where a QUERY Record is the result of an ARP, 901 ND, RARP, or unknown unicast MAC destination address, the 902 ingress TRILL switch MAY send the frame to a Pull 903 Directory Server if the frame is small enough that the 904 resulting Query Message fits into a TRILL Data packet 905 within the campus MTU. The full frame is included, 906 starting with the destination and source MAC addresses 907 but does not include the FCS. 909 If no response is received to a Pull Directory Query Message within a 910 configurable timeout (DirQueryTimeout, see Section 3.9), then the 911 Query Message should be re-transmitted with the same Sequence Number 912 (up to a configurable number of times (DirQueryRetries, see Section 913 3.9)). If there are multiple QUERY Records in a Query Message, 914 responses can be received to various subsets of these QUERY Records 915 before the timeout. In that case, the remaining unanswered QUERY 916 Records should be re-sent in a new Query Message with a new sequence 917 number. If a TRILL switch is not capable of handling partial 918 responses to queries with multiple QUERY Records, it MUST NOT send a 919 Request Message with more than one QUERY Record in it. 921 See Section 3.6 for a discussion of how Query Message errors are 922 handled. 924 3.2.2 Pull Directory Responses 926 A Pull Directory Query Message results in a Pull Directory Response 927 Message as described in Section 3.2.2.1. 929 In addition, if the QUERY Record QTYPE was 2 or 5, the frame included 930 in the Query may be modified and forwarded by the Pull Directory 931 server as described in Section 3.2.2.2. 933 3.2.2.1 Pull Directory Response Message Format 935 Pull Directory Response Messages are sent as the Channel Protocol 936 specific content of an RBridge Channel message [RFC7178] TRILL Data 937 packet or as a native RBridge Channel data frame (see Section 3.5). 938 Responses are sent with the same Data Label and priority as the Query 939 Message to which they correspond except that the Response Message 940 priority is limited to be not more than the configured value 941 DirRespMaxPriority (Section 3.9). 943 The RBridge Channel protocol specific data format is as follows: 945 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Ver | Type | Flags | Count | Err | SubErr | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Sequence Number | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | RESPONSE 1 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 954 | RESPONSE 2 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 956 | ... 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 958 | RESPONSE K 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 961 Ver, Sequence Number: As specified in Section 3.1. 963 Type: 2 = Response. 965 Flags: MUST be sent as zero and ignored on receipt. 967 Count: Count is the number of RESPONSE Records present in the 968 Response Message. 970 Err, SubErr: A two-part error code. Zero unless there was an error 971 in the Query Message, for which case see Section 3.6. 973 RESPONSE: Each RESPONSE Record within a Pull Directory Response 974 Message is formatted as follows: 976 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 977 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 978 | SIZE |OV| RESV | Index | 979 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 980 | Lifetime | 981 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 982 | Response Data ... 983 +--+--+--+--+--+--+--+--+--+--+--... 985 SIZE: The size of the RESPONSE Record is an unsigned integer 986 number of bytes not including the SIZE field and following 987 byte. A value of SIZE so large that the material doesn't fit 988 in the Query Message indicates a malformed QUERY Record. The 989 QUERY Record with such an excessive SIZE value and any 990 subsequent QUERY Records MUST be ignored and the entire 991 Query Message MAY be ignored. 993 OV: The overflow flag. Indicates, as described below, that 994 there was too much Response Data to include in one Response 995 Message. 997 RESV: Three reserved bits that MUST be sent as zero and ignored 998 on receipt. 1000 Index: The relative index of the QUERY Record in the Query 1001 Message to which this RESPONSE Record corresponds. The index 1002 will always be one for Query Messages containing a single 1003 QUERY Record. If the Index is larger than the Count was in 1004 the corresponding Query, that RESPONSE Record MUST be 1005 ignored and subsequent RESPONSE Records or the entire 1006 Response Message MAY be ignored. 1008 Lifetime: The length of time for which the response should be 1009 considered valid in units of 100 milliseconds except that 1010 the values zero and 2**16-1 are special. If zero, the 1011 response can only be used for the particular query from 1012 which it resulted and MUST NOT be cached. If 2**16-1, the 1013 response MAY be kept indefinitely but not after the Pull 1014 Directory server goes down or becomes unreachable. (The 1015 maximum definite time that can be expressed is a little over 1016 1.8 hours.) 1018 Response Data: There are three types of RESPONSE Records. 1019 - If the Err field of the enclosing Response Message has a 1020 message level error code in it, then the RESPONSE Records 1021 are omitted and Count will be zero. See Section 3.6 for 1022 additional information on errors. 1023 - If the Err field of the enclosing Response Message has a 1024 record level error code in it, then the RESPONSE Records 1025 are those in error as further described in Section 3.6. 1026 - If the Err field of the enclosing Response Message is 1027 zero, then the Response Data in each RESPONSE Record is 1028 formatted as the value part of an Interface Addresses 1029 APPsub-TLV [RFC7961]. The maximum size of such contents 1030 is 255 bytes in which case the RESPONSE Record SIZE field 1031 is 255. 1033 Multiple RESPONSE Records can appear in a Response Message with the 1034 same Index if an answer to the QUERY Record consists of multiple 1035 Interface Address APPsub-TLV values. This would be necessary if, for 1036 example, a MAC address within a Data Label appears to be reachable by 1037 multiple TRILL switches. However, all RESPONSE Records to any 1038 particular QUERY Record MUST occur in the same Response Message. If a 1039 Pull Directory holds more mappings for a queried address than will 1040 fit into one Response Message, it selects which to include by some 1041 method outside the scope of this document and sets the overflow flag 1042 (OV) in all of the RESPONSE Records responding to that query address. 1044 See Section 3.6 for a discussion of how errors are handled. 1046 3.2.2.2 Pull Directory Forwarding 1048 Query Messages with QTYPEs 2 and 5 are interpreted and handled as 1049 described below. In these cases, if the information implicitly sought 1050 is not in the directory and the FR flag in the query message was one, 1051 the provided frame is forwarded by the Pull Directory server as a 1052 multi-destination TRILL Data packet with the ingress nickname of the 1053 Pull Directory server (or proxy if it is hosted on an end station) in 1054 the TRILL header. If the FR flag is zero, the frame is not forwarded 1055 in this case. 1057 If there was no error in the handling of the enclosing Query Message, 1058 the Pull Directory server forwards the frame inside that QUERY 1059 Record, after modifying it in some cases, as described below: 1061 ARP: When QTYPE is 2, an ARP [RFC826] frame is included in the QUERY 1062 Record. The ar$op field MUST be ares_op$REQUEST and for the 1063 response described in 3.2.2.1, this is treated as a query for the 1064 target protocol address where the AFN of that address is given by 1065 ar$pro. (ARP field and value names with embedded dollar signs are 1066 specified in [RFC826].) If ar$op is not ares_op$REQUEST or the ARP 1067 is malformed or the query fails, an error is returned. Otherwise 1068 the ARP is modified into the appropriate ARP response that is then 1069 sent by the Pull Directory server as a TRILL Data packet. 1071 ND: When QTYPE is 3, an IPv6 Neighbor Discover (ND [RFC4861]) frame 1072 is included in the QUERY Record. Only Neighbor Solicitation ND 1073 frames (corresponding to an ARP query) are allowed. An error is 1074 returned for other ND frames or if the target address is not 1075 found. Otherwise an ND Neighbor Advertisement response is returned 1076 by the Pull Directory server as a TRILL Data packet. This QTYPE is 1077 not applicable to SEND [RFC3971] for which an error is returned. 1079 RARP: When QTYPE is 4, a RARP [RFC903] frame is included in the QUERY 1080 Record. If the ar$op field is ares_op$REQUEST, the frame is 1081 handled as an ARP as described above. Otherwise the ar$op field 1082 MUST be 'reverse request' and for the response described in 1083 3.2.2.1, this is treated as a query for the target hardware 1084 address where the AFN of that address is given by ar$hrd. (See 1085 [RFC826] for RARP fields.) If ar$op is not one of these values or 1086 the RARP is malformed or the query fails, an error is returned. 1087 Otherwise the RARP is modified into the appropriate RARP response 1088 that is then unicast by the Pull Directory server as a TRILL Data 1089 packet to the source hardware MAC address. 1091 MacDA: When QTYPE is 5, indicating a frame is provided in the QUERY 1092 Record whose destination MAC address TRILL switch attachment is 1093 unknown, the only requirement is that this MAC address must be 1094 unicast. If it is group addressed an error is returned. For the 1095 response described in 3.2.2.1, it is treated as a query for the 1096 MacDA. If the Pull Directory contains TRILL switch attachment 1097 information for the MAC address in the Data Label of the Query 1098 Message, it forwards the frame to that switch in a unicast TRILL 1099 Data packet. 1101 3.3 Cache Consistency 1103 Unless it sends all responses with a Lifetime of zero, a Pull 1104 Directory MUST take action, by sending Update Messages, to minimize 1105 the amount of time that a TRILL switch will continue to use stale 1106 information from that Pull Directory. The format of Update Messages 1107 and the Acknowledge Messages used to respond to Update Messages are 1108 given in Sections 3.3.1 and 3.3.2. 1110 A Pull Directory server MUST maintain one of three sets of records 1111 concerning possible cached data at clients of that server. These are 1112 numbered and listed below in order of increasing specificity: 1114 Method 1, Least Specific. An overall record per Data Label of when 1115 the last positive response data sent will expire and when the 1116 last negative response sent will expire; the records are 1117 retained until such expiration. 1118 Pro: Minimizes the record keeping burden on the Pull 1119 Directory server. 1120 Con: Increases the volume of and overhead due to spontaneous 1122 Update Messages and due to unnecessarily invalidating cached 1123 information. 1125 Method 2, Medium Specificity. For each unit of data (IA APPsub-TLV 1126 Address Set [RFC7961]) held by the server, record when the last 1127 response sent with that positive response data will expire. In 1128 addition, record each address about which a negative response 1129 was sent by the server and when the last such negative response 1130 will expire. Each such record of a positive or negative response 1131 is discarded upon expiration. 1132 Pro/Con: An intermediate level of detail in server record 1133 keeping and an intermediate volume of and overhead due to 1134 spontaneous Update Messages with some unnecessary invalidation 1135 of cached information. 1137 Method 3, Most Specific. For each unit of data held by the server 1138 (IA APPsub-TLV Address Set [RFC7961]) and each address about 1139 which a negative response was sent, a list of TRILL switches 1140 that were sent that data as a positive response or sent a 1141 negative response for the address, and the expected time to 1142 expiration for that data or address at each such TRILL switch, 1143 assuming the requester cached the response. Each list entry is 1144 retained until such expiration time. 1145 Pro: Minimizes spontaneous Update Messages sent to update 1146 pull client TRILL switch caches and minimizes unnecessary 1147 invalidation of cached information. 1148 Con: Increased record keeping burden on the Pull Directory 1149 server. 1151 RESPONSE Records sent with a zero lifetime are considered to have 1152 already expired and so do not need to be tracked. In all cases, there 1153 may still be brief periods of time when directory information has 1154 changed, but information a pull client has cached has not yet been 1155 updated or expunged. 1157 A Pull Directory server may have a limit as to how many TRILL 1158 switches for which it can maintain detailed expiry information by 1159 method 3 above or how many data units or addresses it can maintain 1160 expiry information for by method 2 or the like. If such limits are 1161 exceeded, it MUST transition to a lower numbered method but, in all 1162 cases, MUST support, at a minimum, method 1. 1164 When data at a Pull Directory is changed, deleted, or added and there 1165 may be unexpired stale information at a requesting TRILL switch, the 1166 Pull Directory MUST send an Update Message as discussed below. The 1167 sending of such an Update Message MAY be delayed by a configurable 1168 number of milliseconds (DirUpdateDelay, see Section 3.9) to await 1169 other possible changes that could be included in the same Update. 1171 1. If method 1, the least detailed method, is being followed, then 1172 when any Pull Directory information in a Data Label is changed 1173 or deleted and there are outstanding cached positive data 1174 response(s), an all-addresses flush positive data Update Message 1175 is flooded within that Data Label as an RBridge Channel Message. 1176 Similarly if data is added and there are outstanding cached 1177 negative responses, an all-addresses flush negative message is 1178 similarly flooded. The Count field is zero in an Update Message 1179 indicates "all-addresses". On receiving an all-addresses flooded 1180 flush positive Update from a Pull Directory server it has used, 1181 indicated by the F and P bits being one and the Count being 1182 zero, a TRILL switch discards the cached data responses it has 1183 for that Data Label. Similarly, on receiving an all addresses 1184 flush negative Update, indicated by the F and N bits being one 1185 and the Count being zero, it discards all cached negative 1186 replies for that Data Label. A combined flush positive and 1187 negative can be flooded by having all of the F, P, and N bits 1188 set to one resulting in the discard of all positive and negative 1189 cached information for the Data Label. 1191 2. If method 2 is being followed, then a TRILL switch floods 1192 address specific positive Update Messages when data that might 1193 be cached by a querying TRILL switch is changed or deleted and 1194 floods address specific negative Update Messages when such 1195 information is added to. Such messages are sent as RBridge 1196 Channel messages. The F bit will be one; however, the Count 1197 field will be non-zero and either the P or N bit, but not both, 1198 will be one. There are actually four possible message types 1199 that can be flooded: 1201 2.a If data that might still be cached is updated: 1202 An unsolicited Update Message is sent with the P flag 1203 set and the Err field zero. On receipt, the addresses in the 1204 RESPONSE Records are compared to the addresses for which the 1205 receiving TRILL switch is holding cached positive 1206 information from that server. If they match, the cached 1207 information is updated. 1209 2.b If data that might still be cached is deleted: 1210 An unsolicited Update Message is sent with the P flag 1211 set and the Err field non-zero giving the error that would 1212 now be encountered in attempting to pull information for the 1213 relevant address from the Pull Directory server. In this 1214 non-zero Err field case, the RESPONSE Record(s) differ from 1215 non-zero Err Reply Message RESPONSE Records in that they do 1216 include an interface address set. Any cached positive 1217 information for the addresses given is deleted and the 1218 negative response is cached as per the lifetime given. 1220 2.c If data for an address for which a negative response was 1221 sent is added, so that negative response that might still be 1222 cached is now incorrect: 1223 An unsolicited Update Message is sent with the N flag 1224 set to one and the Err field zero. The addresses in the 1225 RESPONSE Records are compared to the addresses for which the 1226 receiving TRILL switch is holding cached negative 1227 information from that server; if they match, the cached 1228 negative information is deleted and the positive information 1229 provided is cached as per the lifetime given. 1231 2.d In the rare case where it is desired to change the lifetime 1232 or error associated with negative information that might 1233 still be cached: 1234 An unsolicited Update Message is sent with the N flag 1235 set to one and the Err field non-zero. As in case 2.b above, 1236 the RESPONSE Record(s) give the relevant addresses. Any 1237 cached negative information for the address is updated. 1239 3. If method 3 is being followed, the same sort of unsolicited 1240 Update Messages are sent as with method 2 above except they are 1241 not normally flooded but unicast only to the specific TRILL 1242 switches the directory server believes may be holding the cached 1243 positive or negative information that needs deletion or 1244 updating. However, a Pull Directory server MAY flood unsolicited 1245 updates under method 3, for example if it determines that a 1246 sufficiently large fraction of the TRILL switches in some Data 1247 Label are requesters that need to be updated so that flooding is 1248 more efficient that unicast. 1250 A Pull Directory server tracking cached information with method 3 1251 MUST NOT clear the indication that it needs to update cached 1252 information at a querying TRILL switch until it has either (a) sent 1253 an Update Message and received a corresponding Acknowledge Message or 1254 (b) it has sent a configurable number of updates at a configurable 1255 interval that default to 3 updates 100 milliseconds apart (see 1256 Section 3.9). 1258 A Pull Directory server tracking cached information with methods 2 or 1259 1 SHOULD NOT clear the indication that it needs to update cached 1260 information until it has sent an Update Message and received a 1261 corresponding Acknowledge Message from all of its ESADI xxx??? 1262 neighbors or it has sent a number of updates at an interval as in the 1263 paragraph above. 1265 3.3.1 Update Message Format 1267 An Update Message is formatted as a Response Message with the 1268 differences described in Section 3.3 above and the following: 1270 o The Type field in the message header is set to 3. 1271 o The Index field in the RESPONSE Record(s) is set to zero on 1272 transmission and ignored on receipt (but the Count field in the 1273 Update Message header MUST still correctly indicate the number of 1274 RESPONSE Records present). 1275 o The priority with which the message is sent, DirUpdatePriority, is 1276 configurable and defaults to 5 (see Section 3.9). 1278 Update Messages are initiated by a Pull Directory server. The 1279 Sequence number space used is controlled by the originating Pull 1280 Directory server. This update Sequence number space is different from 1281 the Sequence number space used in a Query and the corresponding 1282 Response that are controlled by the querying TRILL switch. 1284 The 4-bit Flags field of the message header for an Update Message is 1285 as follows: 1287 +---+---+---+---+ 1288 | F | P | N | R | 1289 +---+---+---+---+ 1291 F: The Flood bit. If zero, the Update Message is unicast. If F=1, it 1292 is multicast to All-Egress-RBridges. 1294 P, N: Flags used to indicate positive or negative Update Messages. 1295 P=1 indicates positive. N=1 indicates negative. Both may be 1 for 1296 a flooded all addresses Update. 1298 R: Reserved. MUST be sent as zero and ignored on receipt 1300 For tracking methods 2 and 3 in Section 3.3.1, a particular Update 1301 Message must have either the P flag or the N flag set but not both. 1302 If both are set, the Update Message MUST be ignored as this 1303 combination is only valid for method 1. 1305 3.3.2 Acknowledge Message Format 1307 An Acknowledge Message is sent in response to an Update Message to 1308 confirm receipt or indicate an error, unless response is inhibited by 1309 rate limiting. It is formatted as a Response Message but the Type is 1310 set to 4. 1312 If there are no errors in the processing of an Update Message or if 1313 there is a message level overall or header error in an Update 1314 Message, the message is echoed back with the Err and SubErr fields 1315 set appropiately, the Type changed to Acknowledge, and a null records 1316 section with the Count field set to zero. 1318 If there is a record level error in an Update Message, one or more 1319 Acknowledge Messages may be returned with the erroneous record(s) 1320 indicated as discussed in Section 3.6. 1322 The Acknowledge Messages is sent with the same priority as the Update 1323 Message it acknowledges but not more than a configured priority 1324 (DirAckMaxPriority) that defaults to 5 (see Section 3.9). 1326 3.4 Summary of Records Formats in Messages 1328 As specified in Section 3.2 and 3.3, the Query, Response, Update, and 1329 Acknowledge Messages can have zero or more repeating Record 1330 structures under different circumstances, as summarized below. The 1331 "Err" column abbreviations in this table have the meanings listed 1332 below. "IA APPsub-TLV value" means the value part of the IA APPsub- 1333 TLV specified in [RFC7961]. 1335 MBZ = MUST be zero 1336 Z = zero 1337 NZ = non-zero 1338 NZM = non-zero message level error 1339 NZR = non-zero record level error 1341 Message Err Section Record Structure Response Data 1342 ----------- --- ------- ---------------- ------------------ 1343 Query MBZ 3.2.1 QUERY Record - 1344 Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value 1345 Response NZM 3.2.2.1 null - 1346 Response NZR 3.2.2.1 RESPONSE Record Records with error 1347 Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value 1348 Acknowledge Z 3.3.2 null - 1349 Acknowledge NZM 3.3.2 null - 1350 Acknowledge NZR 3.3.2 RESPONSE Record Records with error 1352 See Section 3.6 for further details on errors. 1354 3.5 End Stations and Pull Directories 1356 A Pull Directory can be hosted on an end station as specified in 1357 Section 3.5.1. 1359 A end station can use a Pull Directory as specified in Section 3.5.2. 1360 This capability would be useful in supporting an end station that 1361 performs directory assisted encapsulation [DirAsstEncap] or that is a 1362 "smart end node" [SmartEN]. 1364 The native Pull Directory messages used in these cases are as 1365 specified in Section 3.5.3. In these cases, the edge RBridge(s) and 1366 end station(s) involved need to detect each other and exchange some 1367 control information. This is accomplished with the TRILL ES-IS 1368 mechanism specified in Section 5. 1370 3.5.1 Pull Directory Hosted on an End Station 1372 Optionally, a Pull Directory actually hosted on an end station MAY be 1373 supported. In that case, one or more TRILL switches must act as 1374 indirect Pull Directory servers. That is, they host a Pull Directory 1375 server, which is seen by other TRILL switches in the campus, and a 1376 Pull Directory client, which fetches directory information from one 1377 or more End Station Pull Directory servers, where at least some of 1378 the information served up by the Pull Directory server may be 1379 information fetched from an end station by the co-located Pull 1380 Directory client. Such a TRILL switch hosting an indirect Pull 1381 Directory server must have a direct connection to the end station, 1382 that is a connection not involving any intermediate TRILL switches. 1384 End stations hosting a Pull Directory server MUST support TRILL ES-IS 1385 (see Section 5) and advertise the Data Labels for which they are 1386 providing service in one or more Interested VLAN or Interested Label 1387 sub-TLVs by setting the PUL flag (see Section 7.3). 1389 * * * * * * * 1390 +---------------+ * * 1391 | End Station 1 | +---------------+ * 1392 | Pull Directory+--------------+ RB1, Pull | * 1393 | Server | | Directory| * 1394 +---------------+ +-------+ Client|Server | +----+ 1395 | +---------------+ |RB99| 1396 +---------------+ | * +----+ 1397 | End Station 2 | +--+---+ +---------------+ * 1398 | Pull Directory+---+Bridge+---+ RB2, Pull | * 1399 | Server | +--+---+ | Directory| * 1400 +---------------+ | | Client|Server | * 1401 | +---------------+ * 1402 | * TRILL * 1403 . * Campus * 1404 . * * 1405 . * * * * * * * 1407 Figure 2. End Station Pull Directory Example 1409 The figure above gives an example where RB1 and RB2 advertise 1410 themselves to the rest of the TRILL campus, such as RB99, as Pull 1411 Directory servers and obtain at least some of the information they 1412 are serving up by issuing Pull Directory queries to end stations 1 1413 and/or 2. This example is specific but many variations are possible. 1414 The Bridge shown might be a complex bridged LAN or might be absent 1415 if, as shown for End Station 1, End Station 2 was dual ported with 1416 point-to-point Ethernet links to RB1 and RB2. There could be one or 1417 more than two RBridges having such indirect Pull Directory servers. 1418 Furthermore, there could be one or more than two end stations with 1419 Pull Directory servers on them. Each TRILL switch server could then 1420 be differently configured as to the Data Labels for which it is 1421 providing indirect service selected from the union of the Data Labels 1422 supported by the End Station hosted servers and could select from 1423 among those End Station hosted servers supporting each Data Label the 1424 indirect server is configured to serve up. 1426 When an indirect Pull Directory server receives a Query Message from 1427 another TRILL switch, it answers from information it has cached or 1428 issues Pull Directory request to End Station Pull Directory servers 1429 with which it has TRILL ES-IS adjacency to obtain the information. 1430 Any Response sent by an indirect Pull Directory server MUST NOT have 1431 a validity time longer that the valid of the data on which it is 1432 based. When an indirect Pull Directory server receives Update 1433 Messages, it updates its cached information and MUST originate Update 1434 messages to any clients that may have mirrors of the cached 1435 information so updated. 1437 Because an indirect Pull Directory server discards information it has 1438 cached from queries to an end station Pull Directory server if it 1439 loses adjacency to that server (Section 3.7), if it knowns that such 1440 information may be cached at RBridge clients and has no other source 1441 for the information, it MUST send Update Messages to those clients 1442 withdrawing the information. For this reason, indirect Pull Directory 1443 servers may wish to query multiple sources, if available, and cache 1444 multiple copies of returned information from those multiple sources. 1445 Then if one end station source becomes inaccessible or withdraws the 1446 information but the indirect Pull Directory server has the 1447 information from another source, it need not originate Updates. 1449 3.5.2 Pull Directory Use by End Stations 1451 Some special end stations, such as those discussed in [DirAsstEncap] 1452 and [SmartEN], may need to access directory information. How edge 1453 RBridges provide this optional service is specified below. 1455 When Pull Directory support is provided by an edge RBridge to end 1456 stations, the messages used are as specified in Section 3.5.3 below. 1457 The edge RBridge MUST support TRILL ES-IS (Section 5) and advertises 1458 the Data Labels for which it offers this service to end stations by 1459 setting the Pull Directory flag (PUL) to one in its Interested VLANs 1460 or Interested Labels sub-TLV (see Section 7.3) for that Data Label 1461 advertised through TRILL ES-IS. 1463 3.5.3 Native Pull Directory Messages 1465 The Pull Directory messages used between TRILL switches and end 1466 stations are native RBridge Channel messages [RFC7178]. These 1467 RBridge Channel messages use the same Channel protocol number as the 1468 inter-RBridge Pull Directory RBridge Channel messages. The Outer.VLAN 1469 ID used is the TRILL ES-IS Designated VLAN (see Section 5) on the 1470 link to the end station. Since there is no TRILL Header or inner Data 1471 Label for native RBridge Chanel messages, that information is added 1472 to the Pull Directory message header as specified below. 1474 The native RBridge Channel message Pull Directory message protocol 1475 dependent data part is the same as for inter-RBridge Channel messages 1476 except that the 8-byte header described in Section 3.1 is expanded to 1477 12 or 16 bytes as follows: 1479 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1480 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 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 | Ver | Type | Flags | Count | Err | SubErr | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Sequence Number | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Data Label ... (4 or 8 bytes) | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1488 | Type Specific Payload - variable length 1489 +-+-+- ... 1491 Fields other than Data Label are as in Section 3.1. The Data Label 1492 that normally appears right after the Inner.MacSA of the an RBridge 1493 Channel Pull Directory message appears in the Data Label field of 1494 the Pull Directory message header in the native RBridge Channel 1495 message version. This Data Label appears in a native Query Message, 1496 to be reflected in a Response Message, or it might appear in a native 1497 Update to be reflected in an Acknowledge Message. Since the 1498 appropriate VLAN or FGL [RFC7172] Ethertype is included, the length 1499 of the Data Label can be determined from the first two bytes. 1501 3.6 Pull Directory Message Errors 1503 A non-zero Err field in the Pull Directory Response or Acknowledge 1504 Message header indicates an error message. 1506 If there is an error that applies to an entire Query or Update 1507 Message or its header, as indicated by the range of the value of the 1508 Err field, then the QUERY Records probably were not even looked at by 1509 the Pull Directory Server and would provide no additional information 1510 in the Response or Acknowledge Message. Therefore, the Records 1511 section of the Query Response or Update Message is omitted and the 1512 Count field is set to zero in the Response or Acknowledgement 1513 Message. 1515 If errors occur at the QUERY Record level for a Query Message, they 1516 MUST be reported in a Response Message separate from the results of 1517 any successful non-erroneous QUERY Records. If multiple QUERY Records 1518 in a Query Message have different errors, they MUST be reported in 1519 separate Response Messages. If multiple QUERY Records in a Query 1520 Message have the same error, this error response MAY be reported in 1521 one or multiple Response Messages. In an error Response Message, the 1522 QUERY Record or Records being responded to appear, expanded by the 1523 Lifetime for which the server thinks the error might persist (usually 1524 2**16-1 which indicates indefinitely) and with their Index inserted, 1525 as the RESPONSE Record or Records. 1527 If errors occur at the RESPONSE Record level for an Update Message, 1528 they MUST be reported in an Acknowledge Message separate from the 1529 acknowledgement of any non-erroneous RESPONSE Records. If multiple 1530 RESPONSE Records in an Update have different errors, they MUST be 1531 reported in separate Acknowledge Messages. If multiple RESPONSE 1532 Records in an Update Message have the same error, this error response 1533 MAY be reported in one or multiple Acknowledge Messages. In an error 1534 Acknowledge Message, the RESPONSE Record or Records being responded 1535 to appear, expanded by the time for which the server thinks the error 1536 might persist and with their Index inserted, as a RESPONSE Record or 1537 Records. 1539 Err values 1 through 126 are available for encoding Request or Update 1540 Message level errors. Err values 128 through 254 are available for 1541 encoding QUERY or RESPONSE Record level errors. The SubErr field is 1542 available for providing more detail on errors. The meaning of a 1543 SubErr field value depends on the value of the Err field. 1545 3.6.1 Error Codes 1547 The following table lists error code values for the Err field, their 1548 meaning, and whether they apply at the Message or Record level. 1550 Err Level Meaning 1551 ------ ------- ------- 1552 0 - No Error 1554 1 Message Unknown or reserved Query Message field value 1555 2 Message Request Message/data too short 1556 3 Message Unknown or reserved Update Message field value 1557 4 Message Update Message/data too short 1558 5-126 Message Unassigned 1559 127 - Reserved 1561 128 Record Unknown or reserved QUERY Record field value 1562 129 Record QUERY Record truncated 1563 130 Record Address not found 1564 131 Record Unknown or reserved RESPONSE Record field value 1565 132 Record RESPONSE Record truncated 1566 133-254 Record Unassigned 1567 255 - Reserved 1569 Note that some error codes are for overall message level errors while 1570 some are for errors in the repeating records that occur in messages. 1572 3.6.2 Sub-Errors Under Error Codes 1 and 3 1574 The following sub-errors are specified under error codes 1 and 3: 1576 SubErr Field with Error 1577 ------ ---------------- 1578 0 Unspecified 1579 1 Unknown Ver field value 1580 2 Unknown Type field value 1581 3 Specified Data Label not being served 1582 4-254 Unassigned 1583 255 Reserved 1585 3.6.3 Sub-Errors Under Error Codes 128 and 131 1587 The following sub-errors are specified under error code 128 and 131: 1589 SubErr Field with Error 1590 ------ ---------------- 1591 0 Unspecified 1592 1 Unknown AFN field value 1593 2 Unknown or Reserved QTYPE field value 1594 3 Invalid or inconsistent SIZE field value 1595 4 Invalid frame for QTYPE 2, 3, 4, or 5 1596 5-254 Unassigned 1597 255 Reserved 1599 3.7 Additional Pull Details 1601 If a Pull Directory client notices that a Pull Directory server is no 1602 longer accessible (data reachable [RFC7780] for the inter-RBridge 1603 case or TRILL ES-IS (Section 5) adjacent for end station to RBridge 1604 case), it MUST promptly discard all pull responses it is retaining 1605 from that server as it can no longer receive cache consistency Update 1606 Messages from the server. 1608 A secondary Pull Directory server is one that obtains its data from a 1609 primary directory server. See discussion of primary to secondary 1610 directory information transfer in Section 2.5. 1612 3.8 The No Data Flag 1614 In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], 1615 the mere presence of an Interested VLANs or Interested Labels sub- 1616 TLVs in the LSP of a TRILL switch indicates connection to end 1617 stations in the VLAN(s) or FGL(s) listed and thus a need to receive 1618 multi-destination traffic in those Data Labels. However, with Pull 1619 Directories, advertising that you are a directory server requires 1620 using these sub-TLVs to indicate the Data Label(s) you are serving. 1622 If a directory server does not wish to received multi-destination 1623 TRILL Data packets for the Data Labels it lists in one of the 1624 Interested VLAN or Interested FGL [RFC7172] sub-TLVs, it sets the "No 1625 Data" (NOD) bit to one (see Section 7.3). This means that data on a 1626 distribution tree may be pruned so as not to reach the "No Data" 1627 TRILL switch as long as there are no TRILL switches interested in the 1628 Data Label that are beyond the "No Data" TRILL switch on that 1629 distribution tree. The NOD bit is backwards compatible as TRILL 1630 switches ignorant of it will simply not prune when they could, which 1631 is safe although it may cause increased link utilization by some 1632 sending multi-destination traffic where it is not needed. 1634 Push Directories advertise themselves inside ESADI which normally 1635 requires the ability to send and receive multi-destination TRILL Data 1636 packets but can be implemented with serial unicast. 1638 Example of a TRILL switch serving as a directory that might not want 1639 multi-destination traffic in some Data Labels would be a TRILL switch 1640 that does not offer end station service for any of the Data Labels 1641 for which it is serving as a directory and is either 1642 - a Pull Directory and/or 1643 - a Push Directory for one or more Data Labels where all of the 1644 ESADI traffic for those Data Labels will be handled by unicast 1645 ESADI [RFC7357]. 1647 A Push Directory MUST NOT set the NOD bit for a Data Label if it 1648 needs to communicate via multi-destination ESADI PDUs in that Data 1649 Label since such PDUs look like TRILL Data packets to transit TRILL 1650 switches and are likely to be incorrectly pruned if NOD was set. 1652 3.9 Pull Directory Service Configuration 1654 The following per RBridge scalar configuration parameters are 1655 available for controlling Pull Directory service behavior. In 1656 addition, there is a configurable per Data Label mapping from the 1657 priority of a native frame being ingress to the priority of any Pull 1658 Directory query it causes. The default such mapping depends on the 1659 client strategy as described in Section 4. 1661 Name Default Section Note Below 1662 ------------------ ------- ------- ---------- 1664 DirQueryTimeout 100 millisec 3.2.1 1 1665 DirQueryRetries 3 3.2.1 1 1666 DirGenQPriority 5 3.2.1 2 1668 DirRespMaxPriority 6 3.2.2.1 3 1670 DirUpdateDelay 50 millisec 3.3 1671 DirUpdatePriority 5 3.3.1 1672 DirUpdateTimeout 100 millisec 3.3.3 1673 DirUpdateRetries 3 3.3.3 1675 DirAckMaxPriority 5 3.3.2 4 1677 Note 1: Pull Directory Query client timeout waiting for response and 1678 maximum number of retries 1680 Note 2: Priority for client generated requests (such as a query to 1681 refresh cached information). 1683 Note 3: Pull Directory Response Messages SHOULD NOT be sent with 1684 priority 7 as that priority SHOULD be reserved for messages critical 1685 to network connectivity. 1687 Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent with 1688 priority 7 as that priority SHOULD be reserved for messages critical 1689 to network connectivity. 1691 4. Directory Use Strategies and Push-Pull Hybrids 1693 For some edge nodes that have a great number of Data Labels enabled, 1694 managing the MAC and Data Label <-> Edge RBridge mapping for hosts 1695 under all those Data Labels can be a challenge. This is especially 1696 true for Data Center gateway nodes, which need to communicate with 1697 many, if not all, Data Labels. 1699 For those edge TRILL switch nodes, a hybrid model should be 1700 considered. That is, the Push Model is used for some Data Labels or 1701 addresses within a Data Label while the Pull Model is used for other 1702 Data Labels or addresses within a Data Label. It is the network 1703 operator's decision by configuration as to which Data Labels' mapping 1704 entries are pushed down from directories and which Data Labels' 1705 mapping entries are pulled. 1707 For example, assume a data center where hosts in specific Data 1708 Labels, say VLANs 1 through 100, communicate regularly with external 1709 peers. Probably, the mapping entries for those 100 VLANs should be 1710 pushed down to the data center gateway routers. For hosts in other 1711 Data Labels that only communicate with external peers occasionally 1712 for management interfacing, the mapping entries for those VLANs 1713 should be pulled down from directory when the need comes up. 1715 Similarly, it could be that within a Data Label that some addresses, 1716 such as the addresses of gateways, file, DNS, or database server 1717 hosts are commonly referenced by most other hosts but those other 1718 hosts, perhaps compute engines, are typically only referenced by a 1719 few hosts in that Data Label. In that case, the address information 1720 for the commonly referenced hosts could be pushed as an incomplete 1721 directory while the addresses of the others are pulled when needed. 1723 The mechanisms described in this document for Push and Pull Directory 1724 services make it easy to use Push for some Data Labels or addresses 1725 and Pull for others. In fact, different TRILL switches can even be 1726 configured so that some use Push Directory services and some use Pull 1727 Directory services for the same Data Label if both Push and Pull 1728 Directory services are available for that Data Label. And there can 1729 be Data Labels for which directory services are not used at all. 1731 There are a wide variety of strategies that a TRILL switch can adopt 1732 for making use of directory assistance. A few suggestions are given 1733 below. 1735 - Even if a TRILL switch will normally be operating with 1736 information from a complete Push Directory server, there will be a 1737 period of time when it first comes up before the information it 1738 holds is complete. Or, it could be that the only Push Directories 1739 that can push information to it are incomplete or that they are 1740 just starting and may not yet have pushed the entire directory. 1742 Thus, it is RECOMMENDED that all TRILL switches have a strategy 1743 for dealing with the situation where they do not have complete 1744 directory information. Examples are to send a Pull Directory query 1745 or to revert to [RFC6325] behavior. 1747 - If a TRILL switch receives a native frame X resulting in 1748 seeking directory information, a choice needs to be made as to 1749 what to do if it does not already have the directory information 1750 it needs. In particular, it could (1) immediately flood the TRILL 1751 Data packet resulting from ingressing X in parallel with seeking 1752 the directory information, (2) flood that TRILL Data packet after 1753 a delay, if it fails to obtain the directory information, or (3) 1754 discard X if it fails to obtain the information. The choice might 1755 depend on the priority of frame X since the higher that priority 1756 typically the more urgent the frame is and the greater the 1757 probability of harm in delaying it. If a Pull Directory request is 1758 sent, it is RECOMMENDED that its priority be derived from the 1759 priority of the frame X with the derived priority configurable and 1760 having the following defaults: 1762 Ingressed If Flooded If Flooded 1763 Priority Immediately After Delay 1764 -------- ----------- ----------- 1765 7 5 6 1766 6 5 6 1767 5 4 5 1768 4 3 4 1769 3 2 3 1770 2 0 2 1771 0 1 0 1772 1 1 1 1774 NOTE: The odd looking numbers towards the bottom of the columns 1775 above are because priority 1 is lower than priority zero. That is 1776 to say, the values in the first column are in priority order. They 1777 will look more logical if you think of "0" as being "1 1/2". 1779 Priority 7 is normally only used for urgent messages critical to 1780 adjacency and so SHOULD NOT be the default for directory traffic. 1781 Unsolicited updates are sent with a priority that is configured per 1782 Data Label that defaults to priority 5. 1784 5. TRILL ES-IS 1786 TRILL ES-IS (End System to Intermediate System) is a variation of 1787 TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a 1788 TRILL link among and between one or more TRILL switches and any end 1789 stations on that link. TRILL ES-IS is useful in supporting Pull 1790 Directory hosting on or use from end stations (see Section 3.5) and 1791 supporting specialized end stations [DirAsstEncap] [SmartEN] and may 1792 have additional future uses. The advantages of TRILL ES-IS over 1793 simply making an "end station" be a TRILL Switch include relieving 1794 the end station of having to maintain a copy of the core link state 1795 database (LSPs) and of having to perform routing calculations or 1796 having the ability to forward traffic. 1798 Support of TRILL ES-IS is generally optional for both the TRILL 1799 switches and the end stations on a link but may be required to 1800 support certain features. 1802 Except as provided in this Section 5, TRILL ES-IS PDUs and TLVs are 1803 the same TRILL IS-IS PDUs and TLVs. 1805 5.1 PDUs and System IDs 1807 All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs which 1808 may be unicast) are multicast using the TRILL-ES-IS multicast MAC 1809 address (see Section 7.6). This use of a different multicast address 1810 assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused 1811 for one another. 1813 Because end stations do not have IS-IS System IDs, TRILL ES-IS uses 1814 port MAC addresses in their place. This is convenient since MAC 1815 addresses are 48-bit and almost all IS-IS implementations use 48-bit 1816 System IDs. Logically TRILL IS-IS operates between the TRILL switches 1817 in a TRILL campus as identified by System ID while TRILL ES-IS 1818 operates between Ethernet ports on an Ethernet link (which may be a 1819 bridged LAN) as identified by MAC address [RFC6325]. 1821 As System IDs of TRILL Switches in a campus are required to be 1822 unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be 1823 unique. 1825 5.2 Adjacency, DRB Election, Hellos, TLVs, Etc. 1827 TRILL ES-IS Adjacency formation and DRB election operate between the 1828 ports on the link as specified in [RFC7177] for a broadcast link. 1829 The DRB specifies an ES-IS Designated VLAN for the link. This 1830 adjacency determination, DRB election, and Designated VLAM are 1831 distinct from TRILL IS-IS adjacency, DRB election, and Designated 1832 VLAN. 1834 Although the "Report State" [RFC7177] exists for TRILL ES-IS 1835 adjacencies, such adjacencies are not reported in any LSPs. 1837 End stations supporting TRILL ES-IS MUST assign a unique Port ID to 1838 each of their TRILL ES-IS ports. 1840 TRILL ES-IS has nothing to do with Appointed Forwarders and the 1841 Appointed Forwarders sub-TLV and VLANs Appointed sub-TLV [RFC7176] 1842 are not used in TRILL ES-IS. (The Appointed Forwarders on a link are 1843 determined as specified in [RFC6439] using TRILL IS-IS.) 1845 Although some of the ports sending TRILL ES-IS PDUs are on end 1846 stations and thus not on routers (TRILL switches), they nevertheless 1847 may make use of the Router Capability (#242) and MT-Capability (#222) 1848 IS-IS TLVs to indicate capabilities as elsewhere specified. 1850 TRILL ES-IS Hellos are like TRILL IS-IS Hellos but note the 1851 following: In the Special VLANs and Flags Sub-TLV, any TRILL switches 1852 advertise a nickname they own but for end stations that field MUST be 1853 sent as zero and ignored on receipt. In addition, the AF and TR flag 1854 bits MUST be sent as zero and the AC flag bit MUST be sent as one and 1855 all three are ignored on receipt. 1857 5.3 Link State 1859 The only link state transmission and synchronization that occurs in 1860 TRILL ES-IS is for E-L1CS PDUs (Extended Level 1 Circuit Scoped 1861 [RFC7356]). In particular, the end station Ethernet ports supporting 1862 TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not 1863 support E-L1FS LSPs (or the CSNPs or PSNPs corresponding to either of 1864 them). 1866 6. Security Considerations 1868 Incorrect directory information can result in a variety of security 1869 threats including the following: 1871 Incorrect directory mappings can result in data being delivered to 1872 the wrong end stations, or set of end stations in the case of 1873 multi-destination packets, violating security policy. 1875 Missing or incorrect directory data can result in denial of 1876 service due to sending data packets to black holes or discarding 1877 data on ingress due to incorrect information that their 1878 destinations are not reachable or that their source addresses are 1879 forged. 1881 Push Directory data is distributed through ESADI-LSPs [RFC7357] that 1882 can be authenticated with the same mechanisms as IS-IS LSPs. See 1883 [RFC5304] [RFC5310] and the Security Considerations section of 1884 [RFC7357]. 1886 Pull Directory queries and responses are transmitted as RBridge-to- 1887 RBridge or native RBridge Channel messages [RFC7178]. Such messages 1888 can be secured as specified in [RFC7978]. 1890 For general TRILL security considerations, see [RFC6325]. 1892 7. IANA Considerations 1894 This section gives IANA assignment and registry considerations. 1896 7.1 ESADI-Parameter Data Extensions 1898 Action 1: IANA will assign a two bit field [bits 1-2 suggested] 1899 within the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory 1900 Server Status" (PDSS) and will create a sub-registry in the TRILL 1901 Parameters Registry as follows: 1903 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 1904 Registration Procedures: Standards Action 1905 References: [RFC7357] [This document] 1907 Bit Mnemonic Description Reference 1908 --- -------- ----------- --------- 1909 0 UN Supports Unicast ESADI ESDADI [RFC7357] 1910 1-2 PDSS Push Directory Server Status [this document] 1911 3-7 - Available for assignment 1913 Action 2: In addition, the ESADI-Parameter APPsub-TLV is optionally 1914 extended, as provided in its original specification in ESADI 1915 [RFC7357], by one byte as show below. Therefore [this document] 1916 should be added as a second reference to the ESDAI-Parameter APPsub- 1917 TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 1918 Identifier 1" Registry. 1920 +-+-+-+-+-+-+-+-+ 1921 | Type | (1 byte) 1922 +-+-+-+-+-+-+-+-+ 1923 | Length | (1 byte) 1924 +-+-+-+-+-+-+-+-+ 1925 |R| Priority | (1 byte) 1926 +-+-+-+-+-+-+-+-+ 1927 | CSNP Time | (1 byte) 1928 +-+-+-+-+-+-+-+-+ 1929 | Flags | (1 byte) 1930 +---------------+ 1931 |PushDirPriority| (optional, 1 byte) 1932 +---------------+ 1933 | Reserved for expansion (variable) 1934 +-+-+-+-... 1936 The meanings of all the fields are as specified in ESDADI [RFC7357] 1937 except that the added PushDirPriority is the priority of the 1938 advertising ESADI instance to be a Push Directory as described in 1939 Section 2.3. If the PushDirPriority field is not present (Length = 3) 1940 it is treated as if it were 0x40. 0x40 is also the value used and 1941 placed here by an TRILL switch whose priority to be a Push Directory 1942 has not been configured. 1944 7.2 RBridge Channel Protocol Numbers 1946 Action 3: IANA is requested to assign a new RBridge Channel protocol 1947 number from the range assignable by Standards Action and update the 1948 subregistry of such protocol number in the TRILL Parameters Registry. 1949 Description is "Pull Directory Services". Reference is [this 1950 document]. 1952 7.3 The Pull Directory (PUL) and No Data (NOD) Bits 1954 Action 4: IANA is requested to assign a currently reserved bit in the 1955 Interested VLANs field of the Interested VLANs sub-TLV [suggested bit 1956 18] and the Interested Labels field of the Interested Labels sub-TLV 1957 [suggested bit 6] [RFC7176] to indicate Pull Directory server (PUL). 1958 This bit is to be added, with this document as reference, to the 1959 "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" 1960 subregistries created by [RFC7357]. 1962 Actions 5 and 6: IANA is requested to assign a currently reserved bit 1963 in the Interested VLANs field of the Interested VLANs sub-TLV 1964 [suggested bits 19] and the Interested Labels field of the Interested 1965 Labels sub-TLV [suggested bits 7] [RFC7176] to indicate No Data (NOD, 1966 see Section 3.8). This bit is to be added, with this document as 1967 reference, to the "Interested VLANs Flag Bits" and "Interested Labels 1968 Flag Bits" subregistries created by [RFC7357]. 1970 7.4 TRILL Pull Directory QTYPEs 1972 Action 7: IANA is requested to create a new Registry on the 1973 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 1974 page as follows: 1976 Name: TRILL Pull Directory QTYPEs 1977 Registration Procedure: IETF Review 1978 Reference: [this document] 1979 Initial contents as in Section 3.2.1. 1981 7.5 Pull Directory Error Code Registries 1983 Actions 8, 9, and 10: IANA is requested to create a new Registry and 1984 two new indented SubRegistries under that Registry on the 1985 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 1986 page as follows: 1988 Registry 1989 Name: TRILL Pull Directory Errors 1990 Registration Procedure: IETF Review 1991 Reference: [this document] 1993 Initial contents as in Section 3.6.1. 1995 Sub-Registry 1996 Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 1997 Registration Procedure: Expert Review 1998 Reference: [this document] 2000 Initial contents as in Section 3.6.2. 2002 Sub-Registry 2003 Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 2004 Registration Procedure: Expert Review 2005 Reference: [this document] 2007 Initial contents as in Section 3.6.3. 2009 7.6 TRILL-ES-IS MAC Address 2011 Action 11: IANA is requested to assign a TRILL multicast MAC address 2012 from the "TRILL Multicast Addresses" registry on the TRILL Parameters 2013 IANA web page [value 01-80-C2-00-00-47 recommended]. Description is 2014 "TRILL-ES-IS". Reference is [this document]. 2016 Normative References 2018 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 2019 RFC 826, November 1982. 2021 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 2022 Reverse Address Resolution Protocol", STD 38, RFC 903, June 2023 1984 2025 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 2026 Requirement Levels", BCP 14, RFC 2119, March 1997 2028 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2029 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 2031 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2032 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2033 September 2007. 2035 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 2036 Authentication", RFC 5304, October 2008. 2038 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 2039 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 2040 5310, February 2009. 2042 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 2043 Layer-2 Systems", RFC 6165, April 2011. 2045 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 2046 Ghanwani, "Routing Bridges (RBridges): Base Protocol 2047 Specification", RFC 6325, July 2011. 2049 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 2050 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 2051 6439, DOI 10.17487/RFC6439, November 2011, . 2054 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 2055 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 2056 BCP 141, RFC 7042, October 2013. 2058 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 2059 and D. Dutt, "Transparent Interconnection of Lots of Links 2060 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 2061 . 2063 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 2064 D., and A. Banerjee, "Transparent Interconnection of Lots of 2065 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 2066 . 2068 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 2069 and V. Manral, "Transparent Interconnection of Lots of Links 2070 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 2071 . 2073 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 2074 Ward, "Transparent Interconnection of Lots of Links (TRILL): 2075 RBridge Channel Support", RFC 7178, May 2014, . 2078 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 2079 Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, 2080 September 2014, . 2082 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 2083 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 2084 End Station Address Distribution Information (ESADI) Protocol", 2085 RFC 7357, September 2014, . 2088 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 2089 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 2090 Lots of Links (TRILL): Clarifications, Corrections, and 2091 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 2092 . 2094 [RFC7961] - Eastlake 3rd, D. and L. Yizhou, "Transparent 2095 Interconnection of Lots of Links (TRILL): Interface Addresses 2096 APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016, 2097 . 2099 Informational References 2101 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 2102 Gashinsky, "Directory Assistance Problem and High-Level Design 2103 Proposal", RFC 7067, November 2013. 2105 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 2106 Interconnection of Lots of Links (TRILL): RBridge Channel 2107 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2108 2016, . 2110 [ARPND] - Y. Li, D. Eastlake, L. Dunbar, R. Perlman, I. Gashinsky, 2111 "TRILL: ARP/ND Optimization", draft-ietf-trill-arp- 2112 optimization, work in progress. 2114 [DirAsstEncap] L. Dunbar, D. Eastlake, R. Perlman, I. Gashingksy, 2115 "Directory Assisted TRILL Encapsulation", draft-ietf-trill- 2116 directory-assisted-encap, work in progress. 2118 [SmartEN] R. Perlman, F. Hu, D. Eastlake, K. Krupakaran, T. Liao, 2119 "TRILL Smart Endnodes", draft-ietf-trill-smart-endnodes", 2120 draft-ietf-trill-smart-endnodes, work in progress. 2122 [X.233] - ITU-T Recommendation X.233: Protocol for providing the 2123 connectionless-mode network service: Protocol specification, 2124 International Telecommunications Union, August 1997 2126 Acknowledgments 2128 The contributions of the following persons are gratefully 2129 acknowledged: 2131 Matthew Bocci, Igor Gashinski, Joel Halpern, Susan Hares, Gsyle 2132 Noble 2134 The document was prepared in raw nroff. All macros used were defined 2135 within the source file. 2137 Authors' Addresses 2139 Donald Eastlake 2140 Huawei Technologies 2141 155 Beaver Street 2142 Milford, MA 01757 USA 2144 Phone: +1-508-333-2270 2145 Email: d3e3e3@gmail.com 2147 Linda Dunbar 2148 Huawei Technologies 2149 5430 Legacy Drive, Suite #175 2150 Plano, TX 75024, USA 2152 Phone: +1-469-277-5840 2153 Email: ldunbar@huawei.com 2155 Radia Perlman 2156 EMC 2157 2010 256th Avenue NE, #200 2158 Bellevue, WA 98007 USA 2160 Email: Radia@alum.mit.edu 2162 Yizhou Li 2163 Huawei Technologies 2164 101 Software Avenue, 2165 Nanjing 210012 China 2167 Phone: +86-25-56622310 2168 Email: liyizhou@huawei.com 2170 Copyright, Disclaimer, and Additional IPR Provisions 2172 Copyright (c) 2016 IETF Trust and the persons identified as the 2173 document authors. All rights reserved. 2175 This document is subject to BCP 78 and the IETF Trust's Legal 2176 Provisions Relating to IETF Documents 2177 (http://trustee.ietf.org/license-info) in effect on the date of 2178 publication of this document. Please review these documents 2179 carefully, as they describe your rights and restrictions with respect 2180 to this document. Code Components extracted from this document must 2181 include Simplified BSD License text as described in Section 4.e of 2182 the Trust Legal Provisions and are provided without warranty as 2183 described in the Simplified BSD License. The definitive version of 2184 an IETF Document is that published by, or under the auspices of, the 2185 IETF. Versions of IETF Documents that are published by third parties, 2186 including those that are translated into other languages, should not 2187 be considered to be definitive versions of IETF Documents. The 2188 definitive version of these Legal Provisions is that published by, or 2189 under the auspices of, the IETF. Versions of these Legal Provisions 2190 that are published by third parties, including those that are 2191 translated into other languages, should not be considered to be 2192 definitive versions of these Legal Provisions. For the avoidance of 2193 doubt, each Contributor to the IETF Standards Process licenses each 2194 Contribution that he or she makes as part of the IETF Standards 2195 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 2196 language to the contrary, or terms, conditions or rights that differ 2197 from or are inconsistent with the rights and licenses granted under 2198 RFC 5378, shall have any effect and shall be null and void, whether 2199 published or posted by such Contributor, or included with or in such 2200 Contribution.