idnits 2.17.1 draft-ietf-trill-directory-assist-mechanisms-12.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 (March 2, 2017) is 2574 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: September 1, 2017 March 2, 2017 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..........................5 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 End Stations and Push Directories.....................13 58 2.5 Additional Push Details...............................14 59 2.6 Primary to Secondary Server Push Service..............15 60 2.7 Push Directory Configuration..........................16 62 3. Pull Model Directory Assistance Mechanisms.............17 63 3.1 Pull Directory Message Common Format..................18 64 3.1.1 Version Negotiation.................................19 65 3.2 Pull Directory Query and Response Messages............20 66 3.2.1 Pull Directory Query Message Format.................20 67 3.2.2 Pull Directory Responses............................23 68 3.2.2.1 Pull Directory Response Message Format............23 69 3.2.2.2 Pull Directory Forwarding.........................26 70 3.3 Cache Consistency.....................................27 71 3.3.1 Update Message Format...............................30 72 3.3.2 Acknowledge Message Format..........................31 73 3.4 Summary of Records Formats in Messages................32 74 3.5 End Stations and Pull Directories.....................32 75 3.5.1 Pull Directory Hosted on an End Station.............33 76 3.5.2 Use of Pull Directory by End Stations...............34 77 3.5.3 Native Pull Directory Messages......................35 78 3.6 Pull Directory Message Errors.........................35 79 3.6.1 Error Codes.........................................36 80 3.6.2 Sub-Errors Under Error Codes 1 and 3................37 81 3.6.3 Sub-Errors Under Error Codes 128 and 131............37 82 3.7 Additional Pull Details...............................38 83 3.8 The No Data Flag......................................38 84 3.9 Pull Directory Service Configuration..................39 86 4. Directory Use Strategies and Push-Pull Hybrids.........41 88 5. TRILL ES-IS............................................43 89 5.1 PDUs and System IDs...................................43 90 5.2 Adjacency, DRB Election, Hellos, TLVs, Etc............44 91 5.3 Link State............................................44 93 Table of Contents Continued 95 6. Security Considerations................................45 96 6.1 Directory Information Security........................45 97 6.2 Directory Confidentiality and Privacy.................45 98 6.3 Directory Message Security Considerations.............45 100 7. IANA Considerations....................................47 101 7.1 ESADI-Parameter Data Extensions.......................47 102 7.2 RBridge Channel Protocol Numbers......................48 103 7.3 The Pull Directory (PUL) and No Data (NOD) Bits.......48 104 7.4 TRILL Pull Directory QTYPEs...........................49 105 7.5 Pull Directory Error Code Registries..................49 106 7.6 TRILL-ES-IS MAC Address...............................49 108 Normative References......................................50 109 Informational References..................................51 111 Acknowledgments...........................................53 112 Authors' Addresses........................................54 114 Copyright, Disclaimer, and Additional IPR Provisions......55 116 1. Introduction 118 [RFC7067] gives a problem statement and high level design for using 119 directory servers to assist TRILL [RFC6325] [RFC7780] edge nodes in 120 reducing multi-destination ARP/ND [ARPND], reducing unknown unicast 121 flooding traffic, and improving security against address spoofing 122 within a TRILL campus. Because multi-destination traffic becomes an 123 increasing burden as a network scales up in number of nodes, reducing 124 ARP/ND and unknown unicast flooding improves TRILL network 125 scalability. This document describes specific mechanisms for TRILL 126 directory servers. 128 The information held by the Directory(s) is address mapping and 129 reachability information. Most commonly, what MAC (Media Access 130 Control) address [RFC7042] corresponds to an IP address within a Data 131 Label (VLAN or FGL (Fine Grained Label [RFC7172])) and the egress 132 TRILL switch (RBridge), and optionally what specific port on that 133 TRILL switch, from which that MAC address is reachable. But it could 134 be what IP address corresponds to a MAC address or possibly other 135 address mapping or reachability information. 137 The mechanism used to initially populate directory data in primary 138 servers is beyond the scope of this document. A primary server can 139 use the Push Directory service to provide directory data to secondary 140 servers as described in Section 2.6. In the data center environment, 141 it is common for orchestration software to know and control where all 142 the IP addresses, MAC addresses, and VLANs/tenants are in a data 143 center. Thus such orchestration software can be appropriate for 144 providing the directory function or for supplying the Directory(s) 145 with directory information. 147 Efficient routing of unicast traffic in a TRILL campus assumes that 148 the mapping of destination MAC addresses to edge RBridges is stable 149 enough that the default data plane learning of TRILL and/or the use 150 of directories reduces to an acceptable level the need to flood 151 packets where the location of the destination is unknown. Although 152 not prohibited, "Ephemeral" MAC addresses are unlikely to be used in 153 such an environment. Directories need not be complete and in the case 154 that any ephemeral MAC addresses were in use, they would probably not 155 be included in directory information. 157 Directory services can be offered in a Push Mode, Pull Mode, or both 158 [RFC7067] at the option of the server. Push Mode, in which a 159 directory server pushes information to TRILL switches indicating 160 interest, is specified in Section 2. Pull Mode, in which a TRILL 161 switch queries a server for the information it wants, is specified in 162 Section 3. More detail on modes of operation, including hybrid 163 Push/Pull, are provided in Section 4. 165 1.1 Uses of Directory Information 167 A TRILL switch can consult Directory information whenever it wants, 168 by (1) searching through information that has been retained after 169 being pushed to it or pulled by it or (2) by requesting information 170 from a Pull Directory. However, the following are expected to be the 171 most common circumstances leading to directory information use. All 172 of these are cases of ingressing (or originating) a native frame. 174 1. ARP requests and replies [RFC826] are normally broadcast. But a 175 directory assisted edge TRILL switch could intercept ARP messages 176 and reply if the TRILL switch has the relevant information 177 [ARPND]. 179 2. IPv6 ND (Neighbor Discovery [RFC4861]) requests and replies are 180 normally multicast. Except in the case of Secure ND [RFC3971], 181 where possession of the right keying material might be required, a 182 directory assisted edge TRILL switch could intercept ND messages 183 and reply if the TRILL switch has the relevant information. 184 [ARPND] 186 3. Unknown destination MAC addresses normally cause a native frame to 187 be flooded. An edge TRILL switch ingressing a native frame 188 necessarily has to determine if it knows the egress RBridge from 189 which the destination MAC address of the frame (in the frame's 190 VLAN or FGL) is reachable. It might have learned that information 191 from the directory or could query the directory if it does not 192 know it. Furthermore, if the edge TRILL switch has complete 193 directory information, it can detect a forged source MAC or IP 194 address in any native frame and discard the frame if it finds such 195 a forged address. 197 4. RARP [RFC903] (Reverse ARP) is similar to ARP as above. 199 1.2 Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 The terminology and acronyms of [RFC6325] are used herein along with 206 the following: 208 AFN: Address Family Number, (http://www.iana.org/assignments/address- 209 family-numbers/) 211 CSNP Time: Complete Sequence Number PDU Time. See ESDADI [RFC7357] 212 and Section 7.1 below. 214 Data Label: VLAN or FGL. 216 ESADI: End Station Address Distribution Information [RFC7357]. 218 FGL: Fine Grained Label [RFC7172]. 220 FR: Flood Record flag bit. See Section 3.2.1. 222 Host: A physical server or a virtual machine. A host must have a MAC 223 address and usually has at least one IP address. 225 Interested Labels sub-TLV: Short for "Interested Labels and Spanning 226 Tree Roots sub-TLV" [RFC7176]. 228 Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning 229 Tree Roots sub-TLV" [RFC7176]. 231 IP: Internet Protocol. In this document, IP includes both IPv4 and 232 IPv6. 234 MAC: Media Access Control address [RFC7042] 236 MacDA: Destination MAC address. 238 MacSA: Source MAC address. 240 OV: Overflow flag bit. See Section 3.2.2.1. 242 PDSS: Push Directory Server Status. See Sections 2 and 7.1. 244 PUL: Pull Directory flag bit. See Sections 3 and 7.3. 246 primary server: A Directory server that obtains the information it is 247 serving up by a reliable mechanism outside the scope of this 248 document designed to assure the freshness of that information. 249 (See secondary server.) 251 RBridge: An alternative name for a TRILL switch. 253 secondary server: A Directory server that obtains the information it 254 is serving up from one or more primary servers. 256 TLV: Type, Length, Value 258 TRILL: Transparent Interconnection of Lots of Links or Tunneled 259 Routing in the Link Layer. 261 TRILL switch: A device that implements the TRILL protocol. 263 2. Push Model Directory Assistance Mechanisms 265 In the Push Model [RFC7067], one or more Push Directory servers 266 reside at TRILL switches and push down the address mapping 267 information for the various addresses associated with end station 268 interfaces and the TRILL switches from which those interfaces are 269 reachable [RFC7961]. This service is scoped by Data Label (VLAN or 270 FGL [RFC7172]). A Push Directory advertises when, for a Data Label, 271 it both is configured to be a directory having complete information 272 and has actually pushed all the information it has. It might be 273 pushing only a subset of the mapping and/or reachability information 274 for a Data Label. The Push Model uses the ESADI [RFC7357] (End 275 Station Address Distribution Information) protocol as its 276 distribution mechanism. 278 With the Push Model, if complete address mapping information for a 279 Data Label is being pushed, a TRILL switch (RBridge) that has that 280 complete information and is ingressing a native frame can simply drop 281 the frame if the destination unicast MAC address can't be found in 282 the mapping information available, instead of flooding the frame 283 (ingressing it as an unknown MAC destination TRILL Data frame). But 284 this will result in lost traffic if ingress TRILL switch's directory 285 information is incomplete. 287 2.1 Requesting Push Service 289 In the Push Model, it is necessary to have a way for a TRILL switch 290 to subscribe to information from the directory server(s). TRILL 291 switches simply use the ESADI [RFC7357] protocol mechanism to 292 announce, in their core IS-IS LSPs, the Data Labels for which they 293 are participating in ESADI by using the Interested VLANs and/or 294 Interested Labels sub-TLVs [RFC7176]. This will cause the Directory 295 information to be pushed to them for all such Data Labels that are 296 being served by the one or more Push Directory servers. 298 2.2 Push Directory Servers 300 Push Directory servers advertise, through ESADI, their availability 301 to push the mapping information for a particular Data Label by 302 setting the PDSS (Push Directory Server Status) in their ESADI 303 Parameter APPsub-TLV for that ESADI instance (see [RFC7357] and 304 Section 7.1) to a non-zero value. This PDSS field setting is visible 305 to other ESADI participants, including other Push Directory servers, 306 for that Data Label. Each Push Directory server MUST participate in 307 ESADI for the Data Labels for which it will push mappings and set the 308 PDSS field in its ESADI-Parameters APPsub-TLV for that Data Label. 310 For increased robustness, increased bandwidth capability, and 311 improved locality, it is useful to have multiple Push Directory 312 Servers for each Data Label. Each Push Directory server is configured 313 with a number N in the range 1 to 8, which defaults to 2, for each 314 Data Label for which it can push directory information (see 315 PushDirServers, Section 2.7). If the Push Directory servers for a 316 Data Label are configured consistently with the same N and at least N 317 servers are available, then N copies of that directory will be 318 pushed. 320 Each Push Directory server also has a configurable 8-bit priority 321 (PushDirPriority) to be Active, which defaults to 0x3F (see Section 322 2.7). This priority is treated as an unsigned integer where larger 323 magnitude means higher priority. This priority appears in its ESADI 324 Parameter APPsub-TLV (see Section 7.1). In case of a tie in this 325 configurable priority, the System ID of the TRILL switch acting as 326 the server is used as an unsigned 6-byte integer where larger 327 magnitude indicates higher priority. 329 For each Data Label it can serve, each Push Directory server checks 330 to see if there appear to be enough higher priority servers to push 331 the desired number of copies. It does this by ordering, by priority, 332 the Push Directory servers whose advertisements are present in the 333 ESADI link state database for that Data Label and that are data 334 reachable [RFC7780] as indicated by its IS-IS link state database. 335 The Push Directory server then determines its own position in that 336 order. If a Push Directory server's configuration indicates that N 337 copies of the mappings for a Data Label should be pushed and the 338 server finds that it is number K in the priority ordering (where 339 number 1 in the ordered list is highest priority and the last is 340 lowest priority), then if K is less than or equal to N the Push 341 Directory server is Active. If K is greater than N it is Stand-By. 342 Active and Stand-By behavior are specified below in Section 2.3. 344 For a Push Directory to reside on an end station, one or more TRILL 345 switches locally connected to that end station must proxy for the 346 Push Directory server and advertise themselves in ESADI as Push 347 Directory servers. It appears to the rest of the TRILL campus that 348 these TRILL switches (that are proxying for the end station) are the 349 Push Directory server(s). The protocol between such a Push Directory 350 end station and the one or more proxying TRILL switches acting as 351 Push Directory servers is beyond the scope of this document. 353 2.3 Push Directory Server State Machine 355 The subsections below describe the states, events, and corresponding 356 actions for Push Directory servers. 358 The meaning of the value of the PDSS field in a Push Directory's 359 ESADI Parameter APPsub-TLV is summarized in the table below. 361 PDSS Meaning 362 ---- ---------- 363 0 Not a Push Directory Server 364 1 Push Directory Server in Stand-By Mode 365 2 Push Directory Server in Active Mode but not complete 366 3 Push Directory Server in Active Mode that has pushed 367 complete data 369 2.3.1 Push Directory States 371 A Push Directory Server is in one of seven states, as listed below, 372 for each Data Label it can serve. The name of each state is followed 373 by a symbol that starts and ends with an angle bracket and represents 374 the state. The value that the Push Directory Server advertises in 375 PDSS is determined by the state. In addition, it has an internal 376 State-Transition-Time variable for each Data Label it serves that is 377 set at each state transition and which enables it to determine how 378 long it has been in its current state for that Data Label. 380 Down : A completely shut down virtual state defined for 381 convenience in specifying state diagrams. A Push Directory Server 382 in this state does not advertise any Push Directory data. It may 383 be participating in ESDADI [RFC7357] with the PDSS field zero in 384 its ESADI-Parameters or might be not participating in ESADI at 385 all. All states other than the Down state are considered to be Up 386 states and imply a non-zero PDSS field. 388 Stand-By : No Push Directory data is advertised. Any outstanding 389 EASDI-LSP fragments containing directory data are updated to 390 remove that data and, if the result is an empty fragment (contains 391 nothing except possibly an Authentication TLV), the fragment is 392 purged. The Push Directory participates in ESDADI [RFC7357] and 393 advertises its ESADI fragment zero that includes an ESADI- 394 Parameters APPsub-TLV with the PDSS field set to 1. 396 Active : The Push Directory participates in ESDADI [RFC7357] and 397 advertises its ESADI fragment zero that includes an ESADI- 398 Parameters APPsub-TLV with the PDSS field set to 2. It also 399 advertises its directory data and any changes through ESADI 400 [RFC7357] in its ESADI-LSPs using the Interface Addresses 401 [RFC7961] APPsub-TLV and updates that information as it changes. 403 Active Completing : Same behavior as the Active state except 404 that the server responds differently to events. The purpose of 405 this state is to be sure there has been enough time for directory 406 information to propagate to subscribing edge TRILL switches (see 407 the Time Condition, Section 2.3.2) before the Directory Server 408 advertises that the information is complete. 410 Active Complete : The same behavior as Active except that the 411 PDSS field in the ESADI-Parameters APPsub-TLV is set to 3 and the 412 server responds differently to events. 414 Going Stand-By Was Complete : The same behavior as Active except 415 that the server responds differently to events. The purpose of 416 this state is to be sure that the information, that the directory 417 will no longer be complete, has enough time to propagate to edge 418 TRILL switches (see the Time Condition, Section 2.3.2) before the 419 Directory Server stops advertising updates to the information. 420 (See note below.) 422 Active Uncompleting : The same behavior as Active except that it 423 responds differently to events. The purpose of this state is to be 424 sure that the information, that the directory will no longer be 425 complete, has enough time to propagate to edge TRILL switches (see 426 the Time Condition, Section 2.3.2) before the Directory Server 427 might stop advertising updates to the information. (See note 428 below.) 430 Note: It might appear that a Push Directory could transition 431 directly from Active Complete to Active, since Active state 432 continues to advertise updates, eliminating the need for the 433 Active Uncompleting transition state. But consider the case of 434 the Push Directory that was complete being configured to be 435 incomplete and then the Stand-By Condition (see Section 2.3.2) 436 occurring shortly thereafter. If the first of these two events 437 caused the server to transition directly to the Active state 438 then, when the Stand-By Condition occurred, it would 439 immediately transition to Stand-By and stop advertising updates 440 even though there might not have been enough time for knowledge 441 of its incompleteness to have propagated to all edge TRILL 442 switches. 444 The following table summarizes PDSS value for each state: 446 State PDSS 447 ---------- ------ 448 Down 0 449 Stand-By 1 450 Active 2 451 Active Completing 2 452 Active Complete 3 453 Going Stand-By 2 454 Active Uncompleting 2 456 2.3.2 Push Directory Events and Conditions 458 Three auxiliary conditions referenced later in this section are 459 defined as follows for convenience: 461 The Activate Condition: In order to have the desired number of Push 462 Directory servers pushing data for Data Label X, this Push 463 Directory server should be active. This is determined by the 464 server finding that (A) it is priority K among the data reachable 465 Push Directory servers (where highest priority server is 1) for 466 Data Label X, (B) it is configured that there should be N copies 467 pushed for Data Label X, and (C) K is less than or equal to N. For 468 example, if the Push Directory server is configured so that 2 469 copies should be pushed and finds that it is priority 1 or 2 among 470 the Push Directory servers that are visible in its ESADI link 471 state database and that are data reachable as indicated by its IS- 472 IS link state database. 474 The Stand-By Condition: In order to have the desired number of Push 475 Directory servers pushing data for Data Label X, this Push 476 Directory server should be stand-by (not active). This is 477 determined by the server finding that (A) it is priority K among 478 the data reachable Push Directory servers (where highest priority 479 server is 1) for Data Label X, (B) it is configured that there 480 should be N copies pushed for Data Label X, and (C) K is greater 481 than N. For example, the Push Directory server is configured that 482 2 copies should be pushed and finds that it is priority 3 or lower 483 priority (higher number) among the available Push directory 484 servers. 486 The Time Condition: The Push Directory server has been in its current 487 state for a configurable amount of time (PushDirTimer) that 488 defaults to twice its CSNP (Complete Sequence Number PDU) time 489 (see Sections 2.7 and 7.1).) 491 The events and conditions listed below cause state transitions in 492 Push Directory servers. 494 1. Push Directory server comes Up. 496 2. The Push Directory server or the TRILL switch on which it resides 497 is being shut down. This is a persistent condition unless the shut 498 down is canceled. So, for example, a Push Directory server in the 499 Going Stand-By Was Complete state does not transition out of that 500 state due to this condition but, after the Time Condition is met 501 and the directory transitions to Stand-By and performs the actions 502 required there (such as purging LSPs) continues to the Down state 503 if this condition is still true. Similar comments apply to 504 events/conditions 3, 4, and 5. 506 3. The Activate Condition is met and the server's configuration 507 indicates it does not have complete data. 509 4. The Stand-By Condition is met. 511 5. The Activate Condition is met and the server's configuration 512 indicates it has complete data. 514 6. The server's configuration is changed to indicate it does not have 515 complete data. 517 7. The Time Condition is met. 519 2.3.3 State Transition Diagram and Table 521 The state transition table is as follows: 523 State|Down|Stand-By|Active| Active | Active | Going | Active 524 -----+ | | |Completing|Complete|Stand-By|Uncompleting 525 Event|| | | | | | 526 -----+----+--------+------+----------+--------+---------+------------ 527 1 || N/A | N/A | N/A | N/A | N/A | N/A 528 2 || | | | | | 529 3 || | | | | | 530 4 || | | | | | 531 5 || | | | | | 532 6 || | | | | | 533 7 || | | | | | 535 The above state table is equivalent to the following transition 536 diagram: 538 +-----------+ 539 | Down |<---------+ 540 +-----------+ | 541 |1 ^ | 3,4,5,6,7 | 542 | | +------------+ 543 V |2 544 +---------------+ 545 | Stand-By |<--------------------------------------+ 546 +---------------+ ^ ^ ^ | 547 |5 |3 |1,4,6,7 | | | | 548 | | +---------+ | | | 549 | V |2,4 | | 550 | +---------------------+ | | 551 | | Active |<---------|-------------+ | 552 | +---------------------+ ^ | | | 553 | |5 ^ |1,3,6,7 ^ | | | | 554 | | | | | | | | | 555 | | | +---------+ | | | | 556 | | | | | | | 557 V V |3,6 | | | | 558 +------------------------+ | | | | 559 | Active Completing |------------+ | | 560 +------------------------+ 2,4 | | | 561 |7 |1,5 ^ | | | 562 | | | | | | 563 | +-------+ | | | 564 | | | | 565 | +------------------------------------+ | | 566 | | | | | | 567 V V |7 |5 |3 |7 568 +-------------+ 3,6 +----------------+ 4 +----------------+ 569 | Active |------->| Active |--->| Going Stand-By | 570 | Complete | | Uncompleting | | Was Complete | 571 | |<-------| | | | 572 +-------------+ 5 +----------------+ +----------------+ 573 |1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^ 574 | | | | | | | | 575 +-------+ | +------------+ | +--------+ 576 | | 577 +----------------------------------+ 579 Figure 1. Push Server State Diagram 581 2.4 End Stations and Push Directories 583 End station hosting or use of Push Directories is outside of the 584 scope of this document. Push Directory information distribution is 585 accomplished using ESADI [RFC7357], which does not operate to end 586 stations. In the future, ESADI might be extended to operate to end 587 stations or some other method, such as BGP, might be specified as a 588 way to support end station hosting or use of Push Directories. 590 2.5 Additional Push Details 592 Push Directory mappings can be distinguished from other data 593 distributed through ESADI because mappings are distributed only with 594 the Interface Addresses APPsub-TLV [RFC7961] and are flagged in that 595 APPsub-TLV as being Push Directory data. 597 TRILL switches, whether or not they are Push Directory servers, MAY 598 continue to advertise any locally learned MAC attachment information 599 in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. 600 However, if a Data Label is being served by complete Push Directory 601 servers, advertising such locally learned MAC attachment generally 602 SHOULD NOT be done as it would not add anything and would just waste 603 bandwidth and ESADI link state space. An exception might be when a 604 TRILL switch learns local MAC connectivity and that information 605 appears to be missing from the directory mapping. 607 Because a Push Directory server needs to advertise interest in one or 608 more Data Labels even though it might not want to receive multi- 609 destination TRILL Data packets in those Data Labels, the No Data 610 (NOD) flag bit is provided as discussed in Section 3.8. 612 When a Push Directory server is no longer data reachable [RFC7780] as 613 indicated by the IS-IS link state database, other TRILL switches MUST 614 ignore any Push Directory data from that server because it is no 615 longer being updated and may be stale. 617 The nature of dynamic distributed asynchronous systems is such that 618 it is impossible for a TRILL switch receiving Push Directory 619 information to be absolutely certain that it has complete 620 information. However, it can obtain a reasonable assurance of 621 complete information by requiring two conditions to be met: 622 1. The PDSS field is 3 in the ESADI zero fragment from the server 623 for the relevant Data Label. 624 2. In so far as it can tell, it has had continuous data 625 connectivity to the server for a configurable amount of time 626 that defaults to twice the server's CSNP time (PushDirTimer, 627 see Section 2.7). 628 Condition 2 is necessary because a client TRILL switch might be just 629 coming up and receive an EASDI LSP meeting the requirement in 630 condition 1 above but has not yet received all of the ESADI LSP 631 fragments from the Push Directory server. 633 Likewise, due to various delays, when an end station connects to or 634 disconnects from the campus there are timing differences between such 635 connection or disconnection, the update of directory information at 636 the directory, and the update of directory information at any 637 particular RBridge in the TRILL campus. Thus, there is commonly a 638 small window during which an RBridge using directory information 639 might either (1) drop or unnecessarily flood a frame as having an 640 unknown unicast destination or (2) encapsulate a frame to an edge 641 RBridge where the end station is not longer connected when the frame 642 arrives at that edge RBridge. 644 There may be conflicts between mapping information from different 645 Push Directory servers or conflicts between locally learned 646 information and information received from a Push Directory server. In 647 case of such conflicts, information with a higher confidence value 648 [RFC6325] [RFC7961] is preferred over information with a lower 649 confidence. In case of equal confidence, Push Directory information 650 is preferred to locally learned information and if information from 651 Push Directory servers conflicts, the information from the higher 652 priority Push Directory server is preferred. 654 2.6 Primary to Secondary Server Push Service 656 A secondary Push or Pull Directory server is one that obtains its 657 data from a primary directory server. Such mechanisms, where some 658 directory servers can be populated from others, have been found 659 useful for multiple-server directory applications, for example in the 660 DNS where it is the normal case that some authoritative servers 661 (secondary servers) are populated with data from other authoritative 662 servers (primary servers). 664 Other techniques MAY be used but, by default, this data transfer 665 occurs through the primary server acting as a Push Directory server 666 for the Data Labels involved while the secondary directory server 667 takes the pushed data it receives from the highest priority Push 668 Directory server and re-originates it. Such a secondary server may be 669 a Push Directory server or a Pull Directory server or both for any 670 particular Data Label. Because the data from a secondary server will 671 necessarily be at least a little less fresh than that from a primary 672 server, it is RECOMMENDED that the re-originated secondary server 673 data be given a confidence level at least one less than that of the 674 data as received from the primary (or unchanged if it is already of 675 minimum confidence). 677 2.7 Push Directory Configuration 679 The following per Data Label configuration parameters are available 680 for controlling Push Directory behavior: 682 Name Range Default Section 683 --------------- -------- ------- ------- 684 PushDirService T/F F 2.2 685 PushDirServers 1 - 8 2 2.2 686 PushDirPriority 0 - 255 0x3F 2.2 687 PushDirComplete T/F F 2.3.1, 2.3.2 688 PushDirTimer 1 - 511 2*CSNP 2.3.2, 2.5 690 PushDirService is a boolean. When false, Push Directory service is 691 not provided; when true, it is. 693 PushDirComplete is a boolean. When false, the server never indicates 694 that the information it has pushed is complete; when true, it does so 695 indicate after pushing all the information it knows. 697 PushDirTimer defaults to two times the ESADI CSNP configuration value 698 but not less than 1 second. 700 3. Pull Model Directory Assistance Mechanisms 702 In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory 703 information from an appropriate Directory Server when needed. 705 A TRILL switch that makes use of Pull Directory services must 706 implement appropriate connections between its directory utilization 707 and its link state database and link state updating. For example, 708 Pull Directory servers for a particular Data Label X are found by 709 looking in the core TRILL IS-IS link state database for data 710 reachable [RFC7780] TRILL switches that advertise themselves by 711 having the Pull Directory flag (PUL) on in their Interested VLANs or 712 Interested Labels sub-TLV (see Section 7.3) for that Data Label. The 713 set of such switches can change with configuration changes by network 714 management, such as starting up or shutting down of Pull Directory 715 servers, or changes in network topology, such the connection or 716 disconnection of TRILL switches that are Pull Directory servers, or 717 network partition or merger. As described in Section 3.7, a TRILL 718 switch MUST notice if a Pull Directory from which it has cached data 719 is no longer data reachable so it can discard such cached data. 721 If multiple data reachable TRILL switches indicate in the link state 722 database that they are Pull Directory Servers for a particular Data 723 Label, pull requests can be sent to any one or more of them but it is 724 RECOMMENDED that pull requests be preferentially sent to the server 725 or servers that are lowest cost from the requesting TRILL switch. 727 Pull Directory requests are sent by enclosing them in an RBridge 728 Channel [RFC7178] message using the Pull Directory channel protocol 729 number (see Section 7.2). Responses are returned in an RBridge 730 Channel message using the same channel protocol number. See Section 731 3.2 for Query and Response Message formats. For cache consistency or 732 notification purposes, Pull Directory servers, under certain 733 conditions, MUST send unsolicited Update Messages to client TRILL 734 switches they believe may be holding old data and those clients can 735 acknowledge such updates, as described in Section 3.3. All these 736 messages have a common header as described in Section 3.1. Errors are 737 returned as described in Section 3.6. 739 The requests to Pull Directory Servers are typically derived from 740 ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND 741 [RFC3971] messages, or data frames with unknown unicast destination 742 MAC addresses, intercepted by an ingress TRILL switch, as described 743 in Section 1.1. 745 Pull Directory responses include an amount of time for which the 746 response should be considered valid. This includes negative responses 747 that indicate no data is available. It is RECOMMENDED that both 748 positive responses with data and negative responses be cached and 749 used to locally handle ARP, ND, RARP, unknown destination MAC frames, 750 or the like [ARPND], until the responses expire. If information 751 previously pulled is about to expire, a TRILL switch MAY try to 752 refresh it by issuing a new pull request but, to avoid unnecessary 753 requests, SHOULD NOT do so unless it has been recently used. The 754 validity timer of cached Pull Directory responses is NOT reset or 755 extended merely because that cache entry is used. 757 3.1 Pull Directory Message Common Format 759 All Pull Directory messages are transmitted as the Channel Protocol 760 specific payload of RBridge Channel messages [RFC7178]. Pull 761 Directory messages are formatted as described herein starting with 762 the following common 8-byte header: 764 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Ver | Type | Flags | Count | Err | SubErr | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Sequence Number | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Type Specific Payload - variable length 772 +-+-+- ... 774 Ver: Version of the Pull Directory protocol as an unsigned 775 integer. Version zero is specified in this document. See 776 Section 3.1.1 for a discussion of version negotiation. 778 Type: The Pull Directory message type as follows: 780 Type Section Name 781 ---- ------- -------- 782 0 - Reserved 783 1 3.2.1 Query 784 2 3.2.2 Response 785 3 3.3.1 Update 786 4 3.3.2 Acknowledge 787 5-14 - Unassigned 788 15 - Reserved 790 Flags: Four flag bits whose meaning depends on the Pull Directory 791 message Type. Flags whose meanings are not specified are 792 reserved, MUST be sent as zero, and MUST be ignored on receipt. 794 Count: Some Pull Directory message types specified herein have 795 zero or more occurrences of a Record as part of the type 796 specific payload. The Count field is the number of occurrences 797 of that Record as an unsigned integer. For any Pull Directory 798 messages not structured with such occurrences, this field MUST 799 be sent as zero and ignored on receipt. 801 Err, SubErr: The error and suberror fields are only used in 802 messages that are in the nature of replies. In messages that 803 are requests or updates, these fields MUST be sent as zero and 804 ignored on receipt. An Err field containing the value zero 805 means no error. The meaning of values in the SubErr field 806 depends on the value of the Err field but, in all cases, a zero 807 SubErr field is allowed and provides no additional information 808 beyond the value of the Err field. 810 Sequence Number: An identifying 32-bit quantity set by the TRILL 811 switch sending a request or other unsolicited message and 812 returned in every corresponding reply or acknowledgment. It is 813 used to match up responses with the message to which they 814 respond. 816 Type Specific Payload: Format depends on the Pull Directory 817 message Type. 819 3.1.1 Version Negotiation 821 The version number (Ver) in the Pull Directory message header is 822 incremented for a future version with changes such that TRILL 823 directory messages cannot be parsed correctly by an earlier version. 824 Ver is not incremented for minor changes such as defining a new field 825 value for an existing field. 827 Pull Directory messages come in pairs (Request-Response, Update- 828 Acknowledgment). The version number in the Request/Update (Ver1) 829 indicates the format of that message and of the corresponding 830 returned Response/Acknowledgment. The version number in the returned 831 Response/Acknowledgment (Ver2) indicates the highest version number 832 that the sender of that Response/Acknowledgment understands. 834 In the most common case of a well configured network, Ver1 and Ver2 835 will be equal. 837 If Ver2 is less than Ver1, the returned Response/Acknowledgment will 838 be an error message saying that the version is not understood. 840 If Ver2 is greater than Ver1 and the responder understands Ver1, it 841 responds normally in Ver1 format. However, if the responder does not 842 understand Ver1, it MUST send a version-not-understood error message 843 correctly formatted for Ver1. Thus all implementations that support 844 some version X MUST be able to send a version-not-understood error 845 message formatted correctly formatted for all lower versions down to 846 version zero. 848 3.2 Pull Directory Query and Response Messages 850 The format of Pull Directory Query and Response Messages is specified 851 below. 853 3.2.1 Pull Directory Query Message Format 855 A Pull Directory Query Message is sent as the Channel Protocol 856 specific content of an RBridge Channel message [RFC7178] TRILL Data 857 packet or as a native RBridge Channel data frame (see Section 3.5). 858 The Data Label of the packet is the Data Label in which the query is 859 being made. The priority of the channel message is a mapping of the 860 priority of the ingressed frame that caused the query. The default 861 mapping depends, per Data Label, on the strategy (see Section 4) or a 862 configured priority (DirGenQPriority, Section 3.9) for generated 863 queries. (Generated queries are those not the result of a mapping. 864 For example, a query to refresh a cache entry.) The Channel Protocol 865 specific data is formatted as a header and a sequence of zero or more 866 QUERY Records as follows: 868 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Ver | Type | Flags | Count | Err | SubErr | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Sequence Number | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | QUERY 1 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 877 | QUERY 2 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 879 | ... 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 881 | QUERY K 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 884 Ver, Sequence Number: See Section 3.1. 886 Type: 1 for Query. Queries received by an TRILL switch that is not 887 a Pull Directory for the relevant Data Label result in an error 888 response (see Section 3.6) unless inhibited by rate limiting. 889 (See [RFC7178] for response if the Pull Directory RBridge 890 Channel protocol is not implemented or enabled.) 892 Flags, Err, and SubErr: MUST be sent as zero and ignored on 893 receipt. 895 Count: Number of QUERY Records present. A Query Message Count of 896 zero is explicitly allowed, for the purpose of pinging a Pull 897 Directory server to see if it is responding. On receipt of such 898 an empty Query Message, a Response Message that also has a 899 Count of zero is returned unless inhibited by rate limiting. 901 QUERY: Each QUERY Record within a Pull Directory Query Message is 902 formatted as follows: 904 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 905 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 906 | SIZE |FR| RESV | QTYPE | 907 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 908 If QTYPE = 1 909 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 910 | AFN | 911 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 912 | Query address ... 913 +--+--+--+--+--+--+--+--+--+--+--... 914 If QTYPE = 2 or 5 915 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 916 | Query frame ... 917 +--+--+--+--+--+--+--+--+--+--+--... 919 SIZE: Size of the QUERY Record in bytes as an unsigned integer 920 not including the SIZE field and following byte. A value of 921 SIZE so large that the material doesn't fit in the Query 922 Message indicates a malformed QUERY Record. The QUERY Record 923 with the illegal SIZE value and any subsequent QUERY Records 924 MUST be ignored and the entire Query Message MAY be ignored. 926 FR: The Flood Record flag that is ignored if QTYPE is zero. If 927 QTYPE is 2 or 5 and the directory information sought is not 928 found, the frame provided is flooded, otherwise it is not 929 forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or 930 5, the FR flag has no effect. 932 RESV: A block of three reserved bits. MUST be sent as zero and 933 ignored on receipt. 935 QTYPE: There are several types of QUERY Records currently 936 defined in two classes as follows: (1) a QUERY Record that 937 provides an explicit address and asks for all addresses for 938 the interface specified by the query address and (2) a QUERY 939 Record that includes a frame. The fields of each are 940 specified below. Values of QTYPE are as follows: 942 QTYPE Description 943 ----- ----------- 944 0 Reserved 945 1 Address query 946 2 Frame query 947 3-4 Unassigned 948 5 Unknown unicast MAC query frame 949 6-14 Unassigned 950 15 Reserved 952 AFN: Address Family Number of the query address. 954 Query Address: The query is asking for any other addresses, 955 and the nickname of the TRILL switch from which they are 956 reachable, that correspond to the same interface as this 957 address, within the Data Label of the query of the 958 address provided. A typically Query Address would be 959 something like the following: 960 (1) A 48-bit MAC address with the querying TRILL switch 961 primarily interested in either 962 (1a) the RBridge by which that MAC address is 963 reachable so that the querying RBridge can 964 forward an unknown (before the query) 965 destination MAC address native frame as a 966 unicast TRILL Data packet rather than flooding 967 it, or 968 (1b) the IP address corresponding to the MAC address 969 so that RBridge can locally respond to a RARP 970 [RFC903] native frame. 971 (2) An IPv4 or IPv6 address with the querying RBridge 972 interested in the corresponding MAC address so it can 973 locally respond to an ARP [RFC826] or ND [RFC4861] 974 native frame [ARPND]. 975 But the query address could be some other address type 976 for which an AFN has been assigned, such as a 64-bit MAC 977 address [RFC7042] or a CLNS address [X.233]. 979 Query Frame: Where a QUERY Record is the result of an ARP, 980 ND, RARP, SEND, or unknown unicast MAC destination 981 address, the ingress TRILL switch MAY send the frame to a 982 Pull Directory Server if the frame is small enough that 983 the resulting Query Message fits into a TRILL Data packet 984 within the campus MTU. The full frame is included, 985 starting with the destination and source MAC addresses 986 but does not include the FCS. 988 If no response is received to a Pull Directory Query Message within a 989 configurable timeout (DirQueryTimeout, see Section 3.9), then the 990 Query Message should be re-transmitted with the same Sequence Number 991 (up to a configurable number of times (DirQueryRetries, see Section 992 3.9)). If there are multiple QUERY Records in a Query Message, 993 responses can be received to various subsets of these QUERY Records 994 before the timeout. In that case, the remaining unanswered QUERY 995 Records should be re-sent in a new Query Message with a new sequence 996 number. If a TRILL switch is not capable of handling partial 997 responses to queries with multiple QUERY Records, it MUST NOT send a 998 Request Message with more than one QUERY Record in it. 1000 See Section 3.6 for a discussion of how Query Message errors are 1001 handled. 1003 3.2.2 Pull Directory Responses 1005 A Pull Directory Query Message results in a Pull Directory Response 1006 Message as described in Section 3.2.2.1. 1008 In addition, if the QUERY Record QTYPE was 2 or 5, the frame included 1009 in the Query may be modified and forwarded by the Pull Directory 1010 server as described in Section 3.2.2.2. 1012 3.2.2.1 Pull Directory Response Message Format 1014 Pull Directory Response Messages are sent as the Channel Protocol 1015 specific content of an RBridge Channel message [RFC7178] TRILL Data 1016 packet or as a native RBridge Channel data frame (see Section 3.5). 1017 Responses are sent with the same Data Label and priority as the Query 1018 Message to which they correspond except that the Response Message 1019 priority is limited to be not more than the configured value 1020 DirRespMaxPriority (Section 3.9). 1022 The RBridge Channel protocol specific data format is as follows: 1024 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Ver | Type | Flags | Count | Err | SubErr | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Sequence Number | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | RESPONSE 1 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1033 | RESPONSE 2 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1035 | ... 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1037 | RESPONSE K 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1040 Ver, Sequence Number: As specified in Section 3.1. 1042 Type: 2 = Response. 1044 Flags: MUST be sent as zero and ignored on receipt. 1046 Count: Count is the number of RESPONSE Records present in the 1047 Response Message. 1049 Err, SubErr: A two-part error code. Zero unless there was an error 1050 in the Query Message, for which case see Section 3.6. 1052 RESPONSE: Each RESPONSE Record within a Pull Directory Response 1053 Message is formatted as follows: 1055 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1056 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1057 | SIZE |OV| RESV | Index | 1058 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1059 | Lifetime | 1060 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1061 | Response Data ... 1062 +--+--+--+--+--+--+--+--+--+--+--... 1064 SIZE: The size of the RESPONSE Record is an unsigned integer 1065 number of bytes not including the SIZE field and following 1066 byte. A value of SIZE so large that the material doesn't fit 1067 in the Query Message indicates a malformed RESPONSE Record. 1068 The RESPONSE Record with such an excessive SIZE value and 1069 any subsequent RESPONSE Records MUST be ignored and the 1070 entire Response Message MAY be ignored. 1072 OV: The overflow flag. Indicates, as described below, that 1073 there was too much Response Data to include in one Response 1074 Message. 1076 RESV: Three reserved bits that MUST be sent as zero and ignored 1077 on receipt. 1079 Index: The relative index of the QUERY Record in the Query 1080 Message to which this RESPONSE Record corresponds. The index 1081 will always be one for Query Messages containing a single 1082 QUERY Record. If the Index is larger than the Count was in 1083 the corresponding Query, that RESPONSE Record MUST be 1084 ignored and subsequent RESPONSE Records or the entire 1085 Response Message MAY be ignored. 1087 Lifetime: The length of time for which the response should be 1088 considered valid in units of 100 milliseconds except that 1089 the values zero and 2**16-1 are special. If zero, the 1090 response can only be used for the particular query from 1091 which it resulted and MUST NOT be cached. If 2**16-1, the 1092 response MAY be kept indefinitely but not after the Pull 1093 Directory server goes down or becomes unreachable. (The 1094 maximum definite time that can be expressed is a little over 1095 1.8 hours.) 1097 Response Data: There are three types of RESPONSE Records. 1098 - If the Err field of the enclosing Response Message has a 1099 message level error code in it, then the RESPONSE Records 1100 are omitted and Count will be zero. See Section 3.6 for 1101 additional information on errors. 1102 - If the Err field of the enclosing Response Message has a 1103 record level error code in it, then the RESPONSE Records 1104 are those in error as further described in Section 3.6. 1105 - If the Err field of the enclosing Response Message is 1106 zero, then the Response Data in each RESPONSE Record is 1107 formatted as the value part of an Interface Addresses 1108 APPsub-TLV [RFC7961]. The maximum size of such contents 1109 is 255 bytes, in which case the RESPONSE Record SIZE 1110 field is 255. 1112 Multiple RESPONSE Records can appear in a Response Message with the 1113 same Index if an answer to the QUERY Record consists of multiple 1114 Interface Address APPsub-TLV values. This would be necessary if, for 1115 example, a MAC address within a Data Label appears to be reachable by 1116 multiple TRILL switches. However, all RESPONSE Records to any 1117 particular QUERY Record MUST occur in the same Response Message. If a 1118 Pull Directory holds more mappings for a queried address than will 1119 fit into one Response Message, it selects which to include by some 1120 method outside the scope of this document and sets the overflow flag 1121 (OV) in all of the RESPONSE Records responding to that query address. 1123 See Section 3.6 for a discussion of how errors are handled. 1125 3.2.2.2 Pull Directory Forwarding 1127 Query Messages with QTYPEs 2 and 5 are interpreted and handled as 1128 described below. In these cases, if the information implicitly sought 1129 is not in the directory and the FR flag in the query message was one, 1130 the provided frame is forwarded by the Pull Directory server as a 1131 multi-destination TRILL Data packet with the ingress nickname of the 1132 Pull Directory server (or proxy if it is hosted on an end station) in 1133 the TRILL header. If the FR flag is zero, the frame is not forwarded 1134 in this case. 1136 If there was no error in the handling of the enclosing Query Message, 1137 the Pull Directory server forwards the frame inside that QUERY 1138 Record, after modifying it in some cases, as described below: 1140 ARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates 1141 that an ARP [RFC826] frame is included in the Record: The ar$op 1142 field MUST be ares_op$REQUEST and for the response described in 1143 3.2.2.1, this is treated as a query for the target protocol 1144 address where the AFN of that address is given by ar$pro. (ARP 1145 field and value names with embedded dollar signs are specified in 1146 [RFC826].) If ar$op is not ares_op$REQUEST or the ARP is malformed 1147 or the query fails, an error is returned. Otherwise the ARP is 1148 modified into the appropriate ARP response that is then sent by 1149 the Pull Directory server as a TRILL Data packet. 1151 ND/SEND: When QTYPE is 2 and the Ethertype in the QUERY Record 1152 indicates an IPv6 Neighbor Discover (ND [RFC4861]) or Secure 1153 Neighbor Discover (SEND [RFC3971]) frame is included in the 1154 Record: Only Neighbor Solicitation ND frames (corresponding to an 1155 ARP query) are allowed. An error is returned for other ND frames 1156 or if the target address is not found. Otherwise, if the ND is not 1157 a SEND, an ND Neighbor Advertisement response is returned by the 1158 Pull Directory server as a TRILL Data packet. In the case of SEND 1159 [RFC3971], an error is returned indicating that SEND was received 1160 by the Pull Directory and the Pull Directory then either forwards 1161 the SEND frame to the holder of the IPv6 address if that 1162 information is in the directory or the directory multicasts the 1163 SEND frame. 1165 RARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates 1166 that a RARP [RFC903] frame is included in the Record: If the ar$op 1167 field is ares_op$REQUEST, the frame is handled as an ARP as 1168 described above. Otherwise the ar$op field MUST be 'reverse 1169 request' and for the response described in 3.2.2.1, this is 1170 treated as a query for the target hardware address where the AFN 1171 of that address is given by ar$hrd. (See [RFC826] for RARP 1172 fields.) If ar$op is not one of these values or the RARP is 1173 malformed or the query fails, an error is returned. Otherwise the 1174 RARP is modified into the appropriate RARP response that is then 1175 unicast by the Pull Directory server as a TRILL Data packet to the 1176 source hardware MAC address. 1178 MacDA: When QTYPE is 5, indicating a frame is provided in the QUERY 1179 Record whose destination MAC address TRILL switch attachment is 1180 unknown, the only requirement is that this MAC address has to be 1181 unicast. The Ethertype in the QUERY Record is ignored. If it is 1182 group addressed an error is returned. For the response described 1183 in 3.2.2.1, it is treated as a query for the MacDA. If the Pull 1184 Directory contains TRILL switch attachment information for the MAC 1185 address in the Data Label of the Query Message, it forwards the 1186 frame to that switch in a unicast TRILL Data packet. 1188 3.3 Cache Consistency 1190 Unless it sends all responses with a Lifetime of zero, a Pull 1191 Directory MUST take action, by sending Update Messages, to minimize 1192 the amount of time that a TRILL switch will continue to use stale 1193 information from that Pull Directory. The format of Update Messages 1194 and the Acknowledge Messages used to respond to Update Messages are 1195 given in Sections 3.3.1 and 3.3.2. 1197 A Pull Directory server MUST maintain one of three sets of records 1198 concerning possible cached data at clients of that server. These are 1199 numbered and listed below in order of increasing specificity: 1201 Method 1, Least Specific. An overall record per Data Label of when 1202 the last positive response data sent will expire and when the 1203 last negative response sent will expire; the records are 1204 retained until such expiration. 1205 Pro: Minimizes the record keeping burden on the Pull 1206 Directory server. 1207 Con: Increases the volume of and overhead due to spontaneous 1208 Update Messages and due to unnecessarily invalidating cached 1209 information. 1211 Method 2, Medium Specificity. For each unit of data (IA APPsub-TLV 1212 Address Set [RFC7961]) held by the server, record when the last 1213 response sent with that positive response data will expire. In 1214 addition, record each address about which a negative response 1215 was sent by the server and when the last such negative response 1216 will expire. Each such record of a positive or negative response 1217 is discarded upon expiration. 1218 Pro/Con: An intermediate level of detail in server record 1219 keeping and an intermediate volume of and overhead due to 1220 spontaneous Update Messages with some unnecessary invalidation 1221 of cached information. 1223 Method 3, Most Specific. For each unit of data held by the server 1224 (IA APPsub-TLV Address Set [RFC7961]) and each address about 1225 which a negative response was sent, a list of TRILL switches 1226 that were sent that data as a positive response or sent a 1227 negative response for the address, and the expected time to 1228 expiration for that data or address at each such TRILL switch, 1229 assuming the requester cached the response. Each list entry is 1230 retained until such expiration time. 1231 Pro: Minimizes spontaneous Update Messages sent to update 1232 pull client TRILL switch caches and minimizes unnecessary 1233 invalidation of cached information. 1234 Con: Increased record keeping burden on the Pull Directory 1235 server. 1237 RESPONSE Records sent with a zero lifetime are considered to have 1238 already expired and so do not need to be tracked. In all cases, there 1239 may still be brief periods of time when directory information has 1240 changed, but information a pull client has cached has not yet been 1241 updated or expunged. 1243 A Pull Directory server might have a limit as to how many TRILL 1244 switches for which it can maintain detailed expiry information by 1245 method 3 above or how many data units or addresses it can maintain 1246 expiry information for by method 2 or the like. If such limits are 1247 exceeded, it MUST transition to a lower numbered method but, in all 1248 cases, MUST support, at a minimum, method 1, and SHOULD support 1249 methods 2 and 3. Use of method 1 may be quite inefficient due to 1250 large amounts of cached positive and negative information being 1251 unnecessarily discarded. 1253 When data at a Pull Directory is changed, deleted, or added and there 1254 may be unexpired stale information at a requesting TRILL switch, the 1255 Pull Directory MUST send an Update Message as discussed below. The 1256 sending of such an Update Message MAY be delayed by a configurable 1257 number of milliseconds (DirUpdateDelay, see Section 3.9) to await 1258 other possible changes that could be included in the same Update. 1260 1. If method 1, the least detailed method, is being followed, then 1261 when any Pull Directory information in a Data Label is changed 1262 or deleted and there are outstanding cached positive data 1263 response(s), an all-addresses flush positive data Update Message 1264 is flooded within that Data Label as an RBridge Channel Message. 1265 Similarly if data is added and there are outstanding cached 1266 negative responses, an all-addresses flush negative message is 1267 similarly flooded. The Count field is zero in an Update Message 1268 indicates "all-addresses". On receiving an all-addresses flooded 1269 flush positive Update from a Pull Directory server it has used, 1270 indicated by the F and P bits being one and the Count being 1271 zero, a TRILL switch discards the cached data responses it has 1272 for that Data Label. Similarly, on receiving an all addresses 1273 flush negative Update, indicated by the F and N bits being one 1274 and the Count being zero, it discards all cached negative 1275 replies for that Data Label. A combined flush positive and 1276 negative can be flooded by having all of the F (flood), P 1277 (positive), and N (negative) bits (see Section 3.3.1) set to one 1278 and the Count field zero resulting in the discard of all 1279 positive and negative cached information for the Data Label. 1281 2. If method 2 is being followed, then a TRILL switch floods 1282 address specific positive Update Messages when data that might 1283 be cached by a querying TRILL switch is changed or deleted and 1284 floods address specific negative Update Messages when such 1285 information is added to. Such messages are sent as RBridge 1286 Channel messages. The F bit will be one; however, the Count 1287 field will be non-zero and either the P or N bit, but not both, 1288 will be one. There are actually four possible message types 1289 that can be flooded: 1291 2.a If data that might still be cached is updated: 1292 An unsolicited Update Message is sent with the P flag 1293 set and the Err field zero. On receipt, the addresses in the 1294 RESPONSE Records are compared to the addresses for which the 1295 receiving TRILL switch is holding cached positive 1296 information from that server. If they match, the cached 1297 information is updated. 1299 2.b If data that might still be cached is deleted: 1300 An unsolicited Update Message is sent with the P flag 1301 set and the Err field non-zero giving the error that would 1302 now be encountered in attempting to pull information for the 1303 relevant address from the Pull Directory server. In this 1304 non-zero Err field case, the RESPONSE Record(s) differ from 1305 non-zero Err Reply Message RESPONSE Records in that they do 1306 include an interface address set. Any cached positive 1307 information for the addresses given is deleted and the 1308 negative response is cached as per the lifetime given. 1310 2.c If data for an address for which a negative response was 1311 sent is added, so that negative response that might still be 1312 cached is now incorrect: 1313 An unsolicited Update Message is sent with the N flag 1314 set to one and the Err field zero. The addresses in the 1315 RESPONSE Records are compared to the addresses for which the 1316 receiving TRILL switch is holding cached negative 1317 information from that server; if they match, the cached 1318 negative information is deleted and the positive information 1319 provided is cached as per the lifetime given. 1321 2.d In the rare case where it is desired to change the lifetime 1322 or error associated with negative information that might 1323 still be cached: 1324 An unsolicited Update Message is sent with the N flag 1325 set to one and the Err field non-zero. As in case 2.b above, 1326 the RESPONSE Record(s) give the relevant addresses. Any 1327 cached negative information for the address is updated. 1329 3. If method 3 is being followed, the same sort of unsolicited 1330 Update Messages are sent as with method 2 above except they are 1331 not normally flooded but unicast only to the specific TRILL 1332 switches the directory server believes may be holding the cached 1333 positive or negative information that needs deletion or 1334 updating. However, a Pull Directory server MAY flood unsolicited 1335 updates under method 3, for example if it determines that a 1336 sufficiently large fraction of the TRILL switches in some Data 1337 Label are requesters that need to be updated so that flooding is 1338 more efficient that unicast. 1340 A Pull Directory server tracking cached information with method 3 1341 MUST NOT clear the indication that it needs to update cached 1342 information at a querying TRILL switch until it has either (a) sent 1343 an Update Message and received a corresponding Acknowledge Message or 1344 (b) it has sent a configurable number of updates at a configurable 1345 interval that default to 3 updates 100 milliseconds apart (see 1346 Section 3.9). 1348 A Pull Directory server tracking cached information with methods 2 or 1349 1 SHOULD NOT clear the indication that it needs to update cached 1350 information until it has sent an Update Message and received a 1351 corresponding Acknowledge Message from all of its ESADI neighbors or 1352 it has sent a number of updates at an interval as in the paragraph 1353 above. 1355 3.3.1 Update Message Format 1357 An Update Message is formatted as a Response Message with the 1358 differences described in Section 3.3 above and the following: 1360 o The Type field in the message header is set to 3. 1361 o The Index field in the RESPONSE Record(s) is set to zero on 1362 transmission and ignored on receipt (but the Count field in the 1363 Update Message header MUST still correctly indicate the number of 1364 RESPONSE Records present). 1365 o The priority with which the message is sent, DirUpdatePriority, is 1366 configurable and defaults to 5 (see Section 3.9). 1368 Update Messages are initiated by a Pull Directory server. The 1369 Sequence number space used is controlled by the originating Pull 1370 Directory server. This update Sequence number space is different from 1371 the Sequence number space used in a Query and the corresponding 1372 Response that are controlled by the querying TRILL switch. 1374 The 4-bit Flags field of the message header for an Update Message is 1375 as follows: 1377 +---+---+---+---+ 1378 | F | P | N | R | 1379 +---+---+---+---+ 1381 F: The Flood bit. If zero, the Update Message is unicast. If F=1, it 1382 is multicast to All-Egress-RBridges. 1384 P, N: Flags used to indicate positive or negative Update Messages. 1385 P=1 indicates positive. N=1 indicates negative. Both may be 1 for 1386 a flooded all addresses Update. 1388 R: Reserved. MUST be sent as zero and ignored on receipt 1390 For tracking methods 2 and 3 in Section 3.3.1, a particular Update 1391 Message MUST have either the P flag or the N flag set but not both. 1392 If both are set, the Update Message MUST be ignored as this 1393 combination is only valid for method 1. 1395 3.3.2 Acknowledge Message Format 1397 An Acknowledge Message is sent in response to an Update Message to 1398 confirm receipt or indicate an error, unless response is inhibited by 1399 rate limiting. It is formatted as a Response Message but the Type is 1400 set to 4. 1402 If there are no errors in the processing of an Update Message or if 1403 there is a message level overall or header error in an Update 1404 Message, the message is echoed back with the Err and SubErr fields 1405 set appropriately, the Type changed to Acknowledge, and a null 1406 records section with the Count field set to zero. 1408 If there is a record level error in an Update Message, one or more 1409 Acknowledge Messages may be returned with the erroneous record(s) 1410 indicated as discussed in Section 3.6. 1412 The Acknowledge Messages is sent with the same priority as the Update 1413 Message it acknowledges but not more than a configured priority 1414 (DirAckMaxPriority) that defaults to 5 (see Section 3.9). 1416 3.4 Summary of Records Formats in Messages 1418 As specified in Section 3.2 and 3.3, the Query, Response, Update, and 1419 Acknowledge Messages can have zero or more repeating Record 1420 structures under different circumstances, as summarized below. The 1421 "Err" column abbreviations in this table have the meanings listed 1422 below. "IA APPsub-TLV value" means the value part of the IA APPsub- 1423 TLV specified in [RFC7961]. 1425 MBZ = MUST be zero 1426 Z = zero 1427 NZ = non-zero 1428 NZM = non-zero message level error 1429 NZR = non-zero record level error 1431 Message Err Section Record Structure Response Data 1432 ----------- --- ------- ---------------- ------------------ 1433 Query MBZ 3.2.1 QUERY Record - 1434 Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value 1435 Response NZM 3.2.2.1 null - 1436 Response NZR 3.2.2.1 RESPONSE Record Records with error 1437 Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value 1438 Acknowledge Z 3.3.2 null - 1439 Acknowledge NZM 3.3.2 null - 1440 Acknowledge NZR 3.3.2 RESPONSE Record Records with error 1442 See Section 3.6 for further details on errors. 1444 3.5 End Stations and Pull Directories 1446 A Pull Directory can be hosted on an end station as specified in 1447 Section 3.5.1. 1449 A end station can use a Pull Directory as specified in Section 3.5.2. 1450 This capability would be useful in supporting an end station that 1451 performs directory assisted encapsulation [DirAsstEncap] or that is a 1452 "smart end node" [SmartEN]. 1454 The native Pull Directory messages used in these cases are as 1455 specified in Section 3.5.3. In these cases, the edge RBridge(s) and 1456 end station(s) involved need to detect each other and exchange some 1457 control information. This is accomplished with the TRILL ES-IS 1458 mechanism specified in Section 5. 1460 3.5.1 Pull Directory Hosted on an End Station 1462 Optionally, a Pull Directory actually hosted on an end station MAY be 1463 supported. In that case, one or more TRILL switches must act as 1464 indirect Pull Directory servers. That is, they host a Pull Directory 1465 server, which is seen by other TRILL switches in the campus, and a 1466 Pull Directory client, which fetches directory information from one 1467 or more End Station Pull Directory servers, where at least some of 1468 the information served up by the Pull Directory server may be 1469 information fetched from an end station to which it is directly 1470 connected by the co-located Pull Directory client. (Direct connection 1471 means a connection not involving any intermediate TRILL switches.) 1473 End stations hosting a Pull Directory server MUST support TRILL ES-IS 1474 (see Section 5) and advertise the Data Labels for which they are 1475 providing service in one or more Interested VLAN or Interested Label 1476 sub-TLVs by setting the PUL flag (see Section 7.3). 1478 * * * * * * * 1479 +---------------+ * * 1480 | End Station 1 | +---------------+ * 1481 | Pull Directory+--------------+ RB1, Pull | * 1482 | Server | | Directory| * 1483 +---------------+ +-------+ Client|Server | +----+ 1484 | +---------------+ |RB99| 1485 +---------------+ | * +----+ 1486 | End Station 2 | +--+---+ +---------------+ * 1487 | Pull Directory+---+Bridge+---+ RB2, Pull | * 1488 | Server | +--+---+ | Directory| * 1489 +---------------+ | | Client|Server | * 1490 | +---------------+ * 1491 | * TRILL * 1492 . * Campus * 1493 . * * 1494 . * * * * * * * 1496 Figure 2. End Station Pull Directory Example 1498 The figure above gives an example where RB1 and RB2 advertise 1499 themselves to the rest of the TRILL campus, such as RB99, as Pull 1500 Directory servers and obtain at least some of the information they 1501 are serving up by issuing Pull Directory queries to end stations 1 1502 and/or 2. This example is specific but many variations are possible. 1503 The Bridge shown might be a complex bridged LAN, a LAN without a 1504 bridge (as shown for End Station 1), or connected via point-to-point 1505 links (as shown for End Station 2 that is connected through a bridge 1506 with point-to-point Ethernet links to RB1 and RB2). There could be 1507 one or more than two RBridges having such indirect Pull Directory 1508 servers. Furthermore, there could be one or more than two end 1509 stations with Pull Directory servers on them. Each TRILL switch 1510 server could then be differently configured as to the Data Labels for 1511 which it is providing indirect service selected from the union of the 1512 Data Labels supported by the End Station hosted servers and could 1513 select from among those End Station hosted servers supporting each 1514 Data Label the indirect server is configured to serve up. 1516 When an indirect Pull Directory server receives a Query Message from 1517 another TRILL switch, it answers from information it has cached or 1518 issues Pull Directory request to End Station Pull Directory servers 1519 with which it has TRILL ES-IS adjacency to obtain the information. 1520 Any Response sent by an indirect Pull Directory server MUST NOT have 1521 a validity time longer that the valid of the data on which it is 1522 based. When an indirect Pull Directory server receives Update 1523 Messages, it updates its cached information and MUST originate Update 1524 messages to any clients that may have mirrors of the cached 1525 information so updated. 1527 Since an indirect Pull Directory server discards information it has 1528 cached from queries to an end station Pull Directory server if it 1529 loses adjacency to the server (Section 3.7), if it detects that such 1530 information may be cached at RBridge clients and has no other source 1531 for the information, it MUST send Update Messages to those clients 1532 withdrawing the information. For this reason, indirect Pull Directory 1533 servers may wish to query multiple sources, if available, and cache 1534 multiple copies of returned information from those multiple sources. 1535 Then if one end station source becomes inaccessible or withdraws the 1536 information but the indirect Pull Directory server has the 1537 information from another source, it need not originate Updates. 1539 3.5.2 Use of Pull Directory by End Stations 1541 Some special end stations, such as those discussed in [DirAsstEncap] 1542 and [SmartEN], may need to access directory information. How edge 1543 RBridges provide this optional service is specified below. 1545 When Pull Directory support is provided by an edge RBridge to end 1546 stations, the messages used are as specified in Section 3.5.3 below. 1547 The edge RBridge MUST support TRILL ES-IS (Section 5) and advertises 1548 the Data Labels for which it offers this service to end stations by 1549 setting the Pull Directory flag (PUL) to one in its Interested VLANs 1550 or Interested Labels sub-TLV (see Section 7.3) for that Data Label 1551 advertised through TRILL ES-IS. 1553 3.5.3 Native Pull Directory Messages 1555 The Pull Directory messages used between TRILL switches and end 1556 stations are native RBridge Channel messages [RFC7178]. These 1557 RBridge Channel messages use the same Channel protocol number as the 1558 inter-RBridge Pull Directory RBridge Channel messages. The Outer.VLAN 1559 ID used is the TRILL ES-IS Designated VLAN (see Section 5) on the 1560 link to the end station. Since there is no TRILL Header or inner Data 1561 Label for native RBridge Channel messages, that information is added 1562 to the Pull Directory message header as specified below. 1564 The native RBridge Channel message Pull Directory message protocol 1565 dependent data part is the same as for inter-RBridge Channel messages 1566 except that the 8-byte header described in Section 3.1 is expanded to 1567 12 or 16 bytes as follows: 1569 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Ver | Type | Flags | Count | Err | SubErr | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Sequence Number | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Data Label ... (4 or 8 bytes) | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1578 | Type Specific Payload - variable length 1579 +-+-+- ... 1581 Fields other than Data Label are as in Section 3.1. The Data Label 1582 that normally appears right after the Inner.MacSA of the an RBridge 1583 Channel Pull Directory message appears in the Data Label field of the 1584 Pull Directory message header in the native RBridge Channel message 1585 version. This Data Label appears in a native Query Message, to be 1586 reflected in a Response Message, or it might appear in a native 1587 Update to be reflected in an Acknowledge Message. Since the 1588 appropriate VLAN or FGL [RFC7172] Ethertype is included, the length 1589 of the Data Label can be determined from the first two bytes. 1591 3.6 Pull Directory Message Errors 1593 A non-zero Err field in the Pull Directory Response or Acknowledge 1594 Message header indicates an error message. 1596 If there is an error that applies to an entire Query or Update 1597 Message or its header, as indicated by the range of the value of the 1598 Err field, then the QUERY Records probably were not even looked at by 1599 the Pull Directory Server and would provide no additional information 1600 in the Response or Acknowledge Message. Therefore, the Records 1601 section of the Query Response or Update Message is omitted and the 1602 Count field is set to zero in the Response or Acknowledgment Message. 1604 If errors occur at the QUERY Record level for a Query Message, they 1605 MUST be reported in a Response Message separate from the results of 1606 any successful non-erroneous QUERY Records. If multiple QUERY Records 1607 in a Query Message have different errors, they MUST be reported in 1608 separate Response Messages. If multiple QUERY Records in a Query 1609 Message have the same error, this error response MAY be reported in 1610 one or multiple Response Messages. In an error Response Message, the 1611 QUERY Record or Records being responded to appear, expanded by the 1612 Lifetime for which the server thinks the error might persist (usually 1613 2**16-1 which indicates indefinitely) and with their Index inserted, 1614 as the RESPONSE Record or Records. 1616 If errors occur at the RESPONSE Record level for an Update Message, 1617 they MUST be reported in an Acknowledge Message separate from the 1618 acknowledgment of any non-erroneous RESPONSE Records. If multiple 1619 RESPONSE Records in an Update have different errors, they MUST be 1620 reported in separate Acknowledge Messages. If multiple RESPONSE 1621 Records in an Update Message have the same error, this error response 1622 MAY be reported in one or multiple Acknowledge Messages. In an error 1623 Acknowledge Message, the RESPONSE Record or Records being responded 1624 to appear, expanded by the time for which the server thinks the error 1625 might persist and with their Index inserted, as a RESPONSE Record or 1626 Records. 1628 Err values 1 through 126 are available for encoding Request or Update 1629 Message level errors. Err values 128 through 254 are available for 1630 encoding QUERY or RESPONSE Record level errors. The SubErr field is 1631 available for providing more detail on errors. The meaning of a 1632 SubErr field value depends on the value of the Err field. 1634 3.6.1 Error Codes 1636 The following table lists error code values for the Err field, their 1637 meaning, and whether they apply at the Message or Record level. 1639 Err Level Meaning 1640 ------ ------- ------- 1641 0 - No Error 1643 1 Message Unknown or reserved Query Message field value 1644 2 Message Request Message/data too short 1645 3 Message Unknown or reserved Update Message field value 1646 4 Message Update Message/data too short 1647 5-126 Message Unassigned 1648 127 - Reserved 1650 128 Record Unknown or reserved QUERY Record field value 1651 129 Record QUERY Record truncated 1652 130 Record Address not found 1653 131 Record Unknown or reserved RESPONSE Record field value 1654 132 Record RESPONSE Record truncated 1655 133-254 Record Unassigned 1656 255 - Reserved 1658 Note that some error codes are for overall message level errors while 1659 some are for errors in the repeating records that occur in messages. 1661 3.6.2 Sub-Errors Under Error Codes 1 and 3 1663 The following sub-errors are specified under error codes 1 and 3: 1665 SubErr Field with Error 1666 ------ ---------------- 1667 0 Unspecified 1668 1 Version not understood (see Section 3.1.1) 1669 2 Unknown Type field value 1670 3 Specified Data Label not being served 1671 4-254 Unassigned 1672 255 Reserved 1674 3.6.3 Sub-Errors Under Error Codes 128 and 131 1676 The following sub-errors are specified under error code 128 and 131: 1678 SubErr Field with Error 1679 ------ ---------------- 1680 0 Unspecified 1681 1 Unknown AFN field value 1682 2 Unknown or Reserved QTYPE field value 1683 3 Invalid or inconsistent SIZE field value 1684 4 Invalid frame for QTYPE 2 (other than SEND) 1685 5 SEND frame sent as QTYPE 2 1686 6 Invalid frame for QTYPE 5 (such as multicast MacDA) 1687 7-254 Unassigned 1688 255 Reserved 1690 3.7 Additional Pull Details 1692 A Pull Directory client MUST notice, by tracking link state changes, 1693 when a Pull Directory server is no longer accessible (data reachable 1694 [RFC7780] for the inter-RBridge case or TRILL ES-IS (Section 5) 1695 adjacent for end station to RBridge case), and MUST promptly discard 1696 all pull responses it is retaining from that server as it can no 1697 longer receive cache consistency Update Messages from the server. 1699 A secondary Pull Directory server is one that obtains its data from a 1700 primary directory server. See discussion of primary to secondary 1701 directory information transfer in Section 2.6. 1703 3.8 The No Data Flag 1705 In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], 1706 the mere presence of an Interested VLANs or Interested Labels sub- 1707 TLVs in the LSP of a TRILL switch indicates connection to end 1708 stations in the VLAN(s) or FGL(s) listed and thus a need to receive 1709 multi-destination traffic in those Data Labels. However, with Pull 1710 Directories, advertising that you are a directory server requires 1711 using these sub-TLVs to indicate the Data Label(s) you are serving. 1713 If a directory server does not wish to received multi-destination 1714 TRILL Data packets for the Data Labels it lists in one of the 1715 Interested VLAN or Interested FGL [RFC7172] sub-TLVs, it sets the "No 1716 Data" (NOD) bit to one (see Section 7.3). This means that data on a 1717 distribution tree may be pruned so as not to reach the "No Data" 1718 TRILL switch as long as there are no TRILL switches interested in the 1719 Data Label that are beyond the "No Data" TRILL switch on that 1720 distribution tree. The NOD bit is backwards compatible as TRILL 1721 switches ignorant of it will simply not prune when they could, which 1722 is safe although it may cause increased link utilization by some 1723 sending multi-destination traffic where it is not needed. 1725 Push Directories advertise themselves inside ESADI which normally 1726 requires the ability to send and receive multi-destination TRILL Data 1727 packets but can be implemented with serial unicast. 1729 Examples of a TRILL switch serving as a directory that might not want 1730 multi-destination traffic in some Data Labels would be a TRILL switch 1731 that does not offer end station service for any of the Data Labels 1732 for which it is serving as a directory and is either 1733 - a Pull Directory and/or 1734 - a Push Directory for one or more Data Labels where all of the 1735 ESADI traffic for those Data Labels will be handled by unicast 1736 ESADI [RFC7357]. 1738 A Push Directory MUST NOT set the NOD bit for a Data Label if it 1739 needs to communicate via multi-destination ESADI or RBridge Channel 1740 PDUs in that Data Label since such PDUs look like TRILL Data packets 1741 to transit TRILL switches and are likely to be incorrectly pruned if 1742 NOD was set. 1744 3.9 Pull Directory Service Configuration 1746 The following per RBridge scalar configuration parameters are 1747 available for controlling Pull Directory service behavior. In 1748 addition, there is a configurable per Data Label mapping from the 1749 priority of a native frame being ingress to the priority of any Pull 1750 Directory query it causes. The default such mapping depends on the 1751 client strategy as described in Section 4. 1753 Name Default Section Note Below 1754 ------------------ ------- ------- ---------- 1756 DirQueryTimeout 100 milliseconds 3.2.1 1 1757 DirQueryRetries 3 3.2.1 1 1758 DirGenQPriority 5 3.2.1 2 1760 DirRespMaxPriority 6 3.2.2.1 3 1762 DirUpdateDelay 50 milliseconds 3.3 1763 DirUpdatePriority 5 3.3.1 1764 DirUpdateTimeout 100 milliseconds 3.3.3 1765 DirUpdateRetries 3 3.3.3 1767 DirAckMaxPriority 5 3.3.2 4 1769 Note 1: Pull Directory Query client timeout waiting for response and 1770 maximum number of retries 1771 Note 2: Priority for client generated requests (such as a query to 1772 refresh cached information). 1774 Note 3: Pull Directory Response Messages SHOULD NOT be sent with 1775 priority 7 as that priority SHOULD be reserved for messages critical 1776 to network connectivity. 1778 Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent with 1779 priority 7 as that priority SHOULD be reserved for messages critical 1780 to network connectivity. 1782 4. Directory Use Strategies and Push-Pull Hybrids 1784 For some edge nodes that have a great number of Data Labels enabled, 1785 managing the MAC and Data Label <-> Edge RBridge mapping for hosts 1786 under all those Data Labels can be a challenge. This is especially 1787 true for Data Center gateway nodes, which need to communicate with 1788 many, if not all, Data Labels. 1790 For those edge TRILL switch nodes, a hybrid model should be 1791 considered. That is, the Push Model is used for some Data Labels or 1792 addresses within a Data Label while the Pull Model is used for other 1793 Data Labels or addresses within a Data Label. It is the network 1794 operator's decision by configuration as to which Data Labels' mapping 1795 entries are pushed down from directories and which Data Labels' 1796 mapping entries are pulled. 1798 For example, assume a data center where hosts in specific Data 1799 Labels, say VLANs 1 through 100, communicate regularly with external 1800 peers. Probably, the mapping entries for those 100 VLANs should be 1801 pushed down to the data center gateway routers. For hosts in other 1802 Data Labels that only communicate with external peers occasionally 1803 for management interfacing, the mapping entries for those VLANs 1804 should be pulled down from directory when the need comes up. 1806 Similarly, it could be that within a Data Label that some addresses, 1807 such as the addresses of gateways, file, DNS, or database server 1808 hosts are commonly referenced by most other hosts but those other 1809 hosts, perhaps compute engines, are typically only referenced by a 1810 few hosts in that Data Label. In that case, the address information 1811 for the commonly referenced hosts could be pushed as an incomplete 1812 directory while the addresses of the others are pulled when needed. 1814 The mechanisms described in this document for Push and Pull Directory 1815 services make it easy to use Push for some Data Labels or addresses 1816 and Pull for others. In fact, different TRILL switches can even be 1817 configured so that some use Push Directory services and some use Pull 1818 Directory services for the same Data Label if both Push and Pull 1819 Directory services are available for that Data Label. And there can 1820 be Data Labels for which directory services are not used at all. 1822 There are a wide variety of strategies that a TRILL switch can adopt 1823 for making use of directory assistance. A few suggestions are given 1824 below. 1826 - Even if a TRILL switch will normally be operating with 1827 information from a complete Push Directory server, there will be a 1828 period of time when it first comes up before the information it 1829 holds is complete. Or, it could be that the only Push Directories 1830 that can push information to it are incomplete or that they are 1831 just starting and may not yet have pushed the entire directory. 1833 Thus, it is RECOMMENDED that all TRILL switches have a strategy 1834 for dealing with the situation where they do not have complete 1835 directory information. Examples are to send a Pull Directory query 1836 or to revert to [RFC6325] behavior. 1838 - If a TRILL switch receives a native frame X resulting in 1839 seeking directory information, a choice needs to be made as to 1840 what to do if it does not already have the directory information 1841 it needs. In particular, it could (1) immediately flood the TRILL 1842 Data packet resulting from ingressing X in parallel with seeking 1843 the directory information, (2) flood that TRILL Data packet after 1844 a delay, if it fails to obtain the directory information, or (3) 1845 discard X if it fails to obtain the information. The choice might 1846 depend on the priority of frame X since the higher that priority 1847 typically the more urgent the frame is and the greater the 1848 probability of harm in delaying it. If a Pull Directory request is 1849 sent, it is RECOMMENDED that its priority be derived from the 1850 priority of the frame X with the derived priority configurable and 1851 having the following defaults: 1853 Ingressed If Flooded If Flooded 1854 Priority Immediately After Delay 1855 -------- ----------- ----------- 1856 7 5 6 1857 6 5 6 1858 5 4 5 1859 4 3 4 1860 3 2 3 1861 2 0 2 1862 0 1 0 1863 1 1 1 1865 NOTE: The odd looking numbers towards the bottom of the columns 1866 above are because priority 1 is lower than priority zero. That is 1867 to say, the values in the first column are in priority order. They 1868 will look more logical if you think of "0" as being "1 1/2". 1870 Priority 7 is normally only used for urgent messages critical to 1871 adjacency and so SHOULD NOT be the default for directory traffic. 1872 Unsolicited updates are sent with a priority that is configured per 1873 Data Label that defaults to priority 5. 1875 5. TRILL ES-IS 1877 TRILL ES-IS (End System to Intermediate System) is a variation of 1878 TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a 1879 TRILL link among and between one or more TRILL switches and end 1880 stations on that link. Support of TRILL ES-IS is generally optional 1881 for both the TRILL switches and the end stations on a link but may be 1882 required to support certain features. As of the date of this 1883 document, the only features requiring TRILL ES-IS are those listed in 1884 this Section 5. 1886 TRILL ES-IS is useful in supporting Pull Directory hosting on or use 1887 from end stations (see Section 3.5) and supporting specialized end 1888 stations [DirAsstEncap] [SmartEN] and may have additional future 1889 uses. The advantages of TRILL ES-IS over simply making an "end 1890 station" be a TRILL Switch include relieving the end station of 1891 having to maintain a copy of the core link state database (LSPs) and 1892 of having to perform routing calculations or having the ability to 1893 forward traffic. 1895 Except as provided below in this Section 5, TRILL ES-IS PDUs and TLVs 1896 are the same TRILL IS-IS PDUs and TLVs. 1898 5.1 PDUs and System IDs 1900 All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs which 1901 may be unicast) are multicast using the TRILL-ES-IS multicast MAC 1902 address (see Section 7.6). This use of a different multicast address 1903 assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused 1904 for one another. 1906 Because end stations do not have IS-IS System IDs, TRILL ES-IS uses 1907 port MAC addresses in their place. This is convenient since MAC 1908 addresses are 48-bit and almost all IS-IS implementations use 48-bit 1909 System IDs. Logically TRILL IS-IS operates between the TRILL switches 1910 in a TRILL campus as identified by System ID while TRILL ES-IS 1911 operates between Ethernet ports on an Ethernet link (which may be a 1912 bridged LAN) as identified by MAC address [RFC6325]. 1914 As System IDs of TRILL Switches in a campus are required to be 1915 unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be 1916 unique. 1918 5.2 Adjacency, DRB Election, Hellos, TLVs, Etc. 1920 TRILL ES-IS Adjacency formation and DRB election operate between the 1921 ports on the link as specified in [RFC7177] for a broadcast link. 1922 The DRB specifies an ES-IS Designated VLAN for the link. This 1923 adjacency determination, DRB election, and Designated VLAM are 1924 distinct from TRILL IS-IS adjacency, DRB election, and Designated 1925 VLAN. 1927 Although the "Report State" [RFC7177] exists for TRILL ES-IS 1928 adjacencies, such adjacencies are only reported in TRILL ES-IS LSPs, 1929 not in any TRILL IS-IS LSPs. 1931 End stations supporting TRILL ES-IS MUST assign a unique Port ID to 1932 each of their TRILL ES-IS ports which appears in the TRILL ES-IS 1933 Hellos they send. 1935 TRILL ES-IS has nothing to do with Appointed Forwarders and the 1936 Appointed Forwarders sub-TLV and VLANs Appointed sub-TLV [RFC7176] 1937 are not used and SHOULD NOT be sent in TRILL ES-IS; if such a sub-TLV 1938 is received in TRILL ES-IS it is ignored. (The Appointed Forwarders 1939 on a link are determined as specified in [rfc6439bis] using TRILL IS- 1940 IS.) 1942 Although some of the ports sending TRILL ES-IS PDUs are on end 1943 stations and thus not on routers (TRILL switches), they nevertheless 1944 may make use of the Router Capability (#242) and MT-Capability (#222) 1945 IS-IS TLVs to indicate capabilities as specified in [RFC7176]. 1947 TRILL ES-IS Hellos are like TRILL IS-IS Hellos but note the 1948 following: In the Special VLANs and Flags Sub-TLV, any TRILL switches 1949 advertise a nickname they own but for end stations that field MUST be 1950 sent as zero and ignored on receipt. In addition, the AF and TR flag 1951 bits MUST be sent as zero and the AC flag bit MUST be sent as one and 1952 all three are ignored on receipt. 1954 5.3 Link State 1956 The only link state transmission and synchronization that occurs in 1957 TRILL ES-IS is for E-L1CS PDUs (Extended Level 1 Circuit Scoped 1958 [RFC7356]). In particular, the end station Ethernet ports supporting 1959 TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not 1960 support E-L1FS LSPs (or the CSNPs or PSNPs corresponding to either of 1961 them). TLVs and sub-TLVs that would otherwise be sent in TRILL IS-IS 1962 LSPs or E-L1FS SPs are instead sent in E-L1CS LSPs. 1964 6. Security Considerations 1966 For general TRILL security considerations, see [RFC6325]. 1968 6.1 Directory Information Security 1970 Incorrect directory information can result in a variety of security 1971 threats including those below. Directory servers therefore need to 1972 take care to implement and enforce access control policies that are 1973 not overly permissive. 1975 Incorrect directory mappings can result in data being delivered to 1976 the wrong end stations, or set of end stations in the case of 1977 multi-destination packets, violating security policy. 1979 Missing, incorrect, or inaccessible directory data can result in 1980 denial of service due to sending data packets to black holes or 1981 discarding data on ingress due to incorrect information that their 1982 destinations are not reachable or that their source addresses are 1983 forged. 1985 For these reasons directory information needs to be protected from 1986 unauthorized modification whatever server or end station it resides 1987 on. Parties authorized to modify directory data can violate 1988 availability and integrity policies. 1990 6.2 Directory Confidentiality and Privacy 1992 In implementations of the base TRILL protocol [RFC6325] [RFC7780], 1993 RBridges deal almost exclusively with MAC addresses. Use of 1994 directories to map to/from IP addresses means that RBridges deal more 1995 actively with IP addresses as well. But RBridges in any case would be 1996 exposed to plain text ARP/ND/SEND/IP traffic and so can see all this 1997 addressing meta-data. So this more explicit dealing with IP addresses 1998 has little effect on the privacy of end station traffic. 2000 Parties authorized to read directory data can violate privacy polices 2001 for such data. 2003 6.3 Directory Message Security Considerations 2005 Push Directory data is distributed through ESADI-LSPs [RFC7357]. 2006 ESADI is built on IS-IS and such data can thus be authenticated with 2007 the widely implemented and deployed IS-IS PDU security. This 2008 mechanism provides authentication and integrity protection. See 2009 [RFC5304] [RFC5310] and the Security Considerations section of 2010 [RFC7357]. 2012 Pull Directory queries and responses are transmitted as RBridge-to- 2013 RBridge or native RBridge Channel messages [RFC7178]. Such messages 2014 can be secured by the mechanisms specified in [RFC7978]. These 2015 mechanisms can provide authentication and confidentiality 2016 protections. At the time of this RFC, these security mechanisms are 2017 believed to be less widely implemented than IS-IS security. 2019 7. IANA Considerations 2021 This section gives IANA assignment and registry considerations. 2023 7.1 ESADI-Parameter Data Extensions 2025 Action 1: IANA is requested to create a sub-registry in the TRILL 2026 Parameters Registry as follows: 2028 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 2029 Registration Procedures: Standards Action 2030 References: [RFC7357] [This document] 2032 Bit Mnemonic Description Reference 2033 --- -------- ----------- --------- 2034 0 UN Supports Unicast ESADI ESADI [RFC7357] 2035 1-2 PDSS Push Directory Server Status [this document] 2036 3-7 - Available for assignment 2038 Action 2: In addition, the ESADI-Parameter APPsub-TLV is optionally 2039 extended, as provided in its original specification in ESADI 2040 [RFC7357], by one byte as show below. Therefore [this document] 2041 should be added as a second reference to the ESADI-Parameter APPsub- 2042 TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 2043 Identifier 1" Registry. 2045 +-+-+-+-+-+-+-+-+ 2046 | Type | (1 byte) 2047 +-+-+-+-+-+-+-+-+ 2048 | Length | (1 byte) 2049 +-+-+-+-+-+-+-+-+ 2050 |R| Priority | (1 byte) 2051 +-+-+-+-+-+-+-+-+ 2052 | CSNP Time | (1 byte) 2053 +-+-+-+-+-+-+-+-+ 2054 | Flags | (1 byte) 2055 +---------------+ 2056 |PushDirPriority| (optional, 1 byte) 2057 +---------------+ 2058 | Reserved for (variable) 2059 | expansion 2060 +-+-+-+-... 2062 The meanings of all the fields are as specified in ESDADI [RFC7357] 2063 except that the added PushDirPriority is the priority of the 2064 advertising ESADI instance to be a Push Directory as described in 2065 Section 2.3. If the PushDirPriority field is not present (Length = 3) 2066 it is treated as if it were 0x3F. 0x3F is also the value used and 2067 placed here by an TRILL switch whose priority to be a Push Directory 2068 has not been configured. 2070 7.2 RBridge Channel Protocol Numbers 2072 Action 3: IANA is requested to assign a new RBridge Channel protocol 2073 number from the range assignable by Standards Action and update the 2074 subregistry of such protocol number in the TRILL Parameters Registry. 2075 Description is "Pull Directory Services". Reference is [this 2076 document]. 2078 7.3 The Pull Directory (PUL) and No Data (NOD) Bits 2080 Actions 4 and 5: IANA is requested to assign a currently reserved 2081 bits in the Interested VLANs field of the Interested VLANs sub-TLV 2082 and the Interested Labels field of the Interested Labels sub-TLV 2083 [RFC7176] to indicate Pull Directory server (PUL). This bit is to be 2084 added, with this document as reference, to the "Interested VLANs Flag 2085 Bits" and "Interested Labels Flag Bits" subregistries created by 2086 [RFC7357] as shown below after Action 7. 2088 Actions 6 and 7: IANA is requested to assign a currently reserved bit 2089 in the Interested VLANs field of the Interested VLANs sub-TLV and the 2090 Interested Labels field of the Interested Labels sub-TLV [RFC7176] to 2091 indicate No Data (NOD, see Section 3.8). This bit is to be added, 2092 with this document as reference, to the "Interested VLANs Flag Bits" 2093 and "Interested Labels Flag Bits" subregistries created by [RFC7357] 2094 as shown below. 2096 Bits and format suggested for above actions 4 through 7 are shown 2097 below: 2099 Registry: Interested BLANs Flag Bits 2101 Bit Mnemonic Description Reference 2102 --- -------- -------------- --------------- 2103 18 PUL Pull Directory [this document] 2104 19 NOD No Data [this document] 2106 Registry: Interested Labels Flag Bits 2108 Bit Mnemonic Description Reference 2109 --- -------- -------------- --------------- 2110 6 PUL Pull Directory [this document] 2111 7 NOD No Data [this document] 2113 7.4 TRILL Pull Directory QTYPEs 2115 Action 8: IANA is requested to create a new Registry on the 2116 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 2117 page as follows: 2119 Name: TRILL Pull Directory Query Types (QTYPEs) 2120 Registration Procedure: IETF Review 2121 Reference: [this document] 2122 Initial contents as in Section 3.2.1. 2124 7.5 Pull Directory Error Code Registries 2126 Actions 9, 10, and 11: IANA is requested to create a new Registry and 2127 two new indented SubRegistries under that Registry on the 2128 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 2129 page as follows: 2131 Registry 2132 Name: TRILL Pull Directory Errors 2133 Registration Procedure: IETF Review 2134 Reference: [this document] 2136 Initial contents as in Section 3.6.1. 2138 Sub-Registry 2139 Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 2140 Registration Procedure: Expert Review 2141 Reference: [this document] 2143 Initial contents as in Section 3.6.2. 2145 Sub-Registry 2146 Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 2147 Registration Procedure: Expert Review 2148 Reference: [this document] 2150 Initial contents as in Section 3.6.3. 2152 7.6 TRILL-ES-IS MAC Address 2154 Action 12: IANA is requested to assign a TRILL multicast MAC address 2155 from the "TRILL Multicast Addresses" registry on the TRILL Parameters 2156 IANA web page [value 01-80-C2-00-00-47 recommended]. Description is 2157 "TRILL-ES-IS". Reference is [this document]. 2159 Normative References 2161 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 2162 RFC 826, November 1982. 2164 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 2165 Reverse Address Resolution Protocol", STD 38, RFC 903, June 2166 1984 2168 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 2169 Requirement Levels", BCP 14, RFC 2119, March 1997 2171 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2172 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 2174 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2175 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2176 September 2007. 2178 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 2179 Authentication", RFC 5304, October 2008. 2181 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 2182 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 2183 5310, February 2009. 2185 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 2186 Layer-2 Systems", RFC 6165, April 2011. 2188 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 2189 Ghanwani, "Routing Bridges (RBridges): Base Protocol 2190 Specification", RFC 6325, July 2011. 2192 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 2193 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 2194 BCP 141, RFC 7042, October 2013. 2196 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 2197 and D. Dutt, "Transparent Interconnection of Lots of Links 2198 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 2199 . 2201 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 2202 D., and A. Banerjee, "Transparent Interconnection of Lots of 2203 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 2204 . 2206 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 2207 and V. Manral, "Transparent Interconnection of Lots of Links 2208 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 2209 . 2211 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 2212 Ward, "Transparent Interconnection of Lots of Links (TRILL): 2213 RBridge Channel Support", RFC 7178, May 2014, . 2216 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 2217 Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, 2218 September 2014, . 2220 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 2221 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 2222 End Station Address Distribution Information (ESADI) Protocol", 2223 RFC 7357, September 2014, . 2226 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 2227 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 2228 Lots of Links (TRILL): Clarifications, Corrections, and 2229 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 2230 . 2232 [RFC7961] - Eastlake 3rd, D. and L. Yizhou, "Transparent 2233 Interconnection of Lots of Links (TRILL): Interface Addresses 2234 APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016, 2235 . 2237 [rfc6439bis] - D. Eastlake, Y. Li, M. Umair, A. Banerjee, and F. Hu, 2238 "Routing Bridges (RBridges): Appointed Forwarders", draft-ietf- 2239 trill-rfc6439bis, work in progress. 2241 Informational References 2243 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 2244 Gashinsky, "Directory Assistance Problem and High-Level Design 2245 Proposal", RFC 7067, November 2013. 2247 [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent 2248 Interconnection of Lots of Links (TRILL): RBridge Channel 2249 Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2250 2016, . 2252 [ARPND] - Y. Li, D. Eastlake, L. Dunbar, R. Perlman, I. Gashinsky, 2253 "TRILL: ARP/ND Optimization", draft-ietf-trill-arp- 2254 optimization, work in progress. 2256 [DirAsstEncap] L. Dunbar, D. Eastlake, R. Perlman, I. Gashingksy, 2257 "Directory Assisted TRILL Encapsulation", draft-ietf-trill- 2258 directory-assisted-encap, work in progress. 2260 [SmartEN] R. Perlman, F. Hu, D. Eastlake, K. Krupakaran, T. Liao, 2261 "TRILL Smart Endnodes", draft-ietf-trill-smart-endnodes", 2262 draft-ietf-trill-smart-endnodes, work in progress. 2264 [X.233] - ITU-T Recommendation X.233: Protocol for providing the 2265 connectionless-mode network service: Protocol specification, 2266 International Telecommunications Union, August 1997 2268 Acknowledgments 2270 The contributions of the following persons are gratefully 2271 acknowledged: 2273 Amanda Barber, Matthew Bocci, Alissa Cooper, Stephen Farrell, 2274 Daniel Franke, Igor Gashinski, Joel Halpern, Susan Hares, Alexey 2275 Melnikov, Gsyle Noble, Tianran Zhou 2277 The document was prepared in raw nroff. All macros used were defined 2278 within the source file. 2280 Authors' Addresses 2282 Donald Eastlake 2283 Huawei Technologies 2284 155 Beaver Street 2285 Milford, MA 01757, USA 2287 Phone: +1-508-333-2270 2288 Email: d3e3e3@gmail.com 2290 Linda Dunbar 2291 Huawei Technologies 2292 5430 Legacy Drive, Suite #175 2293 Plano, TX 75024, USA 2295 Phone: +1-469-277-5840 2296 Email: ldunbar@huawei.com 2298 Radia Perlman 2299 EMC 2300 2010 256th Avenue NE, #200 2301 Bellevue, WA 98007, USA 2303 Email: Radia@alum.mit.edu 2305 Yizhou Li 2306 Huawei Technologies 2307 101 Software Avenue, 2308 Nanjing 210012, China 2310 Phone: +86-25-56622310 2311 Email: liyizhou@huawei.com 2313 Copyright, Disclaimer, and Additional IPR Provisions 2315 Copyright (c) 2017 IETF Trust and the persons identified as the 2316 document authors. All rights reserved. 2318 This document is subject to BCP 78 and the IETF Trust's Legal 2319 Provisions Relating to IETF Documents 2320 (http://trustee.ietf.org/license-info) in effect on the date of 2321 publication of this document. Please review these documents 2322 carefully, as they describe your rights and restrictions with respect 2323 to this document. Code Components extracted from this document must 2324 include Simplified BSD License text as described in Section 4.e of 2325 the Trust Legal Provisions and are provided without warranty as 2326 described in the Simplified BSD License. The definitive version of 2327 an IETF Document is that published by, or under the auspices of, the 2328 IETF. Versions of IETF Documents that are published by third parties, 2329 including those that are translated into other languages, should not 2330 be considered to be definitive versions of IETF Documents. The 2331 definitive version of these Legal Provisions is that published by, or 2332 under the auspices of, the IETF. Versions of these Legal Provisions 2333 that are published by third parties, including those that are 2334 translated into other languages, should not be considered to be 2335 definitive versions of these Legal Provisions. For the avoidance of 2336 doubt, each Contributor to the IETF Standards Process licenses each 2337 Contribution that he or she makes as part of the IETF Standards 2338 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 2339 language to the contrary, or terms, conditions or rights that differ 2340 from or are inconsistent with the rights and licenses granted under 2341 RFC 5378, shall have any effect and shall be null and void, whether 2342 published or posted by such Contributor, or included with or in such 2343 Contribution.