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