idnits 2.17.1 draft-ietf-trill-esadi-07.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 (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 10, 2014) is 3662 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Hongjun Zhai 2 INTERNET-DRAFT Fangwei Hu 3 Intended status: Proposed Standard ZTE 4 Updates: 6325 Radia Perlman 5 Intel Labs 6 Donald Eastlake 7 Huawei 8 Olen Stokes 9 Extreme Networks 10 Expires: October 9, 2014 April 10, 2014 12 TRILL: 13 ESADI (End Station Address Distribution Information) Protocol 14 16 Abstract 18 The IETF TRILL (Transparent Interconnection of Lots of Links) 19 protocol provides least cost pair-wise data forwarding without 20 configuration in multi-hop networks with arbitrary topologies and 21 link technologies. TRILL supports multi-pathing of both unicast and 22 multicast traffic. Devices that implement the TRILL protocol are 23 called TRILL Switches or RBridges (Routing Bridges). 25 ESADI (End Station Address Distribution Information) is an optional 26 protocol by which a TRILL switch can communicate, in a Data Label 27 (VLAN or Fine Grained Label) scoped way, end station addresses and 28 other information to TRILL switches participating in ESADI for the 29 relevant Data Label. This document updates RFC 6325, specifically 30 the documentation of the ESADI protocol, and is not backwards 31 compatible. 33 Status of This Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Distribution of this document is unlimited. Comments should be sent 39 to the TRILL working group mailing list: . 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 53 Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 Table of Contents 58 1. Introduction............................................4 59 1.1 Content and Precedence.................................5 60 1.2 Terminology............................................5 62 2. ESADI Protocol Overview.................................7 63 2.1 ESADI Virtual Link....................................10 64 2.2 ESADI Neighbor Determination..........................11 65 2.3 ESADI Payloads........................................11 67 3. ESADI DRB (Designated RBridge) Determination...........13 69 4. ESADI PDU processing...................................14 70 4.1 Unicasting ESADI PDUs.................................14 71 4.2 General Transmission of ESADI PDUs....................15 72 4.3 General Receipt of ESADI PDUs.........................16 73 4.4 ESADI Reliable Flooding...............................16 75 5. End Station Addresses..................................18 76 5.1 Learning Confidence Level.............................18 77 5.2 Forgetting End Station Addresses......................18 78 5.3 Duplicate MAC Address.................................18 80 6. ESADI-LSP Contents.....................................21 81 6.1 ESADI Parameter Data..................................21 82 6.2 MAC Reachability TLV..................................23 83 6.3 Default Authentication................................23 85 7. IANA Considerations....................................25 86 7.1 ESADI Participation and Capability Flags..............25 87 7.2 TRILL GENINFO TLV.....................................26 89 8. Security Considerations................................28 90 9. Acknowledgements.......................................29 92 Normative references......................................30 93 Informative References....................................31 94 Appendix A: Changes to [RFC6325]..........................33 95 Appendix Z: Change History................................34 96 Authors' Addresses........................................38 98 1. Introduction 100 The IETF TRILL (Transparent Interconnection of Lots of Links) 101 protocol [RFC6325] provides least cost pair-wise data forwarding 102 without configuration in multi-hop networks with arbitrary topologies 103 and link technologies, safe forwarding even during periods of 104 temporary loops, and support for multi-pathing of both unicast and 105 multicast traffic. TRILL accomplishes this with the IS-IS 106 (Intermediate System to Intermediate System) [IS-IS] [RFC1195] 107 [rfc6326bis] link-state routing protocol using a header with a hop 108 count. The design supports optimization of the distribution of 109 multi-destination frames and two types of data labeling: VLANs 110 (Virtual Local Area Networks [RFC6325]) and FGLs (Fine Grained 111 Labels, [RFCfgl]). Devices that implement TRILL are called TRILL 112 switches or RBridges (Routing Bridges). 114 There are five ways a TRILL switch can learn end station addresses, 115 as described in Section 4.8 of [RFC6325]. One of these is the ESADI 116 (End Station Address Distribution Information) protocol, which is an 117 optional Data Label scoped way TRILL switches can communicate, with 118 each other, information such as end station addresses and their TRILL 119 switch of attachment. A TRILL switch that is announcing interest in a 120 Data Label MAY use the ESADI protocol to announce the end station 121 address of some or all of its attached end stations in that Data 122 Label to other TRILL switches that are running ESADI for that Data 123 Label. (In the future, ESADI may also be used for additional types of 124 information.) 126 By default, TRILL switches with connected end stations learn 127 addresses from the data plane when ingressing and egressing native 128 frames although such learning can be disabled. The ESADI protocol's 129 potential advantages over data plane learning include the following: 131 1. Security advantages: (1a) The ESADI protocol can be used to 132 announce end stations with an authenticated enrollment (for 133 example enrollment authenticated by cryptographically based EAP 134 (Extensible Authentication Protocol [RFC3748]) methods via 135 [802.1X]). (1b) The ESADI protocol supports cryptographic 136 authentication of its message payloads for more secure 137 transmission. 139 2. Fast update advantages: The ESADI protocol provides a fast update 140 of end station MAC (Media Access Control) addresses and their 141 TRILL switch of attachment. If an end station is unplugged from 142 one TRILL switch and plugged into another, frames ingressed for 143 that end station's MAC address can be black holed. That is, they 144 can be sent just to the older egress TRILL switch that the end 145 station was connected to until cached address information at some 146 remote ingress TRILL switch times out, possibly for tens of 147 seconds [RFC6325]. 149 MAC address reachability information, some ESADI parameters, and 150 optional authentication information are carried in ESADI packets 151 rather than in the TRILL IS-IS protocol. As specified below, ESADI 152 is, for each Data Label, a virtual logical topology overlay in the 153 TRILL topology. An advantage of using ESADI over using TRILL IS-IS is 154 that the end station attachment information is not flooded to all 155 TRILL switches but only to TRILL switches advertising ESADI 156 participation for the Data Label in which those end stations occur. 158 1.1 Content and Precedence 160 This document updates [RFC6325], the TRILL base protocol 161 specification, obsoleting and replacing the description of the TRILL 162 ESADI protocol (Section 4.2.5 of [RFC6325] including all 163 subsections), providing more detail on ESADI, updating other ESADI 164 related sections of [RFC6325], and prevailing over [RFC6325] in any 165 case where they conflict. For this reason, familiarity with [RFC6325] 166 is particularly assumed. These changes include a change to the 167 format of ESADI-LSPs that is not backwards compatible; this change is 168 justified by the substantially increased amount of information that 169 can be carried and in light of the very limited, if any, deployment 170 of RFC 6325 ESADI. These changes are further discussed in Appendix 171 A. 173 Section 2 of this document is the ESADI protocol overview. Section 3 174 specifies ESADI DRB (Designated RBridge) determination. Section 4 175 discusses the processing of ESADI PDUs (Protocol Data Units). Section 176 5 discusses interaction with other modes of end station address 177 learning. And Section 6 describes the ESADI-LSP (Link State PDU) and 178 its contents. 180 1.2 Terminology 182 This document uses the acronyms defined in [RFC6325] and the 183 following: 185 Data Label - VLAN or FGL. 187 ESADI RBridge - An RBridge that is participating in ESADI for one 188 or more Data Labels. 190 FGL - Fine Grained Label [RFCfgl]. 192 LSP - Link State PDU [IS-IS]. 194 LSP number zero - A Link State PDU with fragment number equal to 195 zero. 197 PDU - Protocol Data Unit. 199 TRILL switch - an alternative name for an RBridge. 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 [RFC2119]. 205 Capitalized IANA Considerations terms such as "IETF Review" as to be 206 interpreted as described in [RFC5226]. 208 2. ESADI Protocol Overview 210 ESADI is a Data Label scoped way for TRILL switches (also known as 211 RBridges) to announce and learn end station addresses rapidly and 212 securely. An RBridge that is announcing participation in ESADI for 213 one or more Data Labels is called an ESADI RBridge. 215 ESADI is a separate optional protocol from the mandatory TRILL IS-IS 216 implemented by all RBridges in a campus. There is a separate ESADI 217 instance for each Data Label (VLAN or FGL) if ESADI is being used for 218 that Data Label. In essence, for each such Data Label, there is a 219 modified instance of the IS-IS reliable flooding mechanism in which 220 ESADI RBridges may choose to participate. (These are not the 221 instances specified in [RFC6822].) Multiple ESADI instances may share 222 implementation components within an RBridge as long as that sharing 223 preserves the independent operation of each instance of the ESADI 224 protocol. For example, the ESADI link state database could be in a 225 single database with a field in each record indicating the Data Label 226 to which it applies or could be a separate database per Data Label. 227 But the ESADI update process operates separately for each ESADI 228 instance and independently from the TRILL IS-IS update process. 230 ESADI does no routing calculations so there is no reason for pseudo- 231 nodes in ESADI and none are created (Pseudo-nodes [IS-IS] are a 232 construct for optimizing routing calculations.) Furthermore, there 233 may be a requirement for a relatively large amount of data to be 234 distributed through ESADI which might take a large number of ESADI- 235 LSP fragments. ESADI-LSP, ESADI-CSNP, and ESADI-PSNP (ESADI Link 236 State PDU, Complete Sequence Number PDU, and Partial Sequence Number 237 PDU) payloads are therefore formatted as Extended Level 1 Circuit 238 Scope (E-L1CS) PDUs [FS-LSP] (see also Section 6). This allows up to 239 2**16 fragments but does not support link state data associated with 240 pseudo-nodes. 242 After the TRILL header, ESADI packets have an inner Ethernet header 243 with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All- 244 ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL of 245 interest, and the "L2-IS-IS" Ethertype followed by the ESADI payload 246 as shown in Figure 1. 248 +--------------------------------+ 249 | Link Header | 250 +--------------------------------+ 251 | TRILL Data Header | 252 +--------------------------------+ 253 | Inner Ethernet Addresses | 254 +--------------------------------+ 255 | Data Label | 256 +--------------------------------+ 257 | L2-IS-IS Ethertype | 258 +--------------------------------+ 259 | ESADI Payload | 260 +--------------------------------+ 261 | Link Trailer | 262 +--------------------------------+ 264 Figure 1. TRILL ESADI Packet Overview 266 TRILL ESADI packets sent on an Ethernet link are structured as shown 267 below. The outer VLAN tag will not be present if it was not included 268 by the Ethernet port that sent the packet. 270 Outer Ethernet Header: 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Next Hop Destination Address | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Next Hop Destination Addr. | Sending RBridge Port MAC Addr.| 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Sending RBridge Port MAC Address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 ...Ethernet frame tagging including optional Outer.VLAN tag... 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Ethertype = TRILL 0x22F3 | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | V | R |M|Op-Length| Hop Count | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Egress Nickname | Ingress (Origin) Nickname | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Inner Ethernet Header: 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | All-Egress-RBridges | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | All-Egress-RBridges cont. | Origin RBridge MAC Address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Origin RBridge MAC Address continued | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | VLAN or FGL Data Label (4 or 8 bytes) [RFCfgl] ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Ethertype = L2-IS-IS 0x22F4 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ESADI Payload (formatted as IS-IS): 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Frame Check Sequence: 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | FCS (Frame Check Sequence) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 2: ESADI Ethernet Link Packet Format 310 The Next Hop Destination Address or Outer.MacDA is the All-RBridges 311 multicast address if the ESADI PDU is being multicast. If it is being 312 unicast, the Next Hop Destination Address is the unicast address of 313 the next hop RBridge. The VLAN for the Outer.VLAN information, if 314 present, will be the Designated VLAN for the link on which the packet 315 is sent. The V and R fields will be zero while the M field will be 316 one unless the ESADI PDU was unicast, in which case the M field will 317 be zero. The Data Label specified will be the VLAN or FGL to which 318 the ESADI packet applies. The Origin RBridge MAC Address or 319 Inner.MacSA MUST be a MAC address unique across the campus owned by 320 the RBridge originating the ESADI packet, for example, any of its 321 port MAC addresses if it has any Ethernet ports, and each RBridge 322 MUST use the same Inner.MacSA for all of the ESADI packets that 323 RBridge originates. 325 TRILL ESADI packets sent on a PPP link are structured as shown below 326 [RFC6361]. 328 PPP Header: 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | PPP = TNP (TRILL data) 0x005D | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | V | R |M|Op-Length| Hop Count | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Egress Nickname | Ingress (Origin) Nickname | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Inner Ethernet Header: 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | All-Egress-RBridges | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | All-Egress-RBridges cont. | Origin RBridge MAC Address | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Origin RBridge MAC Address continued | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | VLAN or FGL Data Label (4 or 8 bytes) [RFCfgl] ... 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Ethertype = L2-IS-IS 0x22F4 | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 ESADI Payload (formatted as IS-IS): 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 PPP Check Sequence: 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | PPP Check Sequence | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 3: ESADI PPP Link Packet Format 360 2.1 ESADI Virtual Link 362 All RBridges forward ESADI packets as if they were ordinary TRILL 363 Data packets. Because of this forwarding, it appears to an instance 364 of the ESADI protocol at an RBridge that it is directly connected by 365 a multi-access virtual link to all RBridges in the campus that are 366 data reachable from it (see Section 2 of [ClearCorrect]) and are 367 running ESADI for that Data Label. No "routing" calculation (least 368 cost path or distribution tree construction) ever has to be performed 369 by ESADI. An ESADI RBridge merely transmits the ESADI packets it 370 originates on this virtual link as described for TRILL Data packets 371 in [RFC6325] and [RFCfgl]. For multicast ESADI packets it may use any 372 distribution tree that it might use for an ordinary multi-destination 373 TRILL Data packet. RBridges that do not implement the ESADI protocol, 374 do not have it enabled, or are not participating for the Data Label 375 of an ESADI packet do not decapsulate or locally process the TRILL 376 ESADI packet. Thus, ESADI packets are transparently tunneled through 377 transit RBridges. 379 2.2 ESADI Neighbor Determination 381 The ESADI instance for Data Label X at an RBridge RB1 determines who 382 its adjacent ESADI neighbors are by examining the TRILL IS-IS link 383 state database for RBridges that are data reachable from RB1 (see 384 Section 2 of [ClearCorrect]) and are announcing their participation 385 in Data Label X ESADI. When an RBridge RB2 becomes data unreachable 386 from RB1 or the relevant entries for RB2 are purged from the core IS- 387 IS link state database, it is lost as a neighbor and also dropped 388 from any ESADI instances from the point of view of RB1, and when RB2 389 is no longer announcing participation in Data Label X ESADI, it 390 ceases to be a neighbor for any Data Label X ESADI instance. All 391 these considerations are Data Label scoped. Because of these 392 mechanisms whereby an ESADI instance at an ESADI RBridge can 393 determine its ESADI adjacencies by examining the TRILL IS-IS link 394 state database, there are no "Hellos" sent in ESADI and no adjacency 395 information is carried in ESADI-LSPs. 397 Participation announcement in a VLAN scoped ESADI instance is through 398 setting a flag bit in the Interested VLANs sub-TLV and announcement 399 for an FGL scoped ESADI instance is through setting a flag bit in the 400 Interested Labels sub-TLV [rfc6326bis]. (See Section 7.1) 402 2.3 ESADI Payloads 404 TRILL ESADI packet payloads are structured like IS-IS Extended Level 405 1 Circuit Scoped (E-L1CS) LSP, CSNP, and PSNP PDUs [FS-LSP], except 406 as indicated below, but are always TRILL encapsulated on the wire as 407 if they were TRILL Data packets. The information distributed by the 408 ESADI protocol includes a list of local end station MAC addresses 409 connected to the originating RBridge and, for each such address, a 410 one octet unsigned "confidence" rating in the range 0-254 (see 411 Section 6.2). It is entirely up to the originating RBridge which 412 locally connected MAC addresses it wishes to advertise via ESADI and 413 with what confidence. It MAY advertise all, some, or none of such 414 addresses. In addition, some ESADI parameters of the advertising 415 RBridge (see Section 6.1) and optionally authentication information 416 (see Section 6.3) are included. Future uses of ESADI may distribute 417 other types of information. 419 TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload. 420 The Data Label to which the ESADI data applies is the Data Label of 421 the TRILL Data packet enclosing the ESADI payload. If a Data Label ID 422 could occur within the payload, it might conflict with that TRILL 423 Data packet Data Label and could conflict with any future Data Label 424 mapping scheme that may be adopted [VLANmapping]. If a VLAN or FGL ID 425 field within an ESADI-LSP PDU does include a value, that field's 426 contents MUST be ignored. 428 3. ESADI DRB (Designated RBridge) Determination 430 Because ESADI does no adjacency announcement or routing, the ESADI- 431 DRB never creates a pseudonode. But a DRB (Designated RBridge 432 [rfc6327bis]) is still needed for ESADI-LSP synchronization by 433 issuing ESADI-CSNP PDUs and responding to ESADI-PSNP PDUs. 435 Generally speaking, the DRB election on the ESADI virtual link (see 436 Section 2.1) operates similarly to the DRB election on a TRILL IS-IS 437 broadcast link, as described in Section 4.2.1 ("DRB Election 438 Details") of [rfc6327bis], with the following exceptions: In the Data 439 Label X ESADI-DRB election at RB1 on an ESADI virtual link, the 440 candidates are the local ESADI instance for Data Label X and all 441 remote ESADI instances at RBridges that (1) are data reachable from 442 RB1 [ClearCorrect], and (2) are announcing in their TRILL IS-IS LSP 443 that they are participating in ESADI for Data Label X. The winner is 444 the instance with the highest ESADI Parameter 7-bit priority field 445 with ties broken by System ID, comparing fields as unsigned integers 446 with the larger magnitude considered higher priority. "SNPA/MAC 447 address" is not considered in this tie breaking and there is no "Port 448 ID". 450 4. ESADI PDU processing 452 Data Label X ESADI neighbors are usually not connected directly by a 453 physical link, but are always logically connected by a virtual link 454 (see Section 2.1). There could be hundreds or thousands of ESADI 455 RBridges (TRILL switches) on the virtual link. There are only ESADI- 456 LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI. In particular, 457 there are no Hello or MTU PDUs because ESADI does not build a 458 topology, does not do any routing calculations, and does not 459 determine MTU, using the campus Sz. (Sz is the TRILL campus wide 460 minimum link MTU (see [RFC6325] and [ClearCorrect]).) 462 4.1 Unicasting ESADI PDUs 464 For [IS-IS], PDU multicasting is normal on a local link and no effort 465 is made to optimize to unicast because on the typical physical link 466 for which IS-IS was designed (commonly a piece of multi-access 467 Ethernet cable) any frame made the link busy for that frame time. But 468 to ESADI instances, what appears to be a simple multi-access link is 469 generally a set of multi-hop distribution trees that may or may not 470 be pruned. Thus, transmitting a multicast frame on such a tree can 471 impose a substantially greater load than transmitting a unicast 472 frame. This load may be justified if there are likely to be multiple 473 listeners but may not be justified if there is only one recipient of 474 interest. For this reason, under some circumstances, ESADI PDUs MAY 475 be TRILL unicast if it is confirmed that the destination RBridge 476 supports receiving unicast ESADI PDUs (see Section 6.1). 478 The format of a unicast ESADI packet is the format of a multicast 479 TRILL ESADI packet, in Section 2 above, except as follows: 481 o On an Ethernet link, in the Outer Ethernet Header the Outer.MacDA 482 is the unicast address of the next hop RBridge. 484 o In the TRILL header, the M bit is set to zero and the Egress 485 Nickname is the nickname of the destination RBridge. 487 To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is 488 replaced with the following: 490 "4.6.2.2. TRILL ESADI Packets 492 If M=1, the egress nickname designates the distribution tree. The 493 packet is forwarded as described in Section 4.6.2.5. In addition, 494 if the forwarding RBridge is (1) interested in the specified VLAN 495 or Fine Grained Label [RFCfgl], (2) implements the TRILL ESADI 496 protocol, and (3) ESADI is enabled for that VLAN or Fine Grained 497 Label, the inner frame is decapsulated and provided to that local 498 ESADI protocol. 500 If M=0 and the egress nickname is not that of the receiving 501 RBridge, the packet is forwarded as for known unicast TRILL Data 502 in Section 4.6.2.4. If M=0 and the egress nickname is that of the 503 receiving RBridge and the receiving RBridge supports unicast ESADI 504 PDUs, then the ESADI packet is decapsulated and processed if it 505 meets the three numbered conditions in the paragraph above, 506 otherwise it is discarded." 508 The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to 509 those sections in [RFC6325]. 511 4.2 General Transmission of ESADI PDUs 513 Following the usual [IS-IS] rules, an ESADI instance does not 514 transmit any ESADI PDUs if it has no ESADI adjacencies. Such 515 transmission would just be a waste of bandwidth. 517 The MTU available to ESADI payloads is at least 24 bytes less than 518 that available to TRILL IS-IS because of the additional fields 519 required ( 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 520 6(Inner.MacSA) + 4/8(Data Label) bytes). Thus the inner ESADI 521 payload, starting with the Intradomain Routeing Protocol 522 Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI 523 instance or Sz minus 28 for an FGL ESADI instance; however, if a 524 larger payload is received, it is processed normally. (See [RFC6325] 525 and [ClearCorrect] for discussions of Sz and MTU.) 527 In all cases where this document says that an ESADI PDU is multicast, 528 if the transmitting RBridge has only one neighbor and that neighbor 529 advertises support for unicast, the PDU MAY be unicast (see Section 530 4.1). 532 A priority bit to indicate that an LSP fragment should be flooded 533 with high priority is provided by [FS-LSP]. This bit SHOULD be set on 534 ESADI-LSP fragment zero because it is important that the ESADI 535 Parameters APPsub-TLV get through promptly. This bit SHOULD NOT be 536 set on other ESADI-LSP fragments to avoid giving undue priority to 537 less urgent PDUs. 539 4.3 General Receipt of ESADI PDUs 541 In contrast with layer 3 IS-IS PDU acceptance tests, which check the 542 source inner and outer SNPA/MAC in order to verify that a PDU is from 543 an adjacent TRILL switch, in TRILL ESADI, adjacency is based on 544 system ID, so the system ID inside the PDU is all that is tested for. 546 If an ESADI instance believes that it has no ESADI neighbors, it 547 ignores any ESADI PDUs it receives. 549 4.4 ESADI Reliable Flooding 551 The IS-IS reliable flooding mechanism (the Update Process) is 552 modified for ESADI in the ways listed below. Except as otherwise 553 stated, the ESADI update process works as described in [IS-IS], 554 [RFC1195], and [FS-LSP]. 556 When an ESADI instance sees that it has a new ESADI neighbor, its 557 self-originated EASDI-LSP fragments are scheduled to be sent and MAY 558 be unicast to that neighbor if the neighbor is announcing in its LSP 559 that it supports unicast ESADI (see Section 6.1). If all the other 560 ESADI instances for the same Data Label send their self-originated 561 ESADI-LSPs immediately, there may be a surge of traffic to that new 562 neighbor. So the ESADI instances SHOULD wait an interval of time 563 before sending their ESADI-LSP(s) to a new neighbor. The interval 564 time value is up to the device implementation. One suggestion is that 565 the interval time can be assigned a random value with a range based 566 on the RBridge's nickname (or any one of its nicknames if it holds 567 more than one) such as ( 2000 * nickname / 2**16 ) milliseconds 568 assuming "nickname" to be an unsigned quantity. 570 All the TRILL switches participating in an ESADI instance for some 571 Data Label appear to ESADI to be adjacent. Thus the originator of any 572 active ESADI-LSP fragment always appears to be on link and, to spread 573 the burden of such response, could be the RBridge to respond to any 574 ESADI-CSNP or PSNP request for that fragment. However, under very 575 rare circumstances, it could be that some version of the LSP fragment 576 with a higher sequence number is actually held by another ESADI 577 RBridge on the link, so non-originators need to be able to respond 578 eventually. Thus, when the receipt of a CSNP or PSNP causes the 579 SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP 580 fragment, action is as specified in [IS-IS] for the originating ESADI 581 RBridge of the fragment; however, at a non-originating ESADI RBridge, 582 when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS] 583 is also set to the current time minus 585 minimumLSPTimeInterval * Random (Jitter) / 100 587 (where minimumLSPTimeInterval, Random, and Jitter are as in [IS-IS]). 588 This will delay and jitter the transmission of the LSP fragment by 589 non-originators. This gives the originator more time to send the 590 fragment and provides more time for such an originator transmitted 591 copy to traverse the likely multi-hop path to non-originators and 592 clear the SRMflag for the fragment at non-originators. 594 The multi-hop distribution tree method with Reverse Path Forwarding 595 Check used for multicast distribution by TRILL will typically be less 596 reliable than transmission over a single local broadcast link hop. 597 For LSP synchronization robustness, in addition to sending ESADI- 598 CSNPs as usual when it is DRB, an ESADI RBridge SHOULD also transmit 599 an ESADI-CSNP for an ESADI instance if all of the following 600 conditions are met: 602 o it sees one or more ESADI neighbors for that instance, and 603 o it does not believe it is DRB for the ESADI instance, and 604 o it has not received or sent an ESADI-CSNP PDU for the instance for 605 the average of the CSNP Time (see Section 6.1) of the DRB and its 606 CSNP Time. 608 5. End Station Addresses 610 The subsections below discuss end station address considerations in 611 the context of ESADI. 613 5.1 Learning Confidence Level 615 The confidence level mechanism [RFC6325] allows an RBridge campus 616 manager to cause certain address learning sources to prevail over 617 others. MAC address information learned through a registration 618 protocol, such as [802.1X] with a cryptographically based EAP 619 [RFC3748] method, might be considered more reliable than information 620 learned through the mere observation of data traffic. When such 621 authenticated learned address information is transmitted via the 622 ESADI protocol, the use of authentication in the TRILL ESADI-LSP 623 packets could make tampering with it in transit very difficult. As a 624 result, it might be reasonable to announce such authenticated 625 information via the ESADI protocol with a high confidence, so it 626 would be used in preference to any alternative learning from data 627 observation. 629 5.2 Forgetting End Station Addresses 631 The end station addresses learned through the TRILL ESADI protocol 632 should be forgotten through changes in ESADI-LSPs. The time out of 633 the learned end station address is up to the originating RBridge that 634 decides when to remove such information from its ESADI-LSPs (or up to 635 ESADI protocol timeouts if the originating RBridge becomes 636 unreachable). 638 If RBridge RBn participating in the TRILL ESADI protocol for Data 639 Label X no longer wishes to participate in ESADI, it ceases to 640 participate by (1) clearing the ESADI participation bit in the 641 appropriate Interested VLANs or Interested Labels sub-TLV and (2) 642 sending a final ESADI-LSP nulling out its ESADI-LSP information. 644 5.3 Duplicate MAC Address 646 With ESADI, it is possible to persistently see occurrences of the 647 same MAC address in the same Data Label being advertised as reachable 648 by two or more RBridges. The specification of how to handle this 649 situation in [RFC6325] is updated by replacing the last sentence of 650 the last paragraph of Section 4.2.6 of [RFC6325] as shown below to 651 provide better traffic spreading while avoiding possible address 652 flip-flopping. 654 As background, assume some end station or set of end stations ESn 655 have two or more ports with the same MAC address in the same Data 656 Label with the ports connected to different RBridges (RB1, RB2, ...) 657 by separate links. With ESADI, some other RBridge, RB0, can 658 persistently see that MAC address in that Data Label connected to 659 multiple RBridges. When RB0 ingresses a frame, say from ES0, destined 660 for that MAC and label, the current [RFC6325] text permits a wide 661 range of behavior. In particular, [RFC6325] would permit RB0 to use 662 some rule such as always encapsulate to the egress with the lowest 663 System ID, which would put all of this traffic through only one of 664 the egress RBridges and one of the end station ports. With that 665 behavior, there would be no load spreading, even if there were 666 multiple different ingress RBridges and/or different MAC addresses 667 with the same reachability. [RFC6325] also would also permit RB0 to 668 send different traffic to different egresses by doing ECMP at a flow 669 level, which would likely result in return traffic for RB0 to egress 670 to ES0 from various of RB1, RB2, ... for the same MAC and label. The 671 resulting address reachability flip-flopping perceived at RB0 could 672 cause problems. 674 This update to [RFC6325] avoids these potential difficulties by 675 requiring RB0 to use one of the following two policies: (1) only 676 encapsulate to one egress RBridge for any particular MAC and label 677 but to select that egress pseudo-randomly based on the topology 678 including MAC reachability or (2) if it will not be disturbed by the 679 returning TRILL Data packets showing the same MAC and label flip- 680 flopping between different ingresses, it may use ECMP. Assuming 681 multiple ingress RBridges and/or multiple MAC and label addresses, 682 strategy 1 should result in load spreading without address flip- 683 flopping while strategy 2 will produce better load spreading than 684 strategy 1 but with address flip-flopping from the point of view of 685 RB0. 687 OLD [RFC6325] Section 4.2.6 text: 688 "... If confidences are also tied between the duplicates, for 689 consistency it is suggested that RB2 direct all such frames (or 690 all such frames in the same ECMP flow) toward the same egress 691 RBridge; however, the use of other policies will not cause a 692 network problem since transit RBridges do not examine the 693 Inner.MacDA for known unicast frames." 695 NEW [RFC6325] Section 4.2.6 text: 696 "... 698 If confidences are also tied between the duplicates then RB2 MUST 699 adopt one of the following two strategies: 701 1. In a pseudo-random way [RFC4086], select one of the egress 702 RBridges that is least cost from RB2 and to which the 703 destination MAC appears to be attached and send all traffic for 704 the destination MAC and VLAN (or FGL [RFCfgl]) to that egress. 705 This pseudo-random choice need only be changed when there is a 706 change in campus topology or MAC attachment information. Such 707 pseudo-random selection will, over a population of ingress 708 RBridges, probabilistically spread traffic over the possible 709 egress RBridges. Reasonable inputs to the pseudo-random 710 selection are the ingress RBridge System ID and/or nickname, 711 the VLAN or FGL, the destination MAC address, and a vector of 712 the RBridges with connectivity to that MAC and VLAN or FGL. 713 There is no need for different RBridges to use the same pseudo- 714 random function. 716 As an example of such a pseudo-random function, if there are k 717 egress RBridges (RB0, RB1, ..., RB(k-1)) all reporting 718 attachment to address MACx in Data Label DLy, then an ingress 719 RBridge RBin could select the one to which it will send all 720 unicast TRILL Data packets addressed to MACx in DLy based on 721 the following: 723 FNV-32(RBin | MACx | DLy | RB0 | RB1 | ... | RB(k-1)) mod k 725 where FNV is specified in [FNV], RBx means the nickname for 726 RBridge RBx, "|" means concatenation, MACx is the 727 destination MAC address, DLy is the Data Label, and "mod k" 728 means the integer division remainder of the output of the 729 FNV-32 function considered as a positive integer divided by 730 k. 732 2. If RB2 supports ECMP and will not be disturbed by return 733 traffic from the same MAC and VLAN (or FGL [RFCfgl]) coming 734 from a variety of different RBridges, then it MAY send traffic 735 using ECMP at the flow level to the egress RBridges that are 736 least cost from RB2 and to which the destination MAC appears to 737 be attached." 739 6. ESADI-LSP Contents 741 The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI- 742 PSNP PDUs. Currently, the contents of an ESADI-LSP consists of zero 743 or more MAC Reachability TLVs, optionally an Authentication TLV, and 744 exactly one ESADI parameter APPsub-TLV. Other data may be included in 745 the future and, as in [IS-IS], an ESADI instance ignores any TLVs or 746 sub-TLVs it does not understand. Because these PDUs are formatted as 747 Extended Level 1 Circuit Scope (E-L1CS) PDUs [FS-LSP], the Type and 748 Length fields in the TLVs are 16-bit. 750 This section specifies the format for the ESADI parameter data 751 APPsub-TLV, gives the reference for the ESADI MAC Reachability TLV, 752 and discusses default authentication configuration. 754 For robustness, the payload for an ESADI-LSP number zero and any 755 ESADI-CSNP or ESADI-PSNP covering fragment zero MUST NOT exceed 1470 756 minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN or 1470 757 minus 28 bytes (1442 bytes) if it has an Inner.FGL. But if an ESADI- 758 LSP number zero or such an ESADI-CSNP or ESADI-PSNP is received that 759 is longer, it is still processed normally. (As stated in Section 760 4.3.1 of [RFC6325], 1470 bytes was chosen to make it extremely 761 unlikely that a TRILL control packet, even with reasonable additional 762 headers, tags, and/or encapsulation, would encounter MTU problems on 763 an inter-RBridge link.) 765 6.1 ESADI Parameter Data 767 The figure below presents the format of the ESADI parameter data. 768 This APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP 769 number zero. If it is missing from ESADI-LSP number zero or if ESADI- 770 LSP number zero is not known, priority for the sending RBridge 771 defaults to 0x40 and CSNP Time defaults to 30. If there is more than 772 one occurrence in ESADI-LSP number zero, the first occurrence will be 773 used. Occurrences of the ESADI parameter data APPsub-TLV in non-zero 774 ESADI-LSP fragments are ignored. 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | (2 byte) 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Length | (2 byte) 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 |R| Priority | (1 byte) 782 +-+-+-+-+-+-+-+-+ 783 | CSNP Time | (1 byte) 784 +-+-+-+-+-+-+-+-+ 785 | Flags | (1 byte) 786 +---------------+ 787 | Reserved for expansion (variable) 788 +-+-+-+-... 790 Figure 4. ESADI Parameter APPsub-TLV 792 Type: set to ESADI-PARAM subTLV (TRILL APPsub-TLV type 0x0001). Two 793 bytes because this APPsub-TLV appears in an Extended TLV [FS-LSP]. 795 Length: Variable with a minimum of 3 but must fit within the ESADI 796 packet. 798 R: A reserved bit that MUST be sent as zero and ignored on receipt. 800 Priority: The Priority field gives the originating RBridge's priority 801 for being DRB on the ESADI instance virtual link (see Section 3) 802 for the Data Label in which the PDU containing the parameter data 803 was sent. It is an unsigned seven-bit integer with larger 804 magnitude indication higher priority. It defaults to 0x40 for an 805 RBridge participating in ESADI for which it has not been 806 configured. 808 CSNP Time: An unsigned byte that gives the amount of time in seconds 809 during which the originating RBridge, if it is DRB on the ESADI 810 virtual link, will send at least three EASDI-CSNP PDUs. It 811 defaults to 30 seconds for an RBridge participating in ESADI for 812 which it has not been configured. 814 Flags: A byte of flags associated with the originating ESADI instance 815 as follows: 817 0 1 2 3 4 5 6 7 818 +---+---+---+---+---+---+---+---+ 819 | UN| RESV | 820 +---+---+---+---+---+---+---+---+ 822 The UN flag indicates that the RBridge originating the ESADI- 823 LSP, including this ESADI Parameter Data, will accept and 824 properly process ESADI PDUs sent by TRILL unicast (see Section 825 4.1). The remaining RESV bits are reserved for future use and 826 MUST be sent as zero and ignored on receipt. 828 Reserved for future expansion: Future versions of the ESADI 829 Parameters APPsub-TLV may have additional information. A receiving 830 ESADI RBridge ignores any additional data here unless it 831 implements such future expansion(s). 833 6.2 MAC Reachability TLV 835 The primary information in TRILL ESADI-LSP PDUs consists of MAC 836 Reachability (MAC-RI) TLVs specified in [RFC6165]. These TLVs 837 contain one or more unicast MAC addresses of end stations that are 838 both on a port and in a VLAN for which the originating RBridge is 839 appointed forwarder, along with the one octet unsigned Confidence in 840 this information with a value in the range 0-254. If such a TLV is 841 received containing a confidence of 255, it is treated as if the 842 confidence was 254. (This is to assure that any received address 843 information can be overridden by local address information statically 844 configured with a Confidence of 255.) 846 The TLVs in TRILL ESADI PDUs, including the MAC-RI TLV, MUST NOT 847 contain the Data Label ID. If a Data Label ID is present in the MAC- 848 RI TLV, it is ignored. In the ESADI PDU, only the Inner.VLAN or 849 Inner.FGL tag indicates the Data Label to which the ESADI-LSP 850 applies. 852 6.3 Default Authentication 854 The Authentication TLV may be included in ESADI PDUs. The default for 855 ESADI PDU Authentication is based on the state of TRILL IS-IS shared 856 secret authentication for TRILL IS-IS LSP PDUs. If TRILL IS-IS 857 authentication and ESADI are implemented at a TRILL switch, then 858 ESADI MUST be able to use the authentication algorithms implemented 859 for TRILL IS-IS and implement the keying material derivation function 860 given below. If ESADI authentication has been manually configured, 861 that configuration is not restricted by the configuration of TRILL 862 IS-IS security. 864 If TRILL IS-IS authentication is not in effect for LSP PDUs 865 originated by a TRILL switch then, by default, ESADI PDUs originated 866 by that TRILL switch are also unsecured. 868 If such IS-IS LSP PDU authentication is in effect at a TRILL switch 869 then, unless configured otherwise, ESADI PDUs sent by that switch 870 MUST use the same algorithm in their Authentication TLVs. The ESADI 871 authentication keying material used is derived from the IS-IS LSP 872 shared secret keying material as detailed below. However, such 873 authentication MAY be configured to use some other keying material. 875 HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key ) 877 In the above HMAC-SHA256 is as described in [FIPS180] [RFC6234] and 878 "TRILL ESADI" is the eleven byte US ASCII [ASCII] string indicated. 879 IS-IS-LSP-shared-key is secret keying material being used by the 880 originating TRILL switch for IS-IS LSP authentication. 882 7. IANA Considerations 884 IANA allocation and registry considerations are given below. Three 885 new sub-registries are created in the TRILL Parameters registry 886 located at http://www.iana.org/assignments/trill-parameters, two in 887 Section 7.1 and one in Section 7.2, and various code points assigned. 889 7.1 ESADI Participation and Capability Flags 891 IANA Action 1: 893 IANA is requested to create the following new sub-registry called 894 "Interested VLANs Flag Bits" in the TRILL Parameters registry. 896 Sub-Registry: Interested VLANs Flag Bits 898 Registration Procedures: IETF Review 900 Note: These bits appear in the Interested VLANs record within the 901 Interested VLANs and Spanning Tree Roots Sub-TLV (INT-VLAN) 902 specified in [rfc6326bis]. 904 References: [rfc6326bis], [This document] 906 Bit Mnemonic Description Reference 907 --- -------- ----------- --------- 908 0 M4 IPv4 Multicast Router Attached [rfc6326bis] 909 1 M6 IPv6 Multicast Router Attached [rfc6326bis] 910 2 - Unassigned 911 3 ES ESADI Participation This document 912 4-15 - (used for a VLAN ID) [rfc6326bis] 913 16-19 - Unassigned 914 20-31 - (used for a VLAN ID) [rfc6326bis] 916 The creation of this sub-registry as immediately above assigns bit 3 917 as the ESADI Participation bit in the the Interested VLANs and 918 Spanning Tree Roots Sub-TLV. If The ESADI Participation bit is a one, 919 it indicates that the originating RBridge is participating in ESADI 920 for the indicated Data Label(s). 922 IANA Action 2: 924 IANA is requested to create the following new sub-registry called 925 "Interested Labels Flag Bits" in the TRILL Parameters registry. 927 Sub-Registry: Interested Labels Flag Bits 929 Registration Procedures: IETF Review 931 Note: These bits appear in the Interested Labels record within the 932 Interested Labels and Spanning Tree Roots Sub-TLV (INT-LABEL) 933 specified in [rfc6326bis]. 935 References: [rfc6326bis], [this document] 937 Bit Mnemonic Description Reference 938 --- -------- ----------- --------- 939 0 M4 IPv4 Multicast Router Attached [rfc6326bis] 940 1 M6 IPv6 Multicast Router Attached [rfc6326bis] 941 2 BM Bit Map [rfc6326bis] 942 3 ES ESADI Participation This document 943 4-7 - Unassigned 945 The creation of this sub-registry as immediately above assigns bit 3 946 as the ESADI Participation bit in the the Interested Labels and 947 Spanning Tree Roots Sub-TLV. If The ESADI Participation bit is a one, 948 it indicates that the originating RBridge is participating in ESADI 949 for the indicated Data Label(s). 951 7.2 TRILL GENINFO TLV 953 IANA Action 3: 955 IANA is requested to allocate the IS-IS Application Identifier TBD 956 [1 suggested] under the Generic Information TLV (#251) [RFC6823] 957 for TRILL. 959 IANA Action 4: 961 IANA is requested to create a subregistry in the TRILL Parameters 962 Registry as follows: 964 Sub-Registry: TRILL APPsub-TLV Types under IS-IS TLV #251 965 Application Identifier #TBD 967 Registration Procedures: IETF Review with additional 968 requirements on the documentation of the use being 969 registered as specified in Section 7.2 of . 972 Note: Types greater than 255 are only usable in contexts 973 permitting a type larger than one byte, such as Extended 974 TLVs [FS-LSP]. 976 Reference: 978 Type Name Reference 979 ---------- -------- ----------- 980 0 Reserved 981 1 ESADI-PARAM 982 2-254 Unassigned 983 255 Reserved 984 256-65534 Unassigned 985 65535 Reserved 987 TRILL APPsub-TLV Types 2 through 254 and 256 through 65534 are 988 available for assignment by IETF Review. The RFC causing such an 989 assignment will also include a discussion of security issues and of 990 the rate of change of the information being advertised. TRILL 991 APPsub-TLVs MUST NOT alter basic IS-IS protocol operation including 992 the establishment of adjacencies, the update process, and the 993 decision process for TRILL IS-IS [IS-IS], [RFC1195], [rfc6327bis]. 994 The TRILL Generic Information TLV MUST NOT be used in an IS-IS 995 instance zero [RFC6822] LSP but may be used in FS-LSPs [FS-LSP]. 997 The V, I, D, and S flags in the initial flags byte of a TRILL Generic 998 Information TLV have the meanings specified in [RFC6823] but are not 999 currently used as TRILL operates as a Level 1 IS-IS area and no 1000 semantics are hereby assigned to the inclusion of an IPv4 and/or IPv6 1001 address via the I and V flags. Thus these I and V flags MUST be zero; 1002 however, if either or both is one, the space that should be taken by 1003 and IPv4 and/or IPv6 address respectively is skipped over and 1004 ignored. Furthermore, use of multi-level IS-IS is an obvious 1005 extension for TRILL [MultiLevel] and future IETF Standards Actions 1006 may update or obsolete this specification to provide for the use of 1007 any or all of these flags in the TRILL GENINFO TLV. 1009 The ESADI Parameters information, for which TRILL APPsub-TLV 1 is 1010 hereby assigned, is compact and slow changing (see Section 6.1). 1012 For Security Considerations related to ESADI and the ESADI parameters 1013 APPsub-TLV, see Section 8. 1015 8. Security Considerations 1017 ESADI PDUs can be authenticated through the inclusion of the 1018 Authentication TLV as described in Section 6.3. The ESADI-LSP data 1019 primarily announces MAC address reachability within a Data Label. 1020 Such reachability can, in some cases, be an authenticated 1021 registration (for example, a layer 2 authenticated registration using 1022 cryptographically based EAP (Extensible Authentication Protocol 1023 [RFC3748]) methods via [802.1X]). The combination of these techniques 1024 can cause EASDI MAC reachability information to be substantially more 1025 trustworthy than MAC reachability learned from observation of the 1026 data plane. Nevertheless, ESADI still involves trusting all other 1027 RBridges in the TRILL campus, at least those that have the keying 1028 material necessary to construct a valid Authentication TLV. 1030 However, there may be cases where it is not necessary to authenticate 1031 ESADI PDUs despite using authenticated registration for end stations 1032 because of a significant threat of forged packets on end station 1033 links when that threat is not present for inter-RBridge trunks. For 1034 example a TRILL campus with secure RBridges and inter-RBridge links 1035 configured as trunks but some end stations connected via IEEE 802.11 1036 wireless access links might use 802.11 authentication for the 1037 connection of such end stations but not necessarily authenticate 1038 ESADI PDUs. Note that if the IS-IS LSPs in a TRILL campus are 1039 authenticated, perhaps due to a concern about forged packets, the 1040 ESADI PDUs will be authenticated by default as provided in Section 1041 6.3. 1043 MAC reachability learned from the data plane (the TRILL default) is 1044 overwritten by any future learning of the same type. ESADI 1045 advertisements are represented in Data Label scoped link state 1046 database. Thus ESADI makes visible any multiple attachments of the 1047 same MAC address within a Data Label to different RBridges (see 1048 Section 5.3). This may or may not be an error or misconfiguration but 1049 ESADI at least makes it explicitly and persistently visible, which 1050 would not be the case with data plane learning. 1052 For general TRILL Security Considerations, see [RFC6325]. 1054 9. Acknowledgements 1056 The authors thank the following, listed in alphabetic order, for 1057 their suggestions and contributions: 1059 David Black, Somnath Chatterjee, Sujay Gupta, Pearl Liang, Thomas 1060 Narten, Erik Nordmark, and Mingui Zhang. 1062 This document was produced with raw nroff. All macros used were 1063 defined in the source file. 1065 Normative references 1067 [ASCII] - American National Standards Institute (formerly United 1068 States of America Standards Institute), "USA Code for 1069 Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 1070 has been replaced by newer versions with slight modifications, 1071 but the 1968 version remains definitive for the Internet. 1073 [FIPS180] - "Secure Hash Standard (SHS)", United States of American, 1074 National Institute of Science and Technology, Federal 1075 Information Processing Standard (FIPS) 180-4, March 2012, 1076 http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf 1078 [IS-IS] - International Organization for Standardization, 1079 "Intermediate system to Intermediate system intra-domain 1080 routeing information exchange protocol for use in conjunction 1081 with the protocol for providing the connectionless-mode Network 1082 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 1083 2002. 1085 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1086 dual environments", RFC 1195, December 1990. 1088 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1089 Requirement Levels", BCP 14, RFC 2119, March 1997. 1091 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 1092 "Randomness Requirements for Security", BCP 106, RFC 4086, June 1093 2005. 1095 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 1096 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1097 2008. 1099 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1100 Layer-2 Systems", RFC 6165, April 2011. 1102 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1103 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1104 Specification", RFC 6325, July 2011. 1106 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1107 Interconnection of Lots of Links (TRILL) Protocol Control 1108 Protocol", RFC 6361, August 2011. 1110 [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising 1111 Generic Information in IS-IS", RFC 6823, December 2012. 1113 [ClearCorrect] - Eastlake, D., Zhang, M., Ghanwani, A., Manral, V., 1114 A. Benerjee, "TRILL: Clarifications, Corrections, and Updates", 1115 draft-ietf-trill-clear-correct, in RFC Editor's queue. 1117 [FS-LSP] - Ginsberg, L., S. Previdi, Y. Yang, "IS-IS Flooding Scope 1118 LSPs", draft-ietf-isis-fs-lsp, in RFC Editor's queue. 1120 [rfc6326bis] - Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, 1121 D., and A. Banerjee, "Transparent Interconnection of Lots of 1122 Links (TRILL) Use of IS-IS", draft-ietf-isis-rfc6326bis, in RFC 1123 Editor's queue. 1125 [rfc6327bis] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1126 and V. Manral, "Routing Bridges (RBridges): Adjacency", draft- 1127 ietf-trill-rfc6327bis, in RFC Editor's queue. 1129 [RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 1130 "TRILL (Transparent Interconnection of Lots of Links): Fine- 1131 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 1132 Ediotr's queue. 1134 Informative References 1136 [802.1X] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 1137 networks / Port-Based Network Access Control", IEEE Std 1138 802.1X-2010, 5 February 2010. 1140 [FNV] - G. Fowler, L. Noll, K. Vo & D. Eastlake, "The FNV Non- 1141 Cryptographic Hash Algorithm", draft-eastlake-fnv, Work in 1142 progress. 1144 [RFC3748] - Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1145 Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 1146 3748, June 2004. 1148 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1149 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 1150 2011. 1152 [RFC6822] - Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and 1153 D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1155 [MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai, 1156 "Multilevel TRILL (Transparent Interconnection of Lots of 1157 Links)", draft-perlman-trill-rbridge-multilevel, work in 1158 progress. 1160 [VLANmapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, 1161 and D. Eastlake, "RBridges: Campus VLAN and Priority Regions", 1162 draft-ietf-trill-rbridge-vlan-mapping, work in progress. 1164 Appendix A: Changes to [RFC6325] 1166 Below is a list of the main changes this document makes to the TRILL 1167 base protocol specification [RFC6325]: 1169 1. This document replaces Section 4.2.5 of [RFC6325] ("The TRILL 1170 ESADI Protocol"). 1172 2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads 1173 is changed from the base IS-IS format to the Extended Level 1 1174 Circuit Scoped format (E-L1CS) specified in [FS-LSP]. This change 1175 is not backwards compatible with [RFC6325]. It is made in light of 1176 (a) the very limited, if any, deployment of [RFC6325] ESADI, and 1177 (b) the 256 times greater information carrying capacity of the E- 1178 L1CS format compared with the base IS-IS format. It is anticipated 1179 that this greater carrying capacity will be needed, under some 1180 circumstances, to carry end station addressing information or 1181 other information that is added to ESADI in the future. 1183 3. Unicasting of ESADI PDUs is optionally supported including 1184 replacing Section 4.6.2.2 of [RFC6325] with the new text give in 1185 Section 4.1 of this document. This unicast support is backwards 1186 compatible because it is only used when the recipient RBridge 1187 signals its support. 1189 4. Suggest unicasting of ESADI-LSPs with staggered timing when a new 1190 ESADI RBridge appears on the EASDI virtual link. 1192 5. Provide for staggered delay for non-originators of ESADI-LSP 1193 fragments in response to requests for such fragments by CSNP and 1194 PSNP messages. 1196 6. The handling of persistent reachability of the same MAC within the 1197 same Data Label from two or more RBridge is substantially modified 1198 including the explicit replacement of some text in Section 4.2.6 1199 of [RFC6325] (see Section 5.3 of this document). 1201 Appendix Z: Change History 1203 RFC Editor: Please delete this section before publication. 1205 Z.1 From -00 to -01 1207 1. Add Section 6.3 "Default Authentication". 1209 2. Add "Acknowledgements" Section. 1211 3. Change requirement from "MAY" to "SHOULD" for an ESADI RBridge 1212 that is not DRB to send an ESADI-CSNP if it does not receive an 1213 ESADI-CSNP in long enough. 1215 4. Default CSNP Time was listed as 30 in one place and 40 in another. 1216 Change to uniformly specify 30. 1218 5. Update references to RFC 6326 to reference the 6326bis draft. 1220 6. Relax allocation criteria for TRILL APPsub-TLV type code points 1221 from Standard Action to IETF Review. 1223 7. Numerous Editorial changes. 1225 Z.2 From -01 to -02 1227 1. Extend to cover FGL and well as VLAN and introduce the term "Data 1228 Label" to cover both. 1230 2. Expand number of LSP fragments to 2**16. 1232 3. Simplify neighbor detection to no longer require possession of 1233 ESADI-LSP zero. 1235 4. Add update to last sentence of Section 4.2.6 of [RFC6325]. 1237 5. Update references for publication of RFCs 6822 and 6823. 1239 6. Additional minor changes. 1241 Z.3 From -02 to -03 1243 1. Replace instances of "IS-IS and data unreachable" with just "data 1244 unreachable" as data unreachability implies IS-IS unreachability 1245 [ClearCorrect]. 1247 2. With ESADI, there is just one virtual link on which all 1248 participating TRILL switches are adjacent. Thus, all of the useful 1249 ESADI-LSPs in an ESADI link state database are originated by a 1250 station on this virtual link. To avoid overworking the ESADI DRB 1251 on the link, ESADI-LSPs sent by a reachable TRILL switch in 1252 response to an ESADI-PSNP should be sent by the TRILL switch 1253 originating those EASDI-LSPs. 1255 3. Re-organize material on sending and receiving ESADI PDUs into more 1256 smaller subsections that cover all the different circumstances. 1258 4. Substantially expand Security Considerations section. 1260 5. Numerous editorial changes. 1262 Z.4 From -03 to -04 1264 1. Change to using Extended Level 1 Circuit Scope [FS-LSP] for EASDI- 1265 LSP, ESADI-CSNP, and ESADI-PSNP PDUs. 1267 2. Update references to RFC 6327 to the rfc6327bis draft. 1269 3. Sort Informational References RFCs in numeric order. 1271 4. Add Appendix A: summary of changes to [RFC6325]. 1273 5. Minor editing changes. 1275 Z.5 From -04 to -05 1277 1. Expand Appendix A to be more complete and precise. 1279 2. Add L2-IS-IS Ethertype to Figure 1 so figure and text match. 1281 3. For clarification, add an example pseudo-random function to the 1282 new text in Section 5.3. 1284 4. Eliminate possible unicasting of PSNPs. 1286 5. Provide for staggered delay for non-originators of ESADI-LSP 1287 fragments in response to requests for such fragments by CSNP and 1288 PSNP messages. 1290 6. In Section 7.2, cover inclusion in FS-LSPs as permitted by [FS- 1291 LSP]. 1293 7. Some editing changes including expanding "MAC&label". 1295 Z.6 From -05 to -06 1297 1. In Section 4.3: "a an adjacent" -> "an adjacent". 1299 2. In Section 4.4: "( 100 - Random (Jitter) )" -> Random(Jitter)". 1301 3. Add one Acknowledgement. 1303 Z.7 From -06 to -07 1305 Update bsed on GENART and IANA reveiws: 1307 1. Update and extend the first paragraph of Section 1.1 and items 2 1308 and 3 in Appendix A with particular attention to how this 1309 document updates RFC 6325 and backwards compatibility. 1311 2. Minor edits to the first part of Section 2 to clarify "pseudo- 1312 nodes" and the use of common components inside an RBridge 1313 implementation of the independent ESADI instances. 1315 3. Add "[RFCfgl]" refernces inside Figures 2 and 3. 1317 4. Section 2.1, minor edits for clarity. 1319 5. Section 2.2, "is ignored" -> "MUST be ignored". 1321 6. Section 3, minor edit to clarify DRB election references. 1323 7. Explain source of "1470 bytes" in Section 6. 1325 8. Add new second paragarph to Section 8 to clarify cases where you 1326 might want authenticated end-station registration but would not 1327 need ESADI-PDU authentication. 1329 9. Substnatial editorial changtes to the IANA Considerations 1330 (Section 7), based on IANA review, to clarify the requested IANA 1331 actions. 1333 10. Update Acknowledgements. 1335 11. Other minor editorial changes. 1337 Authors' Addresses 1339 Hongjun Zhai 1340 ZTE Corporation 1341 68 Zijinghua Road 1342 Nanjing 200012 China 1344 Phone: +86-25-52877345 1345 Email: zhai.hongjun@zte.com.cn 1347 Fangwei Hu 1348 ZTE Corporation 1349 889 Bibo Road 1350 Shanghai 201203 China 1352 Phone: +86-21-68896273 1353 Email: hu.fangwei@zte.com.cn 1355 Radia Perlman 1356 Intel Labs 1357 2200 Mission College Blvd. 1358 Santa Clara, CA 95054-1549 USA 1360 Phone: +1-408-765-8080 1361 Email: Radia@alum.mit.edu 1363 Donald Eastlake 1364 Huawei Technologies 1365 155 Beaver Street 1366 Milford, MA 01757 USA 1368 Phone: +1-508-333-2270 1369 Email: d3e3e3@gmail.com 1371 Olen Stokes 1372 Extreme Networks 1373 Pamlico Building One, Suite 100 1374 3306 East NC Hwy 54 1375 RTP, NC 27709 USA 1377 Email: ostokes@extremenetworks.com 1379 Copyright and IPR Provisions 1381 Copyright (c) 2014 IETF Trust and the persons identified as the 1382 document authors. All rights reserved. 1384 This document is subject to BCP 78 and the IETF Trust's Legal 1385 Provisions Relating to IETF Documents 1386 (http://trustee.ietf.org/license-info) in effect on the date of 1387 publication of this document. Please review these documents 1388 carefully, as they describe your rights and restrictions with respect 1389 to this document. Code Components extracted from this document must 1390 include Simplified BSD License text as described in Section 4.e of 1391 the Trust Legal Provisions and are provided without warranty as 1392 described in the Simplified BSD License.