idnits 2.17.1 draft-ietf-trill-directory-assist-mechanisms-02.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 (May 21, 2015) is 3262 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 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 Igor Gashinsky 7 Yahoo 8 Yizhou Li 9 Huawei 10 Expires: November 20, 2015 May 21, 2015 12 TRILL: Edge Directory Assist Mechanisms 13 15 Abstract 16 This document describes mechanisms for providing directory service to 17 TRILL (Transparent Interconnection of Lots of Links) edge switches. 18 The directory information provided can be used in reducing multi- 19 destination traffic, particularly ARP/ND and unknown unicast 20 flooding. It can also be used to detect traffic with forged source 21 addresses. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the TRILL working group mailing list. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 Uses of Directory Information..........................3 50 1.2 Terminology............................................4 52 2. Push Model Directory Assistance Mechanisms..............6 53 2.1 Requesting Push Service................................6 54 2.2 Push Directory Servers.................................6 55 2.3 Push Directory Server State Machine....................7 56 2.3.1 Push Directory States................................8 57 2.3.2 Push Directory Events and Conditions.................9 58 2.3.3 State Transition Diagram and Table..................10 59 2.4 Additional Push Details...............................12 60 2.5 Primary to Secondary Server Push Service..............13 62 3. Pull Model Directory Assistance Mechanisms.............14 63 3.1 Pull Directory Message Common Format..................15 64 3.2 Pull Directory Query and Response Messages............16 65 3.2.1 Pull Directory Query Message Format.................16 66 3.2.2 Pull Directory Responses............................19 67 3.2.2.1 Pull Directory Response Message Format............19 68 3.2.2.2 Pull Directory Forwarding.........................21 69 3.3 Cache Consistency.....................................22 70 3.3.1. Update Message Format..............................25 71 3.3.2 Acknowledge Message Format..........................26 72 3.4 Pull Directory Hosted on an End Station...............26 73 3.5 Pull Directory Message Errors.........................28 74 3.5.1 Error Codes.........................................29 75 3.5.2 Sub-Errors Under Error Codes 1 and 3................29 76 3.5.3 Sub-Errors Under Error Codes 128 and 131............29 77 3.6 Additional Pull Details...............................30 78 3.7 The No Data Flag......................................30 80 4. Directory Use Strategies and Push-Pull Hybrids.........32 81 5. Security Considerations................................34 83 6. IANA Considerations....................................35 84 6.1 ESADI-Parameter Data Extensions.......................35 85 6.2 RBridge Channel Protocol Number.......................36 86 6.3 The Pull Directory (PUL) and No Data (NOD) Bits.......36 87 6.4 TRILL Pull Directory QTYPEs...........................36 88 6.5 Pull Directory Error Code Registries..................37 90 Normative References......................................38 91 Informational References..................................39 92 Acknowledgments...........................................40 93 Authors' Addresses........................................41 95 1. Introduction 97 [RFC7067] gives a problem statement and high level design for using 98 directory servers to assist TRILL [RFC6325] edge nodes in reducing 99 multi-destination ARP/ND [ARPreduction], reducing unknown unicast 100 flooding traffic, and improving security against address spoofing 101 within a TRILL campus. Because multi-destination traffic becomes an 102 increasing burden as a network scales up in number of nodes, reducing 103 ARP/ND and unknown unicast flooding improves TRILL network 104 scalability. This document describes specific mechanisms for 105 directory servers to assist TRILL edge nodes. These mechanisms are 106 optional to implement. 108 The information held by the Directory(s) is address mapping and 109 reachability information. Most commonly, what MAC address [RFC7042] 110 corresponds to an IP address within a Data Label (VLAN or FGL (Fine 111 Grained Label [RFC7172])) and the egress TRILL switch (RBridge), and 112 optionally what specific TRILL switch port, from which that MAC 113 address is reachable. But it could be what IP address corresponds to 114 a MAC address or possibly other address mappings or reachability. 116 In the data center environment, it is common for orchestration 117 software to know and control where all the IP addresses, MAC 118 addresses, and VLANs/tenants are in a data center. Thus such 119 orchestration software can be appropriate for providing the directory 120 function or for supplying the Directory(s) with directory 121 information. 123 Directory services can be offered in a Push or Pull Mode [RFC7067]. 124 Push Mode, in which a directory server pushes information to TRILL 125 switches indicating interest, is specified in Section 2. Pull Mode, 126 in which a TRILL switch queries a server for the information it 127 wants, is specified in Section 3. More detail on modes of operation, 128 including hybrid Push/Pull, are provided in Section 4. 130 The mechanism used to initially populate directory data in primary 131 servers is beyond the scope of this document. A primary server can 132 use the Push Directory service to provide directory data to secondary 133 servers as described in Section 2.5. 135 1.1 Uses of Directory Information 137 A TRILL switch can consult Directory information whenever it wants, 138 by (1) searching through information that has been retained after 139 being pushed to it or pulled by it or (2) by requesting information 140 from a Pull Directory. However, the following are expected to be the 141 most common circumstances leading to directory information use. All 142 of these are cases of ingressing (or originating) a native frame. 144 1. ARP requests and replies [RFC826] are normally broadcast. But a 145 directory assisted edge TRILL switches could intercept ARP 146 messages and reply if the TRILL switch has the relevant 147 information. 149 2. IPv6 ND (Neighbor Discovery [RFC4861]) requests and replies are 150 normally multicast. Except in the case of Secure ND [RFC3971] 151 where possession of the right keying material might be required, 152 directory assisted edge TRILL switches could intercept ND messages 153 and reply if the TRILL switch has the relevant information. 155 3. Unknown destination MAC addresses. An edge TRILL switch ingressing 156 a native frame necessarily has to determine if it knows the egress 157 RBridge from which the destination MAC address of the frame (in 158 the frame's VLAN or FGL) is reachable. It might learn that 159 information from the directory or could query the directory if it 160 does not know. Furthermore, if the edge TRILL switch has complete 161 directory information, it can detect a forged source MAC address 162 in the native frame and discard the frame in that case. 164 4. RARP [RFC903] is similar to ARP as above. 166 1.2 Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 The terminology and acronyms of [RFC6325] are used herein along with 173 the following: 175 CSNP Time: Complete Sequence Number PDU Time. See ESDADI [RFC7357] 176 and Section 6.1 below. 178 Data Label: VLAN or FGL. 180 FGL: Fine Grained Label [RFC7172]. 182 Host: Application running on a physical server or a virtual machine. 183 A host must have a MAC address and usually has at least one IP 184 address. 186 IP: Internet Protocol. In this document, IP includes both IPv4 and 187 IPv6. 189 MacDA: Destination MAC address. 191 PDSS: Push Directory Server Status. See Sections 2 and 6.1 below. 193 PUL: Pull Directory flag bit. See Sections 3 and 6.3 below. 195 primary server: A Directory server that obtains the information it is 196 serving up by a reliable mechanism outside the scope of this 197 document designed to assure the freshness of that information. 198 (See secondary server.) 200 RBridge: An alternative name for a TRILL switch. 202 secondary server: A Directory server that obtains the information it 203 is serving up from one or more primary servers. 205 TRILL: Transparent Interconnection of Lots of Links or Tunneled 206 Routing in the Link Layer. 208 TRILL switch: A device that implements the TRILL protocol. 210 2. Push Model Directory Assistance Mechanisms 212 In the Push Model [RFC7067], one or more Push Directory servers 213 reside at TRILL switches and push down the address mapping 214 information for the various addresses associated with end station 215 interfaces and the TRILL switches from which those interfaces are 216 reachable [IA]. This service is scoped by Data Label (VLAN or FGL 217 [RFC7172]). A Push Directory also advertises whether or not it 218 believes it has pushed complete mapping information for a Data Label. 219 It might be pushing only a subset of the mapping and/or reachability 220 information for a Data Label. The Push Model uses the ESADI [RFC7357] 221 protocol as its distribution mechanism. 223 With the Push Model, if complete address mapping information for a 224 Data Label is being pushed, a TRILL switch (RBridge) which has that 225 complete information and is ingressing a native frame can simply drop 226 the frame if the destination unicast MAC address can't be found in 227 the mapping information available, instead of flooding the frame 228 (ingressing it as an unknown MAC destination TRILL Data frame). But 229 this will result in lost traffic if ingress TRILL switch's directory 230 information is incomplete. 232 2.1 Requesting Push Service 234 In the Push Model, it is necessary to have a way for a TRILL switch 235 to subscribe to information from the directory server(s). TRILL 236 switches simply use the ESADI [RFC7357] protocol mechanism to 237 announce, in their core IS-IS LSPs, the Data Labels for which they 238 are participating in ESADI by using the Interested VLANs and/or 239 Interested Labels sub-TLVs [RFC7176]. This will cause them to be 240 pushed the Directory information for all such Data Labels that are 241 being served by the one or more Push Directory servers. 243 2.2 Push Directory Servers 245 Push Directory servers advertise their availability to push the 246 mapping information for a particular Data Label to each other and to 247 ESADI participants for that Data Label through ESADI by setting the 248 PDSS (Push Directory Server Status) in their ESADI Parameter APPsub- 249 TLV for that ESADI instance (see [RFC7357] and Section 6.1) to a non- 250 zero value. Each Push Directory server MUST participate in ESADI for 251 the Data Labels for which it will push mappings and set the PDSS 252 field in its ESADI-Parameters APPsub-TLV for that Data Label. 254 For robustness, it is useful to have multiple Push Directory Servers 255 for each Data Label. Each Push Directory server is configured with a 256 number N in the range 1 to 8, which defaults to 2, for each Data 257 Label for which it can push directory information. If the Push 258 Directories for a Data Label are configured consistently with the 259 same N and at least N servers are available, then N copies of the 260 directory that will be pushed. 262 Each Push Directory server also has an 8-bit priority to be Active 263 (see Section 6.1 of this document). This priority is treated as an 264 unsigned integer where larger magnitude means higher priority and is 265 in its ESADI Parameter APPsub-TLV. means higher priority. 267 For each Data Label it can serve, each Push Directory server checks 268 to see if there are enough higher priority servers to push the 269 desired number of copies. It does this by ordering, by priority, the 270 Push Directory servers that it can see in the ESADI link state 271 database for that Data Label that are data reachable [rfc7180bis] and 272 determines its own position in that order. If a Push Directory server 273 is configured to believe that N copies of the mappings for a Data 274 Label should be pushed and finds that it is number K in the priority 275 ordering (where number 1 is highest priority and number K is lowest), 276 then if K is less than or equal to N the Push Directory server is 277 Active. If K is greater than N it is Stand-By. Active and Stand-By 278 behavior are specified below. 280 For a Push Directory to reside on an end station, one or more TRILL 281 switches locally connected to that end station must proxy for the 282 Push Directory server and advertise themselves as Push Directory 283 servers. It appears to the rest of the TRILL campus that these TRILL 284 switches (that are proxying for the end station) are the Push 285 Directory server(s). The protocol between such a Push Directory end 286 station and the one or more proxying TRILL switches acting as Push 287 Directory servers is beyond the scope of this document. 289 2.3 Push Directory Server State Machine 291 The subsections below describe the states, events, and corresponding 292 actions for Push Directory servers. 294 The meaning of the value of the PDSS field in a Push Directory's 295 ESADI Parameter APPsub-TLV is summarized in the table below. 297 PDSS Meaning 298 ---- ---------- 299 0 Not a Push Directory Server 300 1 Push Directory Server in Stand-By Mode 301 2 Push Directory Server in Active Mode but not complete 302 3 Push Directory Server in Active Mode that has pushed 303 complete data 305 2.3.1 Push Directory States 307 A Push Directory Server is in one of seven states, as listed below, 308 for each Data Label it can serve. The name of each state is followed 309 by a symbol that starts and ends with an angel bracket and 310 representing the state. The value that the Push Directory Server 311 advertises in PDSS is determined by the state. In addition, it has 312 an internal State-Transition-Time variable for each Data Label it 313 serves which is set at each state transition and which enables it to 314 determine how long it has been in its current state for that Data 315 Label. 317 Down : A completely shut down virtual state defined for 318 convenience in specifying state diagrams. A Push Directory Server 319 in this state does not advertise any Push Directory data. It may 320 be participating in ESDADI [RFC7357] with the PDSS field zero in 321 its ESADI-Parameters or might be not participating in ESADI at 322 all. (All states other than the Down state are considered to be Up 323 states and imply a non-zero PDSS field.) 325 Stand-By : No Push Directory data is advertised. Any outstanding 326 EASDI-LSP fragments containing directory data are updated to 327 remove that data and if the result is an empty fragment (contains 328 nothing except possibly an Authentication TLV), the fragment is 329 purged. The Push Directory participates in ESDADI [RFC7357] and 330 advertises its ESADI fragment zero that includes an ESADI- 331 Parameters APPsub-TLV with the PDSS field set to 1. 333 Active : The PDSS field in the ESADI-Parameters is set to 2. If 334 a Push Directory server is Active, it advertises its directory 335 data and any changes through ESADI [RFC7357] in its ESADI-LSPs 336 using the Interface Addresses [IA] APPsub-TLV and updates that 337 information as it changes. 339 Active Completing : Same behavior as the Active state except 340 that it responds differently to events. The purpose of this state 341 is to be sure there has been enough time for directory information 342 to propagate to subscribing edge TRILL switches before the 343 Directory Server advertises that the information is complete. 345 Active Complete : The same behavior as Active except that the 346 PDSS field in the ESADI-Parameters APPsub-TLV is set to 3 and the 347 server responds differently to events. 349 Going Stand-By : The same behavior as Active except that it 350 responds differently to events. The purpose of this state is to be 351 sure that the information that the directory is no longer complete 352 has enough time to propagate to edge TRILL switches before the 353 Directory Server stop advertising updates to the information. 355 Active Uncompleting : The same behavior as Active except that it 356 responds differently to events. The purpose of this state is to be 357 sure that the information that the directory is no longer complete 358 has enough time to propagate to edge TRILL switches before the 359 Directory Server might stop advertising updates to the 360 information. (See note below.) 362 Note: It might appear that a Push Directory could transition 363 directly from Active Complete to Active, since Active state 364 continues to advertise updates, eliminating the need for the 365 Active Uncompleting transition state. But consider the case of 366 the Push Directory being configured to be incomplete and then 367 the Stand-By Condition (see Section 2.3.2) occurring 368 immediately thereafter. If the first of these two events caused 369 the server to transition directly to the Active state then, 370 when the Stand-By Condition occurred, it would immediately 371 transition to Stand-By and stop advertising updates even though 372 there might not have been enough time for knowledge of its 373 incompleteness to have propagated to all edge TRILL switches. 375 The following table summarizes PDSS value for each state: 377 State PDSS 378 ---------- ------ 379 Down 0 380 Stand-By 1 381 Active 2 382 Active Completing 2 383 Active Complete 3 384 Going Stand-By 2 385 Active Uncompleting 2 387 2.3.2 Push Directory Events and Conditions 389 Three auxiliary conditions referenced later in this section are 390 defined as follows for convenience: 392 The Activate Condition: In order to have the desired number of Push 393 Directory servers pushing data, this Push Directory server should 394 be active. This is determined by the server finding that it is 395 priority K among the data reachable Push Directory servers (where 396 highest priority is 1), it is configured that there should be N 397 copies pushed, and K is less than or equal to N. For example, the 398 Push Directory server is configured that 2 copies should be pushed 399 and finds that it is priority 1 or 2 among the Push Directory 400 servers it can see. 402 The Stand-By Condition: In order to have the desired number of Push 403 Directory servers pushing data, this Push Directory server should 404 be stand-by (not active). This is determined by the server finding 405 that it is priority K among the data reachable data reachable Push 406 Directory servers (where highest priority is 1), it is configured 407 that there should be N copies pushed, and K is greater than N. For 408 example, the Push Directory server is configured that 2 copies 409 should be pushed and finds that it is priority 3 or lower priority 410 (higher number) among the Push directory servers it can see. 412 The Time Condition: The Push Directory server has been in its current 413 state for a configurable amount of time that defaults to twice its 414 CSNP time (see Section 6.1).) 416 The events and conditions listed below cause state transitions in 417 Push Directory servers. 419 1. Push Directory server was Down but is now Up. 421 2. The Push Directory server or the TRILL switch on which it resides 422 is being shut down. 424 3. The Activate Condition is met and the server is not configured to 425 believe it has complete data. 427 4. The Stand-By Condition is met. 429 5. The Activate Condition is met and the server is configured to 430 believe it has complete data. 432 6. The server is configured to believe it does not have complete 433 data. 435 7. The Time Condition is met. 437 2.3.3 State Transition Diagram and Table 439 The state transition table is as follows: 441 State|Down|Stand-By|Active| Active | Active | Going | Active 442 -----+ | | |Completing|Complete|Stand-By|Uncompleting 443 Event|| | | | | | 444 -----+----+--------+------+----------+--------+---------+------------ 445 1 || | | | | | 446 2 || | | | | | 447 3 || | | | | | 448 4 || | | | | | 449 5 || | | | | | 450 6 || | | | | | 451 7 || | | | | | 453 The above state table is equivalent to the following transition 454 diagram: 456 +-----------+ 457 | Down |<---------+ 458 +-----------+ | 459 |1 ^ | 3,4,5,6,7 | 460 | | +------------+ 461 V |2 462 +---------------+ 463 | Stand-By |<------------------------------------------+ 464 +---------------+ ^ ^ ^ | 465 |5 |3 |1,4,6,7 | | | | 466 | | +---------+ | | | 467 | V |2,4 | | 468 | +---------------------+ | | 469 | | Active |<---------|-----------------+ | 470 | +---------------------+ ^ | | | 471 | |5 ^ |1,3,6,7 ^ | | | | 472 | | | | | | | | | 473 | | | +---------+ | | | | 474 | | | | | | | 475 V V |3,6 | | | | 476 +------------------------+ | | | | 477 | Active Completing |------------+ | | 478 +------------------------+ 2,4 | | | 479 |7 |1,5 ^ | | | 480 | | | | | | 481 | +-------+ | | | 482 | | | | 483 | +--------------------------------------+ | | 484 | | | | | | 485 V V |7 |5 |3 |7 486 +---------------+ 3,6 +----------------+ 4 +----------------+ 487 | Active |------->| Active |----->| Going | 488 | Complete | | Uncompleting | | Stand-By | 489 | |<-------| | | | 490 +---------------+ 5 +----------------+ +----------------+ 491 |1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^ 492 | | | | | | | | 493 +-------+ | +------------+ | +--------+ 494 | | 495 +------------------------------------+ 497 Figure 2. Push Server State Diagram 499 2.4 Additional Push Details 501 Push Directory mappings can be distinguished for other data 502 distributed through ESADI because mappings are distributed only with 503 the Interface Addresses APPsub-TLV [IA] and are flagged in that 504 APPsub-TLV as being Push Directory data. 506 TRILL switches, whether or not they are a Push Directory server, MAY 507 continue to advertise any locally learned MAC attachment information 508 in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. 509 However, if a Data Label is being served by complete Push Directory 510 servers, advertising such locally learned MAC attachment generally 511 SHOULD NOT be done as it would not add anything and would just waste 512 bandwidth and ESADI link state space. An exception might be when a 513 TRILL switch learns local MAC connectivity and that information 514 appears to be missing from the directory mapping. 516 Because a Push Directory server needs to advertise interest in one or 517 more Data Labels even though it might not want to receive multi- 518 destination data in those Data Labels, the No Data (NOD) flag bit is 519 provided as discussed in Section 3.7. 521 When a Push Directory server is no longer data reachable 522 [rfc7180bis], TRILL switches MUST ignore any Push Directory data from 523 that server because it is no longer being updated and may be stale. 525 The nature of dynamic distributed asynchronous systems is such that 526 it is impossible for a TRILL switch receiving Push Directory 527 information to be absolutely certain that it has complete 528 information. However, it can obtain a reasonable assurance of 529 complete information by requiring two conditions to be met: 530 1. The PDSS field is 3 in the ESADI zero fragment from the server 531 for the relevant Data Label. 532 2. In so far as it can tell, it has had continuous data 533 connectivity to the server for a configurable amount of time 534 that defaults to twice the server's CSNP time. 535 Condition 2 is necessary because a client TRILL switch might be just 536 coming up and receive an EASDI LSP meeting the requirement in 537 condition 1 above but have not yet received all of the ESADI LSP 538 fragment from the Push Directory server. 540 There may be conflicts between mapping information from different 541 Push Directory servers or conflicts between locally learned 542 information and information received from a Push Directory server. In 543 case of such conflicts, information with a higher confidence value 544 [RFC6325] is preferred over information with a lower confidence. In 545 case of equal confidence, Push Directory information is preferred to 546 locally learned information and if information from Push Directory 547 servers conflicts, the information from the higher priority Push 548 Directory server is preferred. 550 2.5 Primary to Secondary Server Push Service 552 A secondary Push or Pull Directory server is one that obtains its 553 data from a primary directory server. Other techniques MAY be used 554 but, by default, this data transfer occurs through the primary server 555 acting as a Push Directory server for the Data Labels involved while 556 the secondary directory server takes the pushed data it receives from 557 the highest priority Push Directory server and re-originates it. Such 558 a secondary server may be a Push Directory server or a Pull Directory 559 server or both for any particular Data Label. Because the data from a 560 secondary server will necessarily be at least a little less fresh 561 than that from a primary server, it is RECOMMENDED that the re- 562 originated secondary server data be given a confidence level of one 563 less than that of the data as received from the primary (or unchanged 564 if it is alreayd of minimum confidence). 566 3. Pull Model Directory Assistance Mechanisms 568 In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory 569 information from an appropriate Directory Server when needed. 571 Pull Directory servers for a particular Data Label X are found by 572 looking in the core TRILL IS-IS link state database for data 573 reachable [rfc7180bis] TRILL switches that advertise themselves by 574 having the Pull Directory flag (PUL) on in their Interested VLANs or 575 Interested Labels sub-TLV (see Section 6.3)) for that Data Label. If 576 multiple such TRILL switches indicate that they are Pull Directory 577 Servers for a particular Data Label, pull requests can be sent to any 578 one or more of them but it is RECOMMENDED that pull requests be 579 preferentially sent to the server or servers that are lowest cost 580 from the requesting TRILL switch. 582 Pull Directory requests are sent by enclosing them in an RBridge 583 Channel [RFC7178] message using the Pull Directory channel protocol 584 number (see Section 6.2). Responses are returned in an RBridge 585 Channel message using the same channel protocol number. See Section 586 3.2 for Query and Response Message formats. For cache consistency or 587 notification purposes, Pull Directory servers, under certain 588 conditions, MUST send unsolicited Update Messages to client TRILL 589 switches they believe may be holding old data and those clients can 590 acknowledge such updates, as described in Section 3.3. All these 591 messages have a common header as described in Section 3.1. Errors 592 returns can be sent for queries or updates as described in Section 593 3.5. 595 The requests to Pull Directory Servers are typically derived from 596 ingressed ARP [RFC826], ND [RFC4861], or RARP [RFC903] messages, or 597 data frames with unknown unicast destination MAC addresses, 598 intercepted by an ingress TRILL switch as described in Section 1.1. 600 Pull Directory responses include an amount of time for which the 601 response should be considered valid. This includes negative responses 602 that indicate no data is available. It is RECOMMENDED that both 603 positive responses with data and negative responses can be cached and 604 used to locally handle ARP, ND, RARP, unknown destination MAC frames, 605 or the like, until the responses expire. If information previously 606 pulled is about to expire, a TRILL switch MAY try to refresh it by 607 issuing a new pull request but, to avoid unnecessary requests, SHOULD 608 NOT do so if it has not been recently used. The validity timer of 609 cached Pull Directory responses is NOT reset or extended merely 610 because that cache entry is used. 612 3.1 Pull Directory Message Common Format 614 All Pull Directory messages are transmitted as the payload of RBridge 615 Channel messages [RFC7178]. Pull Directory messages are formatted as 616 described herein starting with the following common 8-byte header: 618 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Ver | Type | Flags | Count | Err | SubErr | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Sequence Number | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type Specific Payload - variable length 626 +-+-+- ... 628 Ver: Version of the Pull Directory protocol as an unsigned 629 integer. Version zero is specified in this document. 631 Type: The Pull Directory message type as follows: 633 Type Section Name 634 ---- ------- -------- 635 0 - Reserved 636 1 3.2.1 Query 637 2 3.2.2 Response 638 3 3.3.1 Update 639 4 3.3.2 Acknowledge 640 5-14 - Unassigned 641 15 - Reserved 643 Flags: Four flag bits whose meaning depends on the Pull Directory 644 message Type. Flags whose meaning is not specified are 645 reserved, MUST be sent as zero, and MUST be ignored on receipt. 647 Count: Pull Directory message types specified herein have zero or 648 more occurrences of a Record as part of the type specific 649 payload. The Count field is the number of occurrences of that 650 Record as an unsigned integer. For any Pull Directory messages 651 not structured with such occurrences, this field MUST be sent 652 as zero and ignored on receipt. 654 Err, SubErr: The error and suberror fields are only used in 655 messages that are in the nature of replies. In messages that 656 are requests or updates, these fields MUST be sent as zero and 657 ignored on receipt. An Err field containing the value zero 658 means no error. The meaning of values in the SubErr field 659 depends on the value of the Err field but in all cases, a zero 660 SubErr field is allowed and provides no additional information 661 beyond the value of the Err field. 663 Sequence Number: An opaque 32-bit quantity set by the TRILL switch 664 sending a request or other unsolicited message and returned in 665 every corresponding reply or acknowledgement. It is used to 666 match up responses with the message to which they respond. 668 Type Specific Payload: Format depends on the Pull Directory 669 message Type. 671 3.2 Pull Directory Query and Response Messages 673 The format of the Pull Directory Query and Response Messages is 674 specified below. 676 3.2.1 Pull Directory Query Message Format 678 A Pull Directory Query Message is sent as the Channel Protocol 679 specific content of an RBridge Channel message [RFC7178] TRILL Data 680 packet or as a native RBridge Channel data frame (see Section 3.4). 681 The Data Label of the packet is the Data Label in which the query is 682 being made. The priority of the channel message is a mapping of the 683 priority of the frame being ingressed that caused the query with the 684 default mapping depending, per Data Label, on the strategy (see 685 Section 4) or a configured priority for generated queries. (Generated 686 queries are those not the result of a mapping. For example, a query 687 to refresh a cache entry.) The Channel Protocol specific data is 688 formatted as a header and a sequence of zero or more QUERY Records as 689 follows: 691 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Ver | Type | Flags | Count | Err | SubErr | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Sequence Number | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | QUERY 1 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 700 | QUERY 2 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 702 | ... 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 704 | QUERY K 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 707 Ver, Sequence Number: See 3.1. 709 Type: 1 for Query. Queries received by an TRILL switch that is not 710 a Pull Directory for the relevant Data Label result in an error 711 response (see Section 3.5) unless inhibited by rate limiting. 712 (See [RFC7178] for response if the Pull Directory RBridge 713 Channel protocol is not enabled.) 715 Flags, Err, and SubErr: MUST be sent as zero and ignored on 716 receipt. 718 Count: Number of QUERY Records present. A Query Message Count of 719 zero is explicitly allowed, for the purpose of pinging a Pull 720 Directory server to see if it is responding. On receipt of such 721 an empty Query Message, a Response Message that also has a 722 Count of zero is sent unless inhibited by rate limiting. 724 QUERY: Each QUERY Record within a Pull Directory Query Message is 725 formatted as follows: 727 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 728 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 729 | SIZE |FL| RESV | QTYPE | 730 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 731 If QTYPE = 1 732 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 733 | AFN | 734 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 735 | Query address ... 736 +--+--+--+--+--+--+--+--+--+--+--... 737 If QTYPE = 2, 3, 4, or 5 738 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 739 | Query frame ... 740 +--+--+--+--+--+--+--+--+--+--+--... 742 SIZE: Size of the QUERY Record in bytes as an unsigned integer 743 not including the SIZE field and following byte. A value of 744 SIZE so large that the material doesn't fit in the Query 745 Message indicates a malformed QUERY Record. The QUERY Record 746 with the illegal SIZE value and any subsequent QUERY Records 747 MUST be ignored and the entire Query Message MAY be ignored. 749 FL: The FLooded flag that is ignored if QTYPE is zero. If QTYPE 750 is 2 through 5 and the directory information sought is not 751 found, the frame provided is flooded, otherwise it is not 752 forwarded. See Section 3.2.2.2. 754 RESV: A block of three reserved bits. MUST be sent as zero and 755 ignored on receipt. 757 QTYPE: There are several types of QUERY Records currently 758 defined in two classes as follows: (1) a QUERY Record that 759 provides an explicit address and asks for all addresses for 760 the interface specified by the query address and (2) a QUERY 761 Record that includes a frame. The fields of each are 762 specified below. Values of QTYPE are as follows: 764 QTYPE Description 765 ----- ----------- 766 0 Reserved 767 1 Address query 768 2 ARP query frame 769 3 ND query frame 770 4 RARP query frame 771 5 Unknown unicast MAC query frame 772 6-14 Unassigned 773 15 Reserved 775 AFN: Address Family Number of the query address. 777 Query Address: The query is asking for any other addresses, 778 and the nickname of the TRILL switch from which they are 779 reachable, that correspond to the same interface, within 780 the data label of the query. Typically that would be 781 either (1) a MAC address with the querying TRILL switch 782 primarily interested in the TRILL switch by which that 783 MAC address is reachable, or (2) an IP address with the 784 querying TRILL switch interested in the corresponding MAC 785 address and the TRILL switch by which that MAC address is 786 reachable. But it could be some other address type. 788 Query Frame: Where a QUERY Record is the result of an ARP, 789 ND, RARP, or unknown unicast MAC destination address, the 790 ingress TRILL switch MAY send the frame to a Pull 791 Directory Server if the frame is small enough that the 792 resulting Query Message fits into a TRILL Data packet 793 within the campus MTU. 795 If no response is received to a Pull Directory Query Message within a 796 timeout configurable in milliseconds that defaults to 100, the Query 797 Message should be re-transmitted with the same Sequence Number up to 798 a configurable number of times that defaults to three. If there are 799 multiple QUERY Records in a Query Message, responses can be received 800 to various subsets of these QUERY Records before the timeout. In that 801 case, the remaining unanswered QUERY Records should be re-sent in a 802 new Query Message with a new sequence number. If a TRILL switch is 803 not capable of handling partial responses to queries with multiple 804 QUERY Records, it MUST NOT sent a Request Message with more than one 805 QUERY Record in it. 807 See Section 3.5 for a discussion of how Query Message errors are 808 handled. 810 3.2.2 Pull Directory Responses 812 A Pull Directory Query Message result in a Pull Directory Response 813 Message as described in Section 3.2.2.1. 815 In addition, if the QUERY Record QTYPE was 2, 3, 4, or 5, the frame 816 included in the Query may be modified and forwarded by the Pull 817 Directory server as described in Section 3.2.2.2. 819 3.2.2.1 Pull Directory Response Message Format 821 Pull Directory Response Messages are sent as the Channel Protocol 822 specific content of an RBridge Channel message [RFC7178] TRILL Data 823 packet or as a native RBridge Channel data frame (see Section 3.4). 824 Responses are sent with the same Data Label and priority as the Query 825 Message to which they correspond except that the Response Message 826 priority is limited to be not more than a configured value. This 827 priority limit is configurable per TRILL switch and defaults to 828 priority 6. Pull Directory Response Messages SHOULD NOT be sent with 829 priority 7 as that priority SHOULD be reserved for messages critical 830 to network connectivity. 832 The RBridge Channel protocol specific data format is as follows: 834 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Ver | Type | Flags | Count | Err | SubErr | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Sequence Number | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | RESPONSE 1 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 843 | RESPONSE 2 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 845 | ... 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 847 | RESPONSE K 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 850 Ver, Sequence Number: As specified in Section 3.1. 852 Type: 2 = Response. 854 Flags: MUST be sent as zero and ignored on receipt. 856 Count: Count is the number of RESPONSE Records present in the 857 Response Message. 859 Err, SubErr: A two-part error code. Zero unless there was an error 860 in the Query Message, for which case see Section 3.5. 862 RESPONSE: Each RESPONSE record within a Pull Directory Response 863 Message is formatted as follows: 865 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 866 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 867 | SIZE |OV| RESV | Index | 868 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 869 | Lifetime | 870 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 871 | Response Data ... 872 +--+--+--+--+--+--+--+--+--+--+--... 874 SIZE: The size of the RESPONSE Record is an unsigned integer 875 number of bytes not including the SIZE field and following 876 byte. A value of SIZE so large that the material doesn't fit 877 in the Query Message indicates a malformed QUERY Record. The 878 QUERY Record with such an excessive SIZE value and any 879 subsequent QUERY Records MUST be ignored and the entire 880 Query Message MAY be ignored. 882 OV: The overflow flag. Indicates, as described below, that 883 there was too much Response Data to include in one Response 884 Message. 886 RESV: Three reserved bits that MUST be sent as zero and ignored 887 on receipt. 889 Index: The relative index of the QUERY Record in the Query 890 Message to which this RESPONSE Record corresponds. The index 891 will always be one for Query Messages containing a single 892 QUERY Record. If the Index is larger than the Count was in 893 the corresponding Query, that RESPONSE Record MUST be 894 ignored and subsequent RESPONSE Records or the entire 895 Response Message MAY be ignored. 897 Lifetime: The length of time for which the response should be 898 considered valid in units of 100 milliseconds except that 899 the values zero and 2**16-1 are special. If zero, the 900 response can only be used for the particular query from 901 which it resulted and MUST NOT be cached. If 2**16-1, the 902 response MAY be kept indefinitely but not after the Pull 903 Directory server goes down or becomes unreachable. (The 904 maximum definite time that can be expressed is a little over 905 1.8 hours.) 907 Response Data: There are two types of RESPONSE Records. 908 - If the Err field of the enclosing Repose message is non- 909 zero, then the Response Data in the REPONSE Record is 910 null and SIZE will be zero. See Section 3.5 for 911 additional information on errors. 912 - If the Err field of the enclosing Repose message is zero, 913 then the Response Data is formatted as the value of an 914 Interface Addresses APPsub-TLV [IA]. The maximum size of 915 such contents is 255 bytes in the case when the RESPONSE 916 record SIZE field is 255. 918 Multiple RESPONSE Records can appear in a Response Message with the 919 same Index if the answer to a QUERY Record consists of multiple 920 Interface Address APPsub-TLV values. This would be necessary if, for 921 example, a MAC address within a Data Label appears to be reachable by 922 multiple TRILL switches. However, all RESPONSE Records to any 923 particular QUERY Record MUST occur in the same Response Message. If a 924 Pull Directory holds more mappings for a queried address than will 925 fit into one Response Message, it selects which to include by some 926 method outside the scope of this document and sets the overflow flag 927 (OV) in all of the RESPONSE Records responding to that query address. 929 See Section 3.5 for a discussion of how errors are handled. 931 3.2.2.2 Pull Directory Forwarding 933 Query Messages with QTYPEs 2, 3, 4, and 5 are interpreted and handled 934 as described below. In these cases, if the information sought is not 935 in the directory, the provided frame is forwarded by the Pull 936 Directory server as a multi-destination TRILL Data packet if the FL 937 flag in the Query Message was one, otherwise the frame is not 938 forwarded. If there was no error in the handling of the enclosing 939 Query Message then the Pull Directory server forwards the frame 940 inside that QUERY Record, after modifying it in some cases, as 941 described below. 943 ARP: When QTYPE is 2, an ARP [RFC826] frame is included in the QUERY 944 Record. The ar$op field MUST be ares_op$REQUEST and for the 945 response described in 3.2.2.1, this is treated as a query for the 946 target protocol address where the AFN of that address is given by 947 ar$pro. (ARP field and value names with embedded dollar signs are 948 specified in [RFC826].) If ar$op is not ares_op$REQUEST or the ARP 949 is malformed or the query fails, an error is returned. Otherwise 950 the ARP is modified into the appropriate ARP response that is then 951 sent by the Pull Directory server as a TRILL Data packet. 953 ND: When QTYPE is 3, an IPv6 Neighbor Discover (ND [RFC4861]) frame 954 is included in the QUERY Record. Only Neighbor Solicitation ND 955 frames (corresponding to an ARP query) are allowed. An error is 956 returned for other ND frames or if the target address is not 957 found. Otherwise an ND Neighbor Advertisement response is returned 958 by the Pull Directory server as a TRILL Data packet. 960 RARP: When QTYPE is 4, a RARP [RFC903] frame is included in the QUERY 961 Record. If the ar$op field is ares_op$REQUEST, the frame is 962 handled as an ARP above. Otherwise the ar$op field MUST be 963 'reverse request' and for the response described in 3.2.2.1, this 964 is treated as a query for the target hardware address where the 965 AFN of that address is given by ar$hrd. (See [RFC826] for RARP 966 fields.) If ar$op is not one of these values or the RARP is 967 malformed or the query fails, an error is returned. Otherwise the 968 RARP is modified into the appropriate RARP response that is then 969 unicast by the Pull Directory server as a TRILL Data packet to the 970 source hardware MAC address. 972 MacDA: When QTYPE is 5, indicating a fame is provided in the QUERY 973 Record whose destination MAC address TRILL switch attachment is 974 unknown, the only requirement is that this MAC address must be 975 unicast. If it is group addressed an error is returned. For the 976 response described in 3.2.2.1, it is treated as a query for the 977 MacDA. If the Pull Directory contains TRILL switch attachment 978 information for the MAC address in the Data Label of the Query 979 Message, it forwards the frame to that switch in a unicast TRILL 980 Data packet. 982 3.3 Cache Consistency 984 Unless it sends all responses with a Lifetime of zero, a Pull 985 Directory MUST take action, by sending Update Messages, to minimize 986 the amount of time that a TRILL switch will continue to use stale 987 information from that Pull Directory. The format of Update Messages 988 and the Acknowledge Messages used to respond to Update Messages are 989 given in Sections 3.3.1 and 3.3.2. 991 A Pull Directory server MUST maintain one of the following three sets 992 of records, in order of increasing specificity. Retaining more 993 specific records, such as that given in method 3 below, minimizes 994 spontaneous Update Messages sent to update pull client TRILL switch 995 caches but increases the record keeping burden on the Pull Directory 996 server. Retaining less specific records, such as that given in method 997 1, will generally increase the volume and overhead due to spontaneous 998 Update Messages and due to unnecessarily invalidating cached 999 information, but will still maintain consistency and will reduce the 1000 record keeping burden on the Pull Directory server. In all cases, 1001 there may still be brief periods of time when directory information 1002 has changed but cached information a pull clients has not yet been 1003 updated or expunged. 1005 1. An overall record per Data Label of when the last positive 1006 response data sent will expire at some requester and when the 1007 last negative response will expire at some requester, assuming 1008 those requesters cached the response. 1010 2. For each unit of data (IA APPsub-TLV Address Set [IA]) held by 1011 the server and each address about which a negative response was 1012 sent, when the last response sent with that positive response 1013 data and when the last negative response will expire at a 1014 requester, assuming the requester cached the response. 1016 3. For each unit of data held by the server (IA APPsub-TLV Address 1017 Set [IA]) and each address about which a negative response was 1018 sent, a list of TRILL switches that were sent that data as a 1019 positive response or sent a negative response for the address, 1020 and the expected time to expiration for that data or address at 1021 each such TRILL switch, assuming the requester cached the 1022 response. 1024 RESPONSE Records sent with a zero lifetime are considered to have 1025 already expired and so do not need to be tracked. 1027 A Pull Directory server may have a limit as to how many TRILL 1028 switches for which it can maintain expiry information by method 3 1029 above or how many data units or addresses it can maintain expiry 1030 information for by method 2 or the like. If such limits are exceeded, 1031 it MUST transition to a lower numbered method but, in all cases, MUST 1032 support, at a minimum, method 1. 1034 When data at a Pull Directory is changed, deleted, or added and there 1035 may be unexpired stale information at a requesting TRILL switch, the 1036 Pull Directory MUST send an Update Message as discussed below. The 1037 sending of such an Update Message MAY be delayed by a configurable 1038 number of milliseconds that default to 50 milliseconds to await other 1039 possible changes that could be included in the same Update. 1041 1. If method 1, the crudest method, is being followed, then when 1042 any Pull Directory information in a Data Label is changed or 1043 deleted and there are outstanding cached positive data 1044 response(s), an all-addresses flush positive data Update Message 1045 is flooded within that Data Label as an RBridge Channel Message 1046 with an Inner.MacDA of All-Egress-RBridges. Similarly if data is 1047 added and there are outstanding cached negative responses, an 1048 all-addresses flush negative message is similarly flooded. The 1049 Count field being zero in an Update Message indicates "all- 1050 addresses". On receiving an all-addresses flooded flush positive 1051 Update from a Pull Directory server it has used, indicated by 1052 the F and P bits being one and the Count being zero, a TRILL 1053 switch discards the cached data responses it has for that Data 1054 Label. Similarly, on receiving an all addresses flush negative 1055 Update, indicated by the F and N bits being one and the Count 1056 being zero, it discards all cached negative replies for that 1057 Data Label. A combined flush positive and negative can be 1058 flooded by having all of the F, P, and N bits set to one 1059 resulting in the discard of all positive and negative cached 1060 information for the Data Label. 1062 2. If method 2 is being followed, then a TRILL switch floods 1063 address specific positive Update Messages when data that might 1064 be cached by a querying TRILL switch is changed or deleted and 1065 floods address specific negative Update Messages when such 1066 information is added to. Such messages are somewhat similar to 1067 the method 1 flooded flush Update Messages and are also sent as 1068 RBridge Channel messages with an Inner.MacDA of All-Egress- 1069 RBridges. However the Count field will be non-zero and either 1070 the P or N bit, but not both, will be one. There are actually 1071 four possible message types that can be flooded: 1073 2.a If data still being cached is updated, then an Update 1074 Message is sent with the P flag set and the Err field zero. 1075 The addresses in the RESPONSE records in the unsolicited 1076 response are compared to the addresses about which the 1077 receiving TRILL switch is holding cached positive 1078 information from that server and, if they match, the cached 1079 information is updated. 1081 2.b If data still being cached is deleted, then an Update 1082 Message is sent with the P flag set and the Err field non- 1083 zero giving the error that would now be encountered in 1084 attempting to pull information for the relevant address from 1085 the Pull Directory server. In this non-zero Err field case, 1086 the RESPONSE Record(s) differ from non-zero Err Reply 1087 Message RESPONSE Records in that they include an interface 1088 address set. Any cached positive information for the 1089 address is deleted and the negative response cached as per 1090 the lifetime given. 1092 2.c If data for an address about which a negative response was 1093 sent is added so that negative response is now incorrect, an 1094 Update Message is sent with the N flag set to one and the 1095 Err field zero. The addresses in the RESPONSE records in the 1096 unsolicited response are compared to the addresses about 1097 which the receiving TRILL switch is holding cached negative 1098 information from that server and, if they match, the cached 1099 negative information is deleted and the positive information 1100 provided is cached as per the lifetime given. 1102 2.d In the rare case where it is desired to change the lifetime 1103 or error associated with cached negative information, it is 1104 possible to send an Update Message with the N flag set to 1105 one and the Err field non-zero. As in case 2.b above, the 1106 RESPONSE Record(s) give the relevant addresses. Any cached 1107 negative information for the address is updated. 1109 3. If method 3 is being followed, the same sort of unsolicited 1110 Update Messages are sent as with method 2 above except they are 1111 not normally flooded but unicast only to the specific TRILL 1112 switches the directory server believes may be holding the cached 1113 positive or negative information that needs updating. However, a 1114 Pull Directory server MAY flood unsolicited updates under method 1115 3, for example if it determines that a sufficiently large 1116 fraction of the TRILL switches in some Data Label are requesters 1117 that need to be updated. 1119 A Pull Directory server tracking cached information with method 3 1120 MUST NOT clear the indication that it needs to update cached 1121 information at a querying TRILL switch until it has sent an Update 1122 Message and received a corresponding Acknowledge Message or it has 1123 sent a configurable number of updates at a configurable interval 1124 which default to 3 updates 100 milliseconds apart. 1126 A Pull Directory server tracking cached information with methods 2 or 1127 1 SHOULD NOT clear the indication that it needs to update cached 1128 information until it has sent an Update Message and received a 1129 corresponding Acknowledge Message from all of its ESADI neighbors or 1130 it has sent a configurable number of updates at a configurable 1131 interval that defaults to 3 updates 100 milliseconds apart. 1133 3.3.1. Update Message Format 1135 An Update Message is formatted as a Response Message with the with 1136 differences described in Section 3.3 above and the following: 1138 o The Type field in the message header is set to 3. 1140 o The Index field in the RESPONSE Record(s) is set to zero (but the 1141 Count field in the Update Message header MUST still correctly 1142 indicate the number of RESPONSE Records present). 1144 Update Messages are initiated by a Pull Directory server. The 1145 Sequence number space used is controlled by the originating Pull 1146 Directory server and different from Sequence number space used in a 1147 Query and the corresponding Response that are controlled by the 1148 querying TRILL switch. 1150 The 4-bit Flags field of the message header for an Update Message is 1151 as follows: 1153 +---+---+---+---+ 1154 | F | P | N | R | 1155 +---+---+---+---+ 1157 F: The Flood bit. If zero, the Update Message is unicast. If F=1, it 1158 is multicast to All-Egress-RBridges. 1160 P, N: Flags used to indicate positive or negative Update Messages. 1161 P=1 indicates positive. N=1 indicates negative. Both may be 1 for 1162 a flooded all addresses Update. 1164 R: Reserved. MUST be sent as zero and ignored on receipt 1166 For tracking methods 2 and 3 in Section 3.3.1, a particular update 1167 message must have either the P flag or the N flag set but not both. 1169 3.3.2 Acknowledge Message Format 1171 An Acknowledge Message is sent in response to an Update to confirm 1172 receipt or indicate an error, unless response is inhibited by rate 1173 limiting. It is also formatted as a Response Message but the Type is 1174 set to 4. 1176 If there are no errors in the processing of an Update Message, the 1177 message is essentially echoed back with any error indication cleared 1178 and the Type changed to Acknowledge. 1180 If there was an overall or header error in an Update Message, it is 1181 echoed back as an Acknowledge Message with the Err and SubErr fields 1182 set appropriately (see Section 3.5). 1184 If there is a RESPONSE Record level error in an Update Message, one 1185 or more Acknowledge Messages may be returns as indicated in Section 1186 3.5. 1188 3.4 Pull Directory Hosted on an End Station 1190 Optionally, a Pull Directory actually hosted on an end station MAY be 1191 supported. In that case, one or more TRILL switches must proxy for 1192 the end station and advertise themselves as Pull Directory servers. 1193 Such proxies must have a direct connection to the end station, that 1194 is a connection not involving any intermediate TRILL switches. 1196 When the proxy Pull Directory server TRILL switch receives a Query 1197 Message, it modifies the inter-RBridge Channel message received into 1198 a native RBridge Channel message and forwards it to the end station 1199 Pull Directory server. Later, when it receives one or more responses 1200 from that end station by native RBridge Channel messages, it modifies 1201 them into inter-RBridge Channel messages and forwards them to the 1202 source TRILL switch of the original Query Message. Similarly, an 1203 Update from the end station is forwarded to client TRILL switches and 1204 acknowledgements from those TRILL switches are returned to the end 1205 station by the proxy. Because native RBridge Channel messages have no 1206 TRILL Header and are addressed by MAC address, as opposed to inter- 1207 RBridge Channel messages that are TRILL Data packets and are 1208 addressed by nickname, nickname information must be added to the 1209 native RBridge Channel version of Pull Directory messages. 1211 The native Pull Directory RBridge Channel messages use the same 1212 Channel protocol number as do the inter-RBridge Pull Directory 1213 RBridge Channel messages. The native messages SHOULD be sent with an 1214 Outer.VLAN tag that gives the priority of each message which is the 1215 priority of the original inter-RBridge request packet. The Outer.VLAN 1216 ID used is the Designated VLAN on the link to the end station 1217 [RFC6325]. Since there is no TRILL Header or inner Data Label for 1218 native RBridge Chanel messages, that information is added to the 1219 header. 1221 The native RBridge Channel message Pull Directory message protocol 1222 dependent data part is the same as for inter-RBridge Channel messages 1223 except that the 8-byte header described in Section 3.1 is expanded to 1224 14 or 18 bytes as follows: 1226 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Ver | Type | Flags | Count | Err | SubErr | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Sequence Number | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Nickname (2 bytes) | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1235 | Data Label ... (4 or 8 bytes) | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1237 | Type Specific Payload - variable length 1238 +-+-+- ... 1240 Fields not described below are as in Section 3.1. 1242 Nickname: The nickname of the original TRILL switch that is 1243 communicating with the end station Pull Directory. Usually this 1244 is a remote TRILL switch but it could be the TRILL switch to 1245 which the end station is attached. The proxy copies this from 1246 the ingress nickname when mapping a Query or Acknowledge 1247 Message to native form. It also takes this from a native 1248 Response or Update Message to be used as the egress of the 1249 inter-RBridge form on the message unless it is a flooded Update 1250 in which case a distribution tree is used. 1252 Data Label: The Data Label that normally appears right after the 1253 Inner.MacSA of the an RBridge Channel Pull Directory message 1254 appears here in the native RBridge Channel message version. 1255 This might appear in a native Query Message, to be reflected in 1256 a Response Message, or it might appear in a native Update to be 1257 reflected in an Acknowledge Message. 1259 3.5 Pull Directory Message Errors 1261 A non-zero Err field in the Pull Directory message header indicates 1262 an error message. 1264 If there is an error that applies to an entire Query Message or its 1265 header, as indicated by the range of the value of the Err field, then 1266 the QUERY records in the request are just echoed back in the RESPONSE 1267 records of the Response Message but expanded with a zero Lifetime and 1268 the insertion of the Index field. If there is an error that applies 1269 to an entire Update Message or its header, then the RESPONSE records 1270 in the update, if any, are echoed back in the corresponding 1271 Acknowledge Message. 1273 If errors occur at the QUERY Record level for a Query Message, they 1274 MUST be reported in a Response Message separate from the results of 1275 any successful non-erroneous QUERY Records. If multiple QUERY Records 1276 in a Query Message have different errors, they MUST be reported in 1277 separate Response Messages. If multiple QUERY Records in a Query 1278 Message have the same error, this error response MAY be reported in 1279 one or multiple Response Messages. In an error Response Message, the 1280 QUERY Record or records being responded to appear, expanded by the 1281 Lifetime for which the server thinks the error might persist and with 1282 their Index inserted, as the RESPONSE record or records. 1284 If errors occur at the RESPONSE Record level for an Update Message, 1285 they MUST be reported in a Acknowledge Message separate from the 1286 acknowledgement of any non-erroneous RESPONSE Records. If multiple 1287 RESPONSE Records in an Update have different errors, they MUST be 1288 reported in separate Acknowledge Messages. If multiple RESPONSE 1289 Records in an Update Message have the same error, this error response 1290 MAY be reported in one or multiple Acknowledge Messages. In an error 1291 Acknowledge Message, the RESPONSE Record or records being responded 1292 to appear, expanded by the time for which the server thinks the error 1293 might persist and with their Index inserted, as a RESPONSE Record or 1294 records. 1296 ERR values 1 through 126 are available for encoding Request or Update 1297 Message level errors. ERR values 128 through 254 are available for 1298 encoding QUERY or RESPONSE Record level errors. The SubErr field is 1299 available for providing more detail on errors. The meaning of a 1300 SubErr field value depends on the value of the Err field. 1302 3.5.1 Error Codes 1304 Err Meaning 1305 ----- ------- 1306 0 (no error) 1308 1 Unknown or reserved Query Message field value 1309 2 Request Message/data too short 1310 3 Unknown or reserved Update Message field value 1311 4 Update Message/data too short 1312 5-126 (Available for allocation by IETF Review) 1313 127 Reserved 1315 128 Unknown or reserved QUERY Record field value 1316 129 QUERY Record truncated 1317 130 Address not found 1318 131 Unknown or reserved RESPONSE Record field value 1319 132 RESPONSE Record truncated 1320 133-254 (Available for allocation by IETF Review) 1321 255 Reserved 1323 3.5.2 Sub-Errors Under Error Codes 1 and 3 1325 The following sub-errors are specified under error code 1 and 3: 1327 SubErr Field with Error 1328 ------ ---------------- 1329 0 Unspecified 1330 1 Unknown Ver field value 1331 2 Unknown Type field value 1332 3 Specified Data Label not being served 1333 4-254 (Available for allocation by Expert Review) 1334 255 Reserved 1336 3.5.3 Sub-Errors Under Error Codes 128 and 131 1338 The following sub-errors are specified under error code 128 and 131: 1340 SubErr Field with Error 1341 ------ ---------------- 1342 0 Unspecified 1343 1 Unknown AFN field value 1344 2 Unknown or Reserved QTYPE field value 1345 3 Invalid or inconsistent SIZE field value 1346 4 Invalid frame for QTYPE 2, 3, 4, or 5 1347 5-254 (Available for allocation by Expert Review) 1348 255 Reserved 1350 3.6 Additional Pull Details 1352 If a TRILL switch notices that a Pull Directory server is no longer 1353 data reachable [rfc7180bis], it MUST promptly discard all pull 1354 responses it is retaining from that server as it can no longer 1355 receive cache consistency update Messages from the server. 1357 A secondary Pull Directory server is one that obtains its data from a 1358 primary directory server. See discussion of primary to secondary 1359 directory information transfer in Section 2.5. 1361 3.7 The No Data Flag 1363 In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], 1364 the mere presence of an Interested VLANs or Interested Labels sub- 1365 TLVs in the LSP of a TRILL switch indicates connection to end 1366 stations in the VLAN(s) or FGL(s) listed and thus a desire to receive 1367 multi-destination traffic in those Data Labels. But, with Push and 1368 Pull Directories, advertising that you are a directory server 1369 requires using these sub-TLVs to indicate the Data Label(s) you are 1370 serving. If such a directory server does not wish to received multi- 1371 destination TRILL Data packets for the Data Labels it lists in one of 1372 these sub-TLVs, it sets the "No Data" (NOD) bit to one. This means 1373 that data on a distribution tree may be pruned so as not to reach the 1374 "No Data" TRILL switch as long as there are no TRILL switches 1375 interested in the Data that are beyond the "No Data" TRILL switch on 1376 the distribution tree. The NOD bit is backwards compatible as TRILL 1377 switches ignorant of it will simply not prune when they could, which 1378 is safe although it may cause increased link utilization. 1380 Example of a TRILL switch serving as a directory that might not want 1381 multi-destination traffic in some Data Labels would be a TRILL switch 1382 that does not offer end station service for any of the Data Labels 1383 for which it is serving as a directory and is either 1384 - a Pull Directory and/or 1385 - a Push Directory for which all of the ESADI traffic will be 1386 handled by unicast ESDADI [RFC7357]. 1388 A Push Directory MUST NOT set the NOD bit for a Data Label if it 1389 needs to communicate via multi-destination ESADI PDUs in that data 1390 label since such PDUs look like TRILL Data packets to transit TRILL 1391 switches and are likely to be incorrectly pruned if NOD was set. 1393 4. Directory Use Strategies and Push-Pull Hybrids 1395 For some edge nodes that have a great number of Data Labels enabled, 1396 managing the MAC and Data Label <-> Edge RBridge mapping for hosts 1397 under all those Data Labels can be a challenge. This is especially 1398 true for Data Center gateway nodes, which need to communicate with 1399 many, if not all, Data Labels. 1401 For those edge TRILL switch nodes, a hybrid model should be 1402 considered. That is the Push Model is used for some Data Labels or 1403 addresses within a Data Lable while the Pull Model is used for other 1404 Data Labels or addresses within a Data Label. It is the network 1405 operator's decision by configuration as to which Data Labels' mapping 1406 entries are pushed down from directories and which Data Labels' 1407 mapping entries are pulled. 1409 For example, assume a data center where hosts in specific Data 1410 Labels, say VLANs 1 through 100, communicate regularly with external 1411 peers. Probably, the mapping entries for those 100 VLANs should be 1412 pushed down to the data center gateway routers. For hosts in other 1413 Data Labels that only communicate with external peers occasionally 1414 for management interface, the mapping entries for those VLANs should 1415 be pulled down from directory when the need comes up. 1417 Similarly, it could be that within a Data Label that some addresses, 1418 such as the addresses of gateways, file, DNS, or database server 1419 hosts are commonly referenced by most other hosts but those other 1420 hosts, perhaps compute engines, are typically only referenced by a 1421 few hosts in that Data Label. In that case, the address information 1422 for the commonly referenced hosts could be pushed as an incomplete 1423 directory while the addresses of the others are pulled when needed. 1425 The mechanisms described above for Push and Pull Directory services 1426 make it easy to use Push for some Data Labels or addresses and Pull 1427 for others. In fact, different TRILL switches can even be configured 1428 so that some use Push Directory services and some use Pull Directory 1429 services for the same Data Label if both Push and Pull Directory 1430 services are available for that Data Label. And there can be Data 1431 Labels for which directory services are not used at all. 1433 There are a wide variety of strategies that a TRILL switch can adopt 1434 for making use of directory assistance. A few suggestions are given 1435 below. 1437 - Even if a TRILL switch will normally be operating with 1438 information from a complete Push Directory server, there will be a 1439 period of time when it first comes up before the information it 1440 holds is complete. Or, it could be that the only Push Directories 1441 that can push information to it are incomplete or that they are 1442 just starting and may not yet have pushed the entire directory. 1444 Thus, it is RECOMMENDED that all TRILL switches have a strategy 1445 for dealing with the situation where they do not have complete 1446 directory information. Examples are to send a Pull Directory query 1447 or to revert to [RFC6325] behavior. 1449 - If a TRILL switch receives a native frame X resulting in 1450 seeking directory information, a choice needs to be made as to 1451 what to do if it does not already have the directory information 1452 it needs. In particular, it could (1) immediately flood the TRILL 1453 Data packet resulting from ingressing X in parallel with seeking 1454 the directory information, (2) flood that TRILL Data packet 1455 delayed, if it fails to obtain the directory information, or (3) 1456 discard X if it fails to obtain the information. The choice might 1457 depend on the priority of frame X since the higher that priority, 1458 the more urgent the frame is and the greater the probability of 1459 harm in delaying it. If a Pull Directory request is sent, it is 1460 RECOMMENDED that its priority be derived from the priority of the 1461 frame X with the derived priority configurable and having the 1462 following defaults: 1464 Ingressed If Flooded If Flooded 1465 Priority Immediately After Delay 1466 -------- ----------- ----------- 1467 7 5 6 1468 6 5 6 1469 5 4 5 1470 4 3 4 1471 3 2 3 1472 2 0 2 1473 0 1 0 1474 1 1 1 1476 Priority 7 is normally only used for urgent messages critical to 1477 adjacency and so SHOULD NOT be the default for directory traffic. 1478 Unsolicited updates are sent with a priority that is configured per 1479 Data Label that defaults to priority 5. 1481 5. Security Considerations 1483 Incorrect directory information can result in a variety of security 1484 threats including the following: 1486 Incorrect directory mappings can result in data being delivered to 1487 the wrong end stations, or set of end stations in the case of 1488 multi-destination packets, violating security policy. 1490 Missing or incorrect directory data can result in denial of 1491 service due to sending data packets to black holes or discarding 1492 data on ingress due to incorrect information that their 1493 destinations are not reachable. 1495 Push Directory data is distributed through ESADI-LSPs [RFC7357] that 1496 can be authenticated with the same mechanisms as IS-IS LSPs. See 1497 [RFC5304] [RFC5310] and the Security Considerations section of 1498 [RFC7357]. 1500 Pull Directory queries and responses are transmitted as RBridge-to- 1501 RBridge or native RBridge Channel messages [RFC7178]. Such messages 1502 can be secured as specified in [ChannelTunnel]. 1504 For general TRILL security considerations, see [RFC6325]. 1506 6. IANA Considerations 1508 This section gives IANA assignment and registry considerations. 1510 6.1 ESADI-Parameter Data Extensions 1512 Action 1: IANA will assigned a two bit field [bits 1-2 suggested] 1513 within the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory 1514 Server Status" (PDSS) and will create a sub-registry in the TRILL 1515 Parameters Registry as follows: 1517 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 1519 Registration Procedures: Standards Action 1521 References: [RFC7357] [This document] 1523 Bit Mnemonic Description Reference 1524 --- -------- ----------- --------- 1525 0 UN Supports Unicast ESADI ESDADI [RFC7357] 1526 1-2 PDSS Push Directory Server Status [this document] 1527 3-7 - Available for assignment 1529 Action 2: In addition, the ESADI-Parameter APPsub-TLV is optionally 1530 extended, as provided in its original specification in ESADI 1531 [RFC7357], by one byte as show below. Therefore [this document] 1532 should be added as a second reference to the ESDAI-Parameter APPsub- 1533 TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 1534 Identifier 1" Registry. 1536 +-+-+-+-+-+-+-+-+ 1537 | Type | (1 byte) 1538 +-+-+-+-+-+-+-+-+ 1539 | Length | (1 byte) 1540 +-+-+-+-+-+-+-+-+ 1541 |R| Priority | (1 byte) 1542 +-+-+-+-+-+-+-+-+ 1543 | CSNP Time | (1 byte) 1544 +-+-+-+-+-+-+-+-+ 1545 | Flags | (1 byte) 1546 +---------------+ 1547 |PushDirPriority| (optional, 1 byte) 1548 +---------------+ 1549 | Reserved for expansion (variable) 1550 +-+-+-+-... 1552 The meanings of all the fields are as specified in ESDADI [RFC7357] 1553 except that the added PushDirPriority is the priority of the 1554 advertising ESADI instance to be a Push Directory as described in 1555 Section 2.3. If the PushDirPriority field is not present (Length = 3) 1556 it is treated as if it were 0x40. 0x40 is also the value used and 1557 placed here by an TRILL switch whose priority to be a Push Directory 1558 has not been configured. 1560 6.2 RBridge Channel Protocol Number 1562 Action 3: IANA will allocate a new RBridge Channel protocol number 1563 for "Pull Directory Services" from the range allocable by Standards 1564 Action and update the subregistry of such protocol number in the 1565 TRILL Parameters Registry referencing this document. 1567 6.3 The Pull Directory (PUL) and No Data (NOD) Bits 1569 Action 4: IANA is requested to assign a currently reserved bit in the 1570 Interested VLANs field of the Interested VLANs sub-TLV [suggested bit 1571 18] and the Interested Labels field of the Interested Labels sub-TLV 1572 [suggested bits 6] [RFC7176] to indicate Pull Directory server (PUL). 1573 This bit is to be added, with this document as reference, to the 1574 "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" 1575 subregistries created by [RFC7357]. 1577 Action 5: IANA is requested to assign a currently reserved bit in the 1578 Interested VLANs field of the Interested VLANs sub-TLV [suggested 1579 bits 19] and the Interested Labels field of the Interested Labels 1580 sub-TLV [suggested bits 7] [RFC7176] to indicate No Data (NOD, see 1581 Section 3.7). This bit is to be added, with this document as 1582 reference, to the "Interested VLANs Flag Bits" and "Interested Labels 1583 Flag Bits" subregistries created by [RFC7357]. 1585 6.4 TRILL Pull Directory QTYPEs 1587 Action 6: IANA is requested to create a new Registry on the 1588 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 1589 page as follows: 1591 Name: TRILL Pull Directory QTYPEs" 1592 Registration Procedure: IETF Review 1593 Reference: [this document] 1594 Initial contents as in Section 3.2.1. 1596 6.5 Pull Directory Error Code Registries 1598 Actions 7, 8, and 9: IANA is requested to create a new Registry and 1599 two new SubRegistries on the "Transparent Interconnection of Lots of 1600 Links (TRILL) Parameters" web page as follows: 1602 Registry 1603 Name: TRILL Pull Directory Errors 1604 Registration Procedure: IETF Review 1605 Reference: [this document] 1606 Initial contents as in Section 3.5.1. 1608 Sub-Registry 1609 Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 1610 Registration Procedure: Expert Review 1611 Reference: [this document] 1612 Initial contents as in Section 3.5.2. 1614 Sub-Registry 1615 Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 1616 Registration Procedure: Expert Review 1617 Reference: [this document] 1618 Initial contents as in Section 3.5.3. 1620 Normative References 1622 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 1623 RFC 826, November 1982. 1625 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1626 Reverse Address Resolution Protocol", STD 38, RFC 903, June 1627 1984 1629 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1630 Requirement Levels", BCP 14, RFC 2119, March 1997 1632 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1633 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1635 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1636 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1637 September 2007. 1639 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1640 Authentication", RFC 5304, October 2008. 1642 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1643 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1644 5310, February 2009. 1646 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1647 Layer-2 Systems", RFC 6165, April 2011. 1649 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1650 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1651 Specification", RFC 6325, July 2011. 1653 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1654 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1655 BCP 141, RFC 7042, October 2013. 1657 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1658 and D. Dutt, "Transparent Interconnection of Lots of Links 1659 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 1660 . 1662 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1663 D., and A. Banerjee, "Transparent Interconnection of Lots of 1664 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 1665 . 1667 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1668 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1669 RBridge Channel Support", RFC 7178, May 2014, . 1672 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1673 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1674 End Station Address Distribution Information (ESADI) Protocol", 1675 RFC 7357, September 2014, . 1678 [rfc7180bis] - D. Eastlake 3rd, M. Zhang, A. Banerjee, A. Ghanwani, 1679 and S. Gupta "Transparent Interconnection of Lots of Links 1680 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1681 May 2014, . 1683 [IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface 1684 Addresses APPsub-TLV", draft-ietf-trill-ia-appsubtlv, work in 1685 progress. 1687 Informational References 1689 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 1690 Gashinsky, "Directory Assistance Problem and High-Level Design 1691 Proposal", RFC 7067, November 2013. 1693 [ChannelTunnel] - D. Eastlake, M. Umair, Y. Li, "TRILL: RBridge 1694 Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work 1695 in progress. 1697 [ARPreduction] - Y. Li, D. Eastlake, L. Dunbar, R. Perlman, I. 1698 Gashinsky, "TRILL: ARP/ND Optimization", draft-ietf-trill-arp- 1699 optimization, work in progress. 1701 Acknowledgments 1703 The contributions of the following persons are gratefully 1704 acknowledged: 1706 TBD 1708 The document was prepared in raw nroff. All macros used were defined 1709 within the source file. 1711 Authors' Addresses 1713 Donald Eastlake 1714 Huawei Technologies 1715 155 Beaver Street 1716 Milford, MA 01757 USA 1718 Phone: +1-508-333-2270 1719 Email: d3e3e3@gmail.com 1721 Linda Dunbar 1722 Huawei Technologies 1723 5430 Legacy Drive, Suite #175 1724 Plano, TX 75024, USA 1726 Phone: +1-469-277-5840 1727 Email: ldunbar@huawei.com 1729 Radia Perlman 1730 EMC 1731 2010 256th Avenue NE, #200 1732 Bellevue, WA 98007 USA 1734 Email: Radia@alum.mit.edu 1736 Igor Gashinsky 1737 Yahoo 1738 45 West 18th Street 6th floor 1739 New York, NY 10011 1741 Email: igor@yahoo-inc.com 1743 Yizhou Li 1744 Huawei Technologies 1745 101 Software Avenue, 1746 Nanjing 210012 China 1748 Phone: +86-25-56622310 1749 Email: liyizhou@huawei.com 1751 Copyright, Disclaimer, and Additional IPR Provisions 1753 Copyright (c) 2015 IETF Trust and the persons identified as the 1754 document authors. All rights reserved. 1756 This document is subject to BCP 78 and the IETF Trust's Legal 1757 Provisions Relating to IETF Documents 1758 (http://trustee.ietf.org/license-info) in effect on the date of 1759 publication of this document. Please review these documents 1760 carefully, as they describe your rights and restrictions with respect 1761 to this document. Code Components extracted from this document must 1762 include Simplified BSD License text as described in Section 4.e of 1763 the Trust Legal Provisions and are provided without warranty as 1764 described in the Simplified BSD License. The definitive version of 1765 an IETF Document is that published by, or under the auspices of, the 1766 IETF. Versions of IETF Documents that are published by third parties, 1767 including those that are translated into other languages, should not 1768 be considered to be definitive versions of IETF Documents. The 1769 definitive version of these Legal Provisions is that published by, or 1770 under the auspices of, the IETF. Versions of these Legal Provisions 1771 that are published by third parties, including those that are 1772 translated into other languages, should not be considered to be 1773 definitive versions of these Legal Provisions. For the avoidance of 1774 doubt, each Contributor to the IETF Standards Process licenses each 1775 Contribution that he or she makes as part of the IETF Standards 1776 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1777 language to the contrary, or terms, conditions or rights that differ 1778 from or are inconsistent with the rights and licenses granted under 1779 RFC 5378, shall have any effect and shall be null and void, whether 1780 published or posted by such Contributor, or included with or in such 1781 Contribution.