idnits 2.17.1 draft-ietf-trill-esadi-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (June 7, 2014) is 3582 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 normative reference: RFC 7180 (Obsoleted by RFC 7780) -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) Summary: 2 errors (**), 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: Decemeber 6, 2014 June 7, 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 address and 28 reachability information to TRILL switches participating in ESADI for 29 the relevant Data Label. This document updates RFC 6325, 30 specifically the documentation of the ESADI protocol, and is not 31 backwards 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 8.1 Privacy Considerations................................28 92 9. Acknowledgements.......................................30 94 Normative references......................................31 95 Informative References....................................32 97 Appendix A: Interoperability and Changes to [RFC6325].....34 98 A.1 ESADI PDU Changes.....................................34 99 A.2 Unicasting Changes....................................35 100 A.3 Message Timing Changes and Suggestions................35 101 A.4 Duplicate Address Reachability........................35 103 Appendix Z: Change History................................36 105 Authors' Addresses........................................40 107 1. Introduction 109 The IETF TRILL (Transparent Interconnection of Lots of Links) 110 protocol [RFC6325] provides least cost pair-wise data forwarding 111 without configuration in multi-hop networks with arbitrary topologies 112 and link technologies, safe forwarding even during periods of 113 temporary loops, and support for multi-pathing of both unicast and 114 multicast traffic. TRILL accomplishes this with the IS-IS 115 (Intermediate System to Intermediate System) [IS-IS] [RFC1195] 116 [RFC7176] link-state routing protocol using a header with a hop 117 count. The design supports optimization of the distribution of 118 multi-destination frames and two types of data labeling: VLANs 119 (Virtual Local Area Networks [RFC6325]) and FGLs (Fine Grained 120 Labels, [RFC7172]). Devices that implement TRILL are called TRILL 121 switches or RBridges (Routing Bridges). 123 There are five ways a TRILL switch can learn end station addresses, 124 as described in Section 4.8 of [RFC6325]. One of these is the ESADI 125 (End Station Address Distribution Information) protocol, which is an 126 optional Data Label scoped way TRILL switches can communicate, with 127 each other, information such as end station addresses and their TRILL 128 switch of attachment. A TRILL switch that is announcing interest in a 129 Data Label MAY use the ESADI protocol to announce the end station 130 address of some or all of its attached end stations in that Data 131 Label to other TRILL switches that are running ESADI for that Data 132 Label. (In the future, ESADI may also be used for other address and 133 reachability information.) 135 By default, TRILL switches with connected end stations learn 136 addresses from the data plane when ingressing and egressing native 137 frames although such learning can be disabled. The ESADI protocol's 138 potential advantages over data plane learning include the following: 140 1. Security advantages: (1a) The ESADI protocol can be used to 141 announce end stations with an authenticated enrollment (for 142 example enrollment authenticated by cryptographically based EAP 143 (Extensible Authentication Protocol [RFC3748]) methods via 144 [802.1X]). (1b) The ESADI protocol supports cryptographic 145 authentication of its message payloads for more secure 146 transmission. 148 2. Fast update advantages: The ESADI protocol provides a fast update 149 of end station MAC (Media Access Control) addresses and their 150 TRILL switch of attachment. If an end station is unplugged from 151 one TRILL switch and plugged into another, ingressed frames with 152 that end station's MAC address as their destination can be black 153 holed. That is, they can be sent just to the older egress TRILL 154 switch that the end station was connected to until cached address 155 information at some remote ingress TRILL switch times out, 156 possibly for tens of seconds [RFC6325]. 158 MAC address reachability information, some ESADI parameters, and 159 optional authentication information are carried in ESADI packets 160 rather than in the TRILL IS-IS protocol. As specified below, ESADI 161 is, for each Data Label, a virtual logical topology overlay in the 162 TRILL topology. An advantage of using ESADI over using TRILL IS-IS is 163 that the end station attachment information is not flooded to all 164 TRILL switches but only to TRILL switches advertising ESADI 165 participation for the Data Label in which those end stations occur. 167 1.1 Content and Precedence 169 This document updates [RFC6325], the TRILL base protocol 170 specification, obsoleting and replacing the description of the TRILL 171 ESADI protocol (Section 4.2.5 of [RFC6325] including all 172 subsections), providing more detail on ESADI, updating other ESADI 173 related sections of [RFC6325], and prevailing over [RFC6325] in any 174 case where they conflict. For this reason, familiarity with [RFC6325] 175 is particularly assumed. These changes include a change to the 176 format of ESADI-LSPs that is not backwards compatible; this change is 177 justified by the substantially increased amount of information that 178 can be carried and in light of the very limited, if any, deployment 179 of RFC 6325 ESADI. These changes are further discussed in Appendix 180 A. 182 Section 2 of this document is the ESADI protocol overview. Section 3 183 specifies ESADI DRB (Designated RBridge) determination. Section 4 184 discusses the processing of ESADI PDUs (Protocol Data Units). Section 185 5 discusses interaction with other modes of end station address 186 learning. And Section 6 describes the ESADI-LSP (Link State PDU) and 187 its contents. 189 1.2 Terminology 191 This document uses the acronyms defined in [RFC6325] and the 192 following: 194 Data Label - VLAN or FGL. 196 ESADI RBridge - An RBridge that is participating in ESADI for one 197 or more Data Labels. 199 FGL - Fine Grained Label [RFC7172]. 201 LSP - Link State PDU [IS-IS]. 203 LSP number zero - A Link State PDU with fragment number equal to 204 zero. 206 PDU - Protocol Data Unit. 208 TRILL switch - an alternative name for an RBridge. 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 Capitalized IANA Considerations terms such as "IETF Review" as to be 215 interpreted as described in [RFC5226]. 217 2. ESADI Protocol Overview 219 ESADI is a Data Label scoped way for TRILL switches (also known as 220 RBridges) to announce and learn end station addresses rapidly and 221 securely. An RBridge that is announcing participation in ESADI for 222 one or more Data Labels is called an ESADI RBridge. 224 ESADI is a separate optional protocol from the mandatory TRILL IS-IS 225 implemented by all RBridges in a campus. There is a separate ESADI 226 instance for each Data Label (VLAN or FGL) if ESADI is being used for 227 that Data Label. In essence, for each such Data Label, there is a 228 modified instance of the IS-IS reliable flooding mechanism in which 229 ESADI RBridges may choose to participate. (These are not the 230 instances specified in [RFC6822].) Multiple ESADI instances may share 231 implementation components within an RBridge as long as that sharing 232 preserves the independent operation of each instance of the ESADI 233 protocol. For example, the ESADI link state database could be in a 234 single database with a field in each record indicating the Data Label 235 to which it applies or could be a separate database per Data Label. 236 But the ESADI update process operates separately for each ESADI 237 instance and independently from the TRILL IS-IS update process. 239 ESADI does no routing calculations so there is no reason for pseudo- 240 nodes in ESADI and none are created (Pseudo-nodes [IS-IS] are a 241 construct for optimizing routing calculations.) Furthermore, there 242 may be a requirement for a relatively large amount of data to be 243 distributed through ESADI which might take a large number of ESADI- 244 LSP fragments. ESADI-LSP, ESADI-CSNP, and ESADI-PSNP (ESADI Link 245 State PDU, Complete Sequence Number PDU, and Partial Sequence Number 246 PDU) payloads are therefore formatted as Extended Level 1 Circuit 247 Scope (E-L1CS) PDUs [FS-LSP] (see also Section 6). This allows up to 248 2**16 fragments but does not support link state data associated with 249 pseudo-nodes. 251 After the TRILL header, ESADI packets have an inner Ethernet header 252 with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All- 253 ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL of 254 interest, and the "L2-IS-IS" Ethertype followed by the ESADI payload 255 as shown in Figure 1. 257 +--------------------------------+ 258 | Link Header | 259 +--------------------------------+ 260 | TRILL Data Header | 261 +--------------------------------+ 262 | Inner Ethernet Addresses | 263 +--------------------------------+ 264 | Data Label | 265 +--------------------------------+ 266 | L2-IS-IS Ethertype | 267 +--------------------------------+ 268 | ESADI Payload | 269 +--------------------------------+ 270 | Link Trailer | 271 +--------------------------------+ 273 Figure 1. TRILL ESADI Packet Overview 275 TRILL ESADI packets sent on an Ethernet link are structured as shown 276 below. The outer VLAN tag will not be present if it was not included 277 by the Ethernet port that sent the packet. 279 Outer Ethernet Header: 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Next Hop Destination Address | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Next Hop Destination Addr. | Sending RBridge Port MAC Addr.| 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Sending RBridge Port MAC Address | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ...Ethernet frame tagging including optional Outer.VLAN tag... 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Ethertype = TRILL 0x22F3 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | V | R |M|Op-Length| Hop Count | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Egress Nickname | Ingress (Origin) Nickname | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Inner Ethernet Header: 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | All-Egress-RBridges | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | All-Egress-RBridges cont. | Origin RBridge MAC Address | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Origin RBridge MAC Address continued | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ... 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Ethertype = L2-IS-IS 0x22F4 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 ESADI Payload (formatted as IS-IS): 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Frame Check Sequence: 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | FCS (Frame Check Sequence) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2: ESADI Ethernet Link Packet Format 319 The Next Hop Destination Address or Outer.MacDA is the All-RBridges 320 multicast address if the ESADI PDU is being multicast. If it is being 321 unicast, the Next Hop Destination Address is the unicast address of 322 the next hop RBridge. The VLAN for the Outer.VLAN information, if 323 present, will be the Designated VLAN for the link on which the packet 324 is sent. The V and R fields will be zero while the M field will be 325 one unless the ESADI PDU was unicast, in which case the M field will 326 be zero. The Data Label specified will be the VLAN or FGL to which 327 the ESADI packet applies. The Origin RBridge MAC Address or 328 Inner.MacSA MUST be a MAC address unique across the campus owned by 329 the RBridge originating the ESADI packet, for example, any of its 330 port MAC addresses if it has any Ethernet ports, and each RBridge 331 MUST use the same Inner.MacSA for all of the ESADI packets that 332 RBridge originates. 334 TRILL ESADI packets sent on a PPP link are structured as shown below 335 [RFC6361]. 337 PPP Header: 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | PPP = TNP (TRILL data) 0x005D | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | V | R |M|Op-Length| Hop Count | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Egress Nickname | Ingress (Origin) Nickname | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Inner Ethernet Header: 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | All-Egress-RBridges | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | All-Egress-RBridges cont. | Origin RBridge MAC Address | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Origin RBridge MAC Address continued | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ... 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Ethertype = L2-IS-IS 0x22F4 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 ESADI Payload (formatted as IS-IS): 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 PPP Check Sequence: 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | PPP Check Sequence | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 3: ESADI PPP Link Packet Format 369 2.1 ESADI Virtual Link 371 All RBridges forward ESADI packets as if they were ordinary TRILL 372 Data packets. Because of this forwarding, it appears to an instance 373 of the ESADI protocol at an RBridge that it is directly connected by 374 a multi-access virtual link to all RBridges in the campus that are 375 data reachable from it (see Section 2 of [RFC7180]) and are running 376 ESADI for that Data Label. No "routing" calculation (least cost path 377 or distribution tree construction) ever has to be performed by ESADI. 378 An ESADI RBridge merely transmits the ESADI packets it originates on 379 this virtual link as described for TRILL Data packets in [RFC6325] 380 and [RFC7172]. For multicast ESADI packets it may use any 381 distribution tree that it might use for an ordinary multi-destination 382 TRILL Data packet. RBridges that do not implement the ESADI protocol, 383 do not have it enabled, or are not participating for the Data Label 384 of an ESADI packet do not decapsulate or locally process the TRILL 385 ESADI packet. Thus, ESADI packets are transparently tunneled through 386 transit RBridges. 388 2.2 ESADI Neighbor Determination 390 The ESADI instance for Data Label X at an RBridge RB1 determines who 391 its adjacent ESADI neighbors are by examining the TRILL IS-IS link 392 state database for RBridges that are data reachable from RB1 (see 393 Section 2 of [RFC7180]) and are announcing their participation in 394 Data Label X ESADI. When an RBridge RB2 becomes data unreachable from 395 RB1 or the relevant entries for RB2 are purged from the core IS-IS 396 link state database, it is lost as a neighbor and also dropped from 397 any ESADI instances from the point of view of RB1, and when RB2 is no 398 longer announcing participation in Data Label X ESADI, it ceases to 399 be a neighbor for any Data Label X ESADI instance. All these 400 considerations are Data Label scoped. Because of these mechanisms 401 whereby an ESADI instance at an ESADI RBridge can determine its ESADI 402 adjacencies by examining the TRILL IS-IS link state database, there 403 are no "Hellos" sent in ESADI and no adjacency information is carried 404 in ESADI-LSPs. 406 Participation announcement in a VLAN scoped ESADI instance is through 407 setting a flag bit in the Interested VLANs sub-TLV and announcement 408 for an FGL scoped ESADI instance is through setting a flag bit in the 409 Interested Labels sub-TLV [RFC7176]. (See Section 7.1) 411 2.3 ESADI Payloads 413 TRILL ESADI packet payloads are structured like IS-IS Extended Level 414 1 Circuit Scoped (E-L1CS) LSP, CSNP, and PSNP PDUs [FS-LSP], except 415 as indicated below, but are always TRILL encapsulated on the wire as 416 if they were TRILL Data packets. The information distributed by the 417 ESADI protocol includes a list of local end station MAC addresses 418 connected to the originating RBridge and, for each such address, a 419 one octet unsigned "confidence" rating in the range 0-254 (see 420 Section 6.2). It is entirely up to the originating RBridge which 421 locally connected MAC addresses it wishes to advertise via ESADI and 422 with what confidence. It MAY advertise all, some, or none of such 423 addresses. In addition, some ESADI parameters of the advertising 424 RBridge (see Section 6.1) and optionally authentication information 425 (see Section 6.3) are included. Future uses of ESADI may distribute 426 other similar address and reachability information. 428 TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload. 429 The Data Label to which the ESADI data applies is the Data Label of 430 the TRILL Data packet enclosing the ESADI payload. If a Data Label ID 431 could occur within the payload, it might conflict with that TRILL 432 Data packet Data Label and could conflict with any future Data Label 433 mapping scheme that may be adopted [VLANmapping]. If a VLAN or FGL ID 434 field within an ESADI-LSP PDU does include a value, that field's 435 contents MUST be ignored. 437 3. ESADI DRB (Designated RBridge) Determination 439 Because ESADI does no adjacency announcement or routing, the ESADI- 440 DRB never creates a pseudonode. But a DRB (Designated RBridge 441 [RFC7177]) is still needed for ESADI-LSP synchronization by issuing 442 ESADI-CSNP PDUs and responding to ESADI-PSNP PDUs. 444 Generally speaking, the DRB election on the ESADI virtual link (see 445 Section 2.1) operates similarly to the DRB election on a TRILL IS-IS 446 broadcast link, as described in Section 4.2.1 ("DRB Election 447 Details") of [RFC7177], with the following exceptions: In the Data 448 Label X ESADI-DRB election at RB1 on an ESADI virtual link, the 449 candidates are the local ESADI instance for Data Label X and all 450 remote ESADI instances at RBridges that (1) are data reachable from 451 RB1 [RFC7180], and (2) are announcing in their TRILL IS-IS LSP that 452 they are participating in ESADI for Data Label X. The winner is the 453 instance with the highest ESADI Parameter 7-bit priority field with 454 ties broken by System ID, comparing fields as unsigned integers with 455 the larger magnitude considered higher priority. "SNPA/MAC address" 456 is not considered in this tie breaking and there is no "Port ID". 458 4. ESADI PDU processing 460 Data Label X ESADI neighbors are usually not connected directly by a 461 physical link, but are always logically connected by a virtual link 462 (see Section 2.1). There could be hundreds or thousands of ESADI 463 RBridges (TRILL switches) on the virtual link. There are only ESADI- 464 LSP, ESADI-CSNP and ESADI-PSNP PDUs used in ESADI. In particular, 465 there are no Hello or MTU PDUs because ESADI does not build a 466 topology, does not do any routing calculations, and does not 467 determine MTU, using the campus Sz. (Sz is the TRILL campus wide 468 minimum link MTU (see [RFC6325] and [RFC7180]).) 470 4.1 Unicasting ESADI PDUs 472 For [IS-IS], PDU multicasting is normal on a local link and no effort 473 is made to optimize to unicast because on the typical physical link 474 for which IS-IS was designed (commonly a piece of multi-access 475 Ethernet cable) any frame made the link busy for that frame time. But 476 to ESADI instances, what appears to be a simple multi-access link is 477 generally a set of multi-hop distribution trees that may or may not 478 be pruned. Thus, transmitting a multicast frame on such a tree can 479 impose a substantially greater load than transmitting a unicast 480 frame. This load may be justified if there are likely to be multiple 481 listeners but may not be justified if there is only one recipient of 482 interest. For this reason, under some circumstances, ESADI PDUs MAY 483 be TRILL unicast if it is confirmed that the destination RBridge 484 supports receiving unicast ESADI PDUs (see Section 6.1). 486 The format of a unicast ESADI packet is the format of a multicast 487 TRILL ESADI packet, in Section 2 above, except as follows: 489 o On an Ethernet link, in the Outer Ethernet Header the Outer.MacDA 490 is the unicast address of the next hop RBridge. 492 o In the TRILL header, the M bit is set to zero and the Egress 493 Nickname is the nickname of the destination RBridge. 495 To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is 496 replaced with the following: 498 "4.6.2.2. TRILL ESADI Packets 500 If M=1, the egress nickname designates the distribution tree. The 501 packet is forwarded as described in Section 4.6.2.5. In addition, 502 if the forwarding RBridge is (1) interested in the specified VLAN 503 or Fine Grained Label [RFC7172], (2) implements the TRILL ESADI 504 protocol, and (3) ESADI is enabled for that VLAN or Fine Grained 505 Label, the inner frame is decapsulated and provided to that local 506 ESADI protocol. 508 If M=0 and the egress nickname is not that of the receiving 509 RBridge, the packet is forwarded as for known unicast TRILL Data 510 in Section 4.6.2.4. If M=0 and the egress nickname is that of the 511 receiving RBridge and the receiving RBridge supports unicast ESADI 512 PDUs, then the ESADI packet is decapsulated and processed if it 513 meets the three numbered conditions in the paragraph above, 514 otherwise it is discarded." 516 The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to 517 those sections in [RFC6325]. 519 4.2 General Transmission of ESADI PDUs 521 Following the usual [IS-IS] rules, an ESADI instance does not 522 transmit any ESADI PDUs if it has no ESADI adjacencies. Such 523 transmission would just be a waste of bandwidth. 525 The MTU available to ESADI payloads is at least 24 bytes less than 526 that available to TRILL IS-IS because of the additional fields 527 required ( 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 528 6(Inner.MacSA) + 4/8(Data Label) bytes). Thus the inner ESADI 529 payload, starting with the Intradomain Routeing Protocol 530 Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI 531 instance or Sz minus 28 for an FGL ESADI instance; however, if a 532 larger payload is received, it is processed normally. (See [RFC6325] 533 and [RFC7180] for discussions of Sz and MTU.) 535 In all cases where this document says that an ESADI PDU is multicast, 536 if the transmitting RBridge has only one neighbor and that neighbor 537 advertises support for unicast, the PDU MAY be unicast (see Section 538 4.1). 540 A priority bit to indicate that an LSP fragment should be flooded 541 with high priority is provided by [FS-LSP]. This bit SHOULD be set on 542 ESADI-LSP fragment zero because it is important that the ESADI 543 Parameters APPsub-TLV get through promptly. This bit SHOULD NOT be 544 set on other ESADI-LSP fragments to avoid giving undue priority to 545 less urgent PDUs. 547 4.3 General Receipt of ESADI PDUs 549 In contrast with layer 3 IS-IS PDU acceptance tests, which check the 550 source inner and outer SNPA/MAC in order to verify that a PDU is from 551 an adjacent TRILL switch, in TRILL ESADI, adjacency is based on 552 system ID, so the system ID inside the PDU is all that is tested for. 554 If an ESADI instance believes that it has no ESADI neighbors, it 555 ignores any ESADI PDUs it receives. 557 4.4 ESADI Reliable Flooding 559 The IS-IS reliable flooding mechanism (the Update Process) is 560 modified for ESADI in the ways listed below. Except as otherwise 561 stated, the ESADI update process works as described in [IS-IS], 562 [RFC1195], and [FS-LSP]. 564 When an ESADI instance sees that it has a new ESADI neighbor, its 565 self-originated ESADI-LSP fragments are scheduled to be sent and MAY 566 be unicast to that neighbor if the neighbor is announcing in its LSP 567 that it supports unicast ESADI (see Section 6.1). If all the other 568 ESADI instances for the same Data Label send their self-originated 569 ESADI-LSPs immediately, there may be a surge of traffic to that new 570 neighbor. So the ESADI instances SHOULD wait an interval of time 571 before sending their ESADI-LSP(s) to a new neighbor. The interval 572 time value is up to the device implementation. One suggestion is that 573 the interval time can be assigned a random value with a range based 574 on the RBridge's nickname (or any one of its nicknames if it holds 575 more than one) such as ( 2000 * nickname / 2**16 ) milliseconds 576 assuming "nickname" to be an unsigned quantity. 578 All the TRILL switches participating in an ESADI instance for some 579 Data Label appear to ESADI to be adjacent. Thus the originator of any 580 active ESADI-LSP fragment always appears to be on link and, to spread 581 the burden of such response, could be the RBridge to respond to any 582 ESADI-CSNP or PSNP request for that fragment. However, under very 583 rare circumstances, it could be that some version of the LSP fragment 584 with a higher sequence number is actually held by another ESADI 585 RBridge on the link, so non-originators need to be able to respond 586 eventually. Thus, when the receipt of a CSNP or PSNP causes the 587 SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP 588 fragment, action is as specified in [IS-IS] for the originating ESADI 589 RBridge of the fragment; however, at a non-originating ESADI RBridge, 590 when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS] 591 is also set to the current time minus 593 minimumLSPTimeInterval * Random (Jitter) / 100 595 (where minimumLSPTimeInterval, Random, and Jitter are as in [IS-IS]). 596 This will delay and jitter the transmission of the LSP fragment by 597 non-originators. This gives the originator more time to send the 598 fragment and provides more time for such an originator transmitted 599 copy to traverse the likely multi-hop path to non-originators and 600 clear the SRMflag for the fragment at non-originators. 602 The multi-hop distribution tree method with Reverse Path Forwarding 603 Check used for multicast distribution by TRILL will typically be less 604 reliable than transmission over a single local broadcast link hop. 605 For LSP synchronization robustness, in addition to sending ESADI- 606 CSNPs as usual when it is DRB, an ESADI RBridge SHOULD also transmit 607 an ESADI-CSNP for an ESADI instance if all of the following 608 conditions are met: 610 o it sees one or more ESADI neighbors for that instance, and 611 o it does not believe it is DRB for the ESADI instance, and 612 o it has not received or sent an ESADI-CSNP PDU for the instance for 613 the average of the CSNP Time (see Section 6.1) of the DRB and its 614 CSNP Time. 616 5. End Station Addresses 618 The subsections below discuss end station address considerations in 619 the context of ESADI. 621 5.1 Learning Confidence Level 623 The confidence level mechanism [RFC6325] allows an RBridge campus 624 manager to cause certain address learning sources to prevail over 625 others. MAC address information learned through a registration 626 protocol, such as [802.1X] with a cryptographically based EAP 627 [RFC3748] method, might be considered more reliable than information 628 learned through the mere observation of data traffic. When such 629 authenticated learned address information is transmitted via the 630 ESADI protocol, the use of authentication in the TRILL ESADI-LSP 631 packets could make tampering with it in transit very difficult. As a 632 result, it might be reasonable to announce such authenticated 633 information via the ESADI protocol with a high confidence, so it 634 would be used in preference to any alternative learning from data 635 observation. 637 5.2 Forgetting End Station Addresses 639 The end station addresses learned through the TRILL ESADI protocol 640 should be forgotten through changes in ESADI-LSPs. The time out of 641 the learned end station address is up to the originating RBridge that 642 decides when to remove such information from its ESADI-LSPs (or up to 643 ESADI protocol timeouts if the originating RBridge becomes 644 unreachable). 646 If RBridge RBn participating in the TRILL ESADI protocol for Data 647 Label X no longer wishes to participate in ESADI, it ceases to 648 participate by (1) clearing the ESADI participation bit in the 649 appropriate Interested VLANs or Interested Labels sub-TLV and (2) 650 sending a final ESADI-LSP nulling out its ESADI-LSP information. 652 5.3 Duplicate MAC Address 654 With ESADI, it is possible to persistently see occurrences of the 655 same MAC address in the same Data Label being advertised as reachable 656 by two or more RBridges. The specification of how to handle this 657 situation in [RFC6325] is updated by replacing the last sentence of 658 the last paragraph of Section 4.2.6 of [RFC6325] as shown below to 659 provide better traffic spreading while avoiding possible address 660 flip-flopping. 662 As background, assume some end station or set of end stations ESn 663 have two or more ports with the same MAC address in the same Data 664 Label with the ports connected to different RBridges (RB1, RB2, ...) 665 by separate links. With ESADI, some other RBridge, RB0, can 666 persistently see that MAC address in that Data Label connected to 667 multiple RBridges. When RB0 ingresses a frame, say from ES0, destined 668 for that MAC and label, the current [RFC6325] text permits a wide 669 range of behavior. In particular, [RFC6325] would permit RB0 to use 670 some rule such as always encapsulate to the egress with the lowest 671 System ID, which would put all of this traffic through only one of 672 the egress RBridges and one of the end station ports. With that 673 behavior, there would be no load spreading, even if there were 674 multiple different ingress RBridges and/or different MAC addresses 675 with the same reachability. [RFC6325] also would also permit RB0 to 676 send different traffic to different egresses by doing ECMP at a flow 677 level, which would likely result in return traffic for RB0 to egress 678 to ES0 from various of RB1, RB2, ... for the same MAC and label. The 679 resulting address reachability flip-flopping perceived at RB0 could 680 cause problems. 682 This update to [RFC6325] avoids these potential difficulties by 683 requiring RB0 to use one of the following two policies: (1) only 684 encapsulate to one egress RBridge for any particular MAC and label 685 but to select that egress pseudo-randomly based on the topology 686 including MAC reachability or (2) if it will not be disturbed by the 687 returning TRILL Data packets showing the same MAC and label flip- 688 flopping between different ingresses, it may use ECMP. Assuming 689 multiple ingress RBridges and/or multiple MAC and label addresses, 690 strategy 1 should result in load spreading without address flip- 691 flopping while strategy 2 will produce better load spreading than 692 strategy 1 but with address flip-flopping from the point of view of 693 RB0. 695 OLD [RFC6325] Section 4.2.6 text: 696 "... If confidences are also tied between the duplicates, for 697 consistency it is suggested that RB2 direct all such frames (or 698 all such frames in the same ECMP flow) toward the same egress 699 RBridge; however, the use of other policies will not cause a 700 network problem since transit RBridges do not examine the 701 Inner.MacDA for known unicast frames." 703 NEW [RFC6325] Section 4.2.6 text: 704 "... 706 If confidences are also tied between the duplicates then RB2 MUST 707 adopt one of the following two strategies: 709 1. In a pseudo-random way [RFC4086], select one of the egress 710 RBridges that is least cost from RB2 and to which the 711 destination MAC appears to be attached and send all traffic for 712 the destination MAC and VLAN (or FGL [RFC7172]) to that egress. 713 This pseudo-random choice need only be changed when there is a 714 change in campus topology or MAC attachment information. Such 715 pseudo-random selection will, over a population of ingress 716 RBridges, probabilistically spread traffic over the possible 717 egress RBridges. Reasonable inputs to the pseudo-random 718 selection are the ingress RBridge System ID and/or nickname, 719 the VLAN or FGL, the destination MAC address, and a vector of 720 the RBridges with connectivity to that MAC and VLAN or FGL. 721 There is no need for different RBridges to use the same pseudo- 722 random function. 724 As an example of such a pseudo-random function, if there are k 725 egress RBridges (RB0, RB1, ..., RB(k-1)) all reporting 726 attachment to address MACx in Data Label DLy, then an ingress 727 RBridge RBin could select the one to which it will send all 728 unicast TRILL Data packets addressed to MACx in DLy based on 729 the following: 731 FNV-32(RBin | MACx | DLy | RB0 | RB1 | ... | RB(k-1)) mod k 733 where FNV is specified in [FNV], RBx means the nickname for 734 RBridge RBx, "|" means concatenation, MACx is the 735 destination MAC address, DLy is the Data Label, and "mod k" 736 means the integer division remainder of the output of the 737 FNV-32 function considered as a positive integer divided by 738 k. 740 2. If RB2 supports ECMP and will not be disturbed by return 741 traffic from the same MAC and VLAN (or FGL [RFC7172]) coming 742 from a variety of different RBridges, then it MAY send traffic 743 using ECMP at the flow level to the egress RBridges that are 744 least cost from RB2 and to which the destination MAC appears to 745 be attached." 747 6. ESADI-LSP Contents 749 The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI- 750 PSNP PDUs. Currently, the contents of an ESADI-LSP consists of zero 751 or more MAC Reachability TLVs, optionally an Authentication TLV, and 752 exactly one ESADI parameter APPsub-TLV. Other similar data may be 753 included in the future and, as in [IS-IS], an ESADI instance ignores 754 any TLVs or sub-TLVs it does not understand. Because these PDUs are 755 formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs [FS-LSP], 756 the Type and Length fields in the TLVs are 16-bit. 758 This section specifies the format for the ESADI parameter data 759 APPsub-TLV, gives the reference for the ESADI MAC Reachability TLV, 760 and discusses default authentication configuration. 762 For robustness, the payload for an ESADI-LSP number zero and any 763 ESADI-CSNP or ESADI-PSNP covering fragment zero MUST NOT exceed 1470 764 minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN or 1470 765 minus 28 bytes (1442 bytes) if it has an Inner.FGL. But if an ESADI- 766 LSP number zero or such an ESADI-CSNP or ESADI-PSNP is received that 767 is longer, it is still processed normally. (As stated in Section 768 4.3.1 of [RFC6325], 1470 bytes was chosen to make it extremely 769 unlikely that a TRILL control packet, even with reasonable additional 770 headers, tags, and/or encapsulation, would encounter MTU problems on 771 an inter-RBridge link.) 773 6.1 ESADI Parameter Data 775 The figure below presents the format of the ESADI parameter data. 776 This APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP 777 number zero. If it is missing from ESADI-LSP number zero or if ESADI- 778 LSP number zero is not known, priority for the sending RBridge 779 defaults to 0x40 and CSNP Time defaults to 30. If there is more than 780 one occurrence in ESADI-LSP number zero, the first occurrence will be 781 used. Occurrences of the ESADI parameter data APPsub-TLV in non-zero 782 ESADI-LSP fragments are ignored. 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Type | (2 bytes) 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Length | (2 bytes) 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 |R| Priority | (1 byte) 790 +-+-+-+-+-+-+-+-+ 791 | CSNP Time | (1 byte) 792 +-+-+-+-+-+-+-+-+ 793 | Flags | (1 byte) 794 +---------------+ 795 | Reserved for expansion (variable) 796 +-+-+-+-... 798 Figure 4. ESADI Parameter APPsub-TLV 800 Type: set to ESADI-PARAM subTLV (TRILL APPsub-TLV type 0x0001). Two 801 bytes because this APPsub-TLV appears in an Extended TLV [FS-LSP]. 803 Length: Variable with a minimum of 3 but must fit within the ESADI 804 packet. This field is encoded as an unsigned integer in network 805 byte order [FS-LSP]. 807 R: A reserved bit that MUST be sent as zero and ignored on receipt. 809 Priority: The Priority field gives the originating RBridge's priority 810 for being DRB on the ESADI instance virtual link (see Section 3) 811 for the Data Label in which the PDU containing the parameter data 812 was sent. It is an unsigned seven-bit integer with larger 813 magnitude indication higher priority. It defaults to 0x40 for an 814 RBridge participating in ESADI for which it has not been 815 configured. 817 CSNP Time: An unsigned byte that gives the amount of time in seconds 818 during which the originating RBridge, if it is DRB on the ESADI 819 virtual link, will send at least three EASDI-CSNP PDUs. It 820 defaults to 30 seconds for an RBridge participating in ESADI for 821 which it has not been configured. 823 Flags: A byte of flags associated with the originating ESADI instance 824 as follows: 826 0 1 2 3 4 5 6 7 827 +---+---+---+---+---+---+---+---+ 828 | UN| RESV | 829 +---+---+---+---+---+---+---+---+ 831 The UN flag indicates that the RBridge originating the ESADI- 832 LSP, including this ESADI Parameter Data, will accept and 833 properly process ESADI PDUs sent by TRILL unicast (see Section 834 4.1). The remaining RESV bits are reserved for future use and 835 MUST be sent as zero and ignored on receipt. 837 Reserved for future expansion: Future versions of the ESADI 838 Parameters APPsub-TLV may have additional information. A receiving 839 ESADI RBridge ignores any additional data here unless it 840 implements such future expansion(s). 842 6.2 MAC Reachability TLV 844 The primary information in TRILL ESADI-LSP PDUs consists of MAC 845 Reachability (MAC-RI) TLVs specified in [RFC6165]. These TLVs 846 contain one or more unicast MAC addresses of end stations that are 847 both on a port and in a VLAN for which the originating RBridge is 848 appointed forwarder, along with the one octet unsigned Confidence in 849 this information with a value in the range 0-254. If such a TLV is 850 received containing a confidence of 255, it is treated as if the 851 confidence was 254. (This is to assure that any received address 852 information can be overridden by local address information statically 853 configured with a Confidence of 255.) 855 The TLVs in TRILL ESADI PDUs, including the MAC-RI TLV, MUST NOT 856 contain the Data Label ID. If a Data Label ID is present in the MAC- 857 RI TLV, it is ignored. In the ESADI PDU, only the Inner.VLAN or 858 Inner.FGL tag indicates the Data Label to which the ESADI-LSP 859 applies. 861 6.3 Default Authentication 863 The Authentication TLV may be included in ESADI PDUs [RFC5310] [IS- 864 IS]. The default for ESADI PDU Authentication is based on the state 865 of TRILL IS-IS shared secret authentication for TRILL IS-IS LSP PDUs. 866 If TRILL IS-IS authentication and ESADI are implemented at a TRILL 867 switch, then ESADI MUST be able to use the authentication algorithms 868 implemented for TRILL IS-IS and implement the keying material 869 derivation function given below. If ESADI authentication has been 870 manually configured, that configuration is not restricted by the 871 configuration of TRILL IS-IS security. 873 If TRILL IS-IS authentication is not in effect for LSP PDUs 874 originated by a TRILL switch then, by default, ESADI PDUs originated 875 by that TRILL switch are also unsecured. 877 If such IS-IS LSP PDU authentication is in effect at a TRILL switch 878 then, unless configured otherwise, ESADI PDUs sent by that switch 879 MUST use the same algorithm in their Authentication TLVs. The ESADI 880 authentication keying material used is derived from the IS-IS LSP 881 shared secret keying material as detailed below. However, such 882 authentication MAY be configured to use some other keying material. 884 HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key ) 886 In the above HMAC-SHA256 is as described in [FIPS180] [RFC6234] and 887 "TRILL ESADI" is the eleven byte US ASCII [ASCII] string indicated. 888 IS-IS-LSP-shared-key is secret keying material being used by the 889 originating TRILL switch for IS-IS LSP authentication. 891 7. IANA Considerations 893 IANA allocation and registry considerations are given below. Three 894 new sub-registries are created in the TRILL Parameters registry 895 located at http://www.iana.org/assignments/trill-parameters, two in 896 Section 7.1 and one in Section 7.2, and various code points assigned. 898 7.1 ESADI Participation and Capability Flags 900 IANA Action 1: 902 IANA is requested to create the following new sub-registry called 903 "Interested VLANs Flag Bits" in the TRILL Parameters registry. 905 Sub-Registry: Interested VLANs Flag Bits 907 Registration Procedures: IETF Review 909 Note: These bits appear in the Interested VLANs record within the 910 Interested VLANs and Spanning Tree Roots Sub-TLV (INT-VLAN) 911 specified in [RFC7176]. 913 References: [RFC7176], [This document] 915 Bit Mnemonic Description Reference 916 --- -------- ----------- --------- 917 0 M4 IPv4 Multicast Router Attached [RFC7176] 918 1 M6 IPv6 Multicast Router Attached [RFC7176] 919 2 - Unassigned 920 3 ES ESADI Participation This document 921 4-15 - (used for a VLAN ID) [RFC7176] 922 16-19 - Unassigned 923 20-31 - (used for a VLAN ID) [RFC7176] 925 The creation of this sub-registry as immediately above assigns bit 3 926 as the ESADI Participation bit in the Interested VLANs and Spanning 927 Tree Roots Sub-TLV. If The ESADI Participation bit is a one, it 928 indicates that the originating RBridge is participating in ESADI for 929 the indicated Data Label(s). 931 IANA Action 2: 933 IANA is requested to create the following new sub-registry called 934 "Interested Labels Flag Bits" in the TRILL Parameters registry. 936 Sub-Registry: Interested Labels Flag Bits 938 Registration Procedures: IETF Review 940 Note: These bits appear in the Interested Labels record within the 941 Interested Labels and Spanning Tree Roots Sub-TLV (INT-LABEL) 942 specified in [RFC7176]. 944 References: [RFC7176], [this document] 946 Bit Mnemonic Description Reference 947 --- -------- ----------- --------- 948 0 M4 IPv4 Multicast Router Attached [RFC7176] 949 1 M6 IPv6 Multicast Router Attached [RFC7176] 950 2 BM Bit Map [RFC7176] 951 3 ES ESADI Participation This document 952 4-7 - Unassigned 954 The creation of this sub-registry as immediately above assigns bit 3 955 as the ESADI Participation bit in the Interested Labels and Spanning 956 Tree Roots Sub-TLV. If The ESADI Participation bit is a one, it 957 indicates that the originating RBridge is participating in ESADI for 958 the indicated Data Label(s). 960 7.2 TRILL GENINFO TLV 962 IANA Action 3: 964 IANA is requested to allocate the IS-IS Application Identifier TBD 965 [1 suggested] under the Generic Information TLV (#251) [RFC6823] 966 for TRILL. 968 IANA Action 4: 970 IANA is requested to create a subregistry in the TRILL Parameters 971 Registry as follows: 973 Sub-Registry: TRILL APPsub-TLV Types under IS-IS TLV #251 974 Application Identifier #TBD 976 Registration Procedures: IETF Review with additional 977 requirements on the documentation of the use being 978 registered as specified in Section 7.2 of . 981 Note: Types greater than 255 are only usable in contexts 982 permitting a type larger than one byte, such as Extended 983 TLVs [FS-LSP]. 985 Reference: 987 Type Name Reference 988 ---------- -------- ----------- 989 0 Reserved 990 1 ESADI-PARAM 991 2-254 Unassigned 992 255 Reserved 993 256-65534 Unassigned 994 65535 Reserved 996 TRILL APPsub-TLV Types 2 through 254 and 256 through 65534 are 997 available for assignment by IETF Review. The RFC causing such an 998 assignment will also include a discussion of security issues and of 999 the rate of change of the information being advertised. TRILL 1000 APPsub-TLVs MUST NOT alter basic IS-IS protocol operation including 1001 the establishment of adjacencies, the update process, and the 1002 decision process for TRILL IS-IS [IS-IS], [RFC1195], [RFC7177]. The 1003 TRILL Generic Information TLV MUST NOT be used in an IS-IS instance 1004 zero [RFC6822] LSP but may be used in FS-LSPs [FS-LSP]. 1006 The V, I, D, and S flags in the initial flags byte of a TRILL Generic 1007 Information TLV have the meanings specified in [RFC6823] but are not 1008 currently used as TRILL operates as a Level 1 IS-IS area and no 1009 semantics are hereby assigned to the inclusion of an IPv4 and/or IPv6 1010 address via the I and V flags. Thus these I and V flags MUST be zero; 1011 however, if either or both is one, the space that should be taken by 1012 and IPv4 and/or IPv6 address respectively is skipped over and 1013 ignored. Furthermore, use of multi-level IS-IS is an obvious 1014 extension for TRILL [MultiLevel] and future IETF Standards Actions 1015 may update or obsolete this specification to provide for the use of 1016 any or all of these flags in the TRILL GENINFO TLV. 1018 The ESADI Parameters information, for which TRILL APPsub-TLV 1 is 1019 hereby assigned, is compact and slow changing (see Section 6.1). 1021 For Security Considerations related to ESADI and the ESADI parameters 1022 APPsub-TLV, see Section 8. 1024 8. Security Considerations 1026 ESADI PDUs can be authenticated through the inclusion of the 1027 Authentication TLV [RFC5310]. Defaults for such authentication are 1028 described in Section 6.3. 1030 The ESADI-LSP data primarily announces MAC address reachability 1031 within a Data Label. Such reachability can, in some cases, be an 1032 authenticated registration (for example, a layer 2 authenticated 1033 registration using cryptographically based EAP (Extensible 1034 Authentication Protocol [RFC3748]) methods via [802.1X]). The 1035 combination of these techniques can cause EASDI MAC reachability 1036 information to be substantially more trustworthy than MAC 1037 reachability learned from observation of the data plane. 1038 Nevertheless, ESADI still involves trusting all other RBridges in the 1039 TRILL campus, at least those that have the keying material necessary 1040 to construct a valid Authentication TLV. 1042 However, there may be cases where it is not necessary to authenticate 1043 ESADI PDUs despite using authenticated registration for end stations 1044 because of a significant threat of forged packets on end station 1045 links when that threat is not present for inter-RBridge trunks. For 1046 example a TRILL campus with secure RBridges and inter-RBridge links 1047 configured as trunks but some end stations connected via IEEE 802.11 1048 wireless access links might use 802.11 authentication for the 1049 connection of such end stations but not necessarily authenticate 1050 ESADI PDUs. Note that if the IS-IS LSPs in a TRILL campus are 1051 authenticated, perhaps due to a concern about forged packets, the 1052 ESADI PDUs will be authenticated by default as provided in Section 1053 6.3. 1055 MAC reachability learned from the data plane (the TRILL default) is 1056 overwritten by any future learning of the same type. ESADI 1057 advertisements are represented in Data Label scoped link state 1058 database. Thus ESADI makes visible any multiple attachments of the 1059 same MAC address within a Data Label to different RBridges (see 1060 Section 5.3). This may or may not be an error or misconfiguration but 1061 ESADI at least makes it explicitly and persistently visible, which 1062 would not be the case with data plane learning. 1064 For general TRILL Security Considerations, see [RFC6325]. 1066 8.1 Privacy Considerations 1068 The address reachability information distributed by ESADI has 1069 substantial privacy considerations under many, but not all, 1070 circumstances. 1072 For example, if ESADI were used in a TRILL campus with independent 1073 user end stations at the edge, the MAC addresses of such end stations 1074 could uniquely identify the users of those end stations. Their 1075 reachability would be sensitive information and, particularly if 1076 logged, be revealing of their users. On the other hand, if TRILL is 1077 being used to implement an Internet Exchange Point (IXP) to connect 1078 Internet Service Providers (ISPs), the MAC addresses being advertised 1079 in ESADI would typically be those of the ISP's directly connected IP 1080 router ports, since Layer 3 routers bound the TRILL campus, for which 1081 there would be few privacy concerns. 1083 However, records of MAC attachment, including a modest amount of 1084 history, perhaps a few days worth, can be useful in managing a 1085 network and troubleshooting network problems. It might, in some 1086 cases, also be legally required or required for billing purposes or 1087 the like. 1089 Network operators should seek a reasonable balance between these 1090 competing considerations for the circumstances of their particular 1091 networks where ESADI is in use. They should not maintain logs of MAC 1092 reachability information for any longer than is clearly required. 1094 9. Acknowledgements 1096 The authors thank the following, listed in alphabetic order, for 1097 their suggestions and contributions: 1099 David Black, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, 1100 Sujay Gupta, Russ Housley, Pearl Liang, Kathleen Moriarty, Thomas 1101 Narten, Erik Nordmark, and Mingui Zhang. 1103 This document was produced with raw nroff. All macros used were 1104 defined in the source file. 1106 Normative references 1108 [ASCII] - American National Standards Institute (formerly United 1109 States of America Standards Institute), "USA Code for 1110 Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 1111 has been replaced by newer versions with slight modifications, 1112 but the 1968 version remains definitive for the Internet. 1114 [FIPS180] - "Secure Hash Standard (SHS)", United States of American, 1115 National Institute of Science and Technology, Federal 1116 Information Processing Standard (FIPS) 180-4, March 2012, 1117 http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf 1119 [FS-LSP] - Ginsberg, L., S. Previdi, Y. Yang, "IS-IS Flooding Scope 1120 LSPs", draft-ietf-isis-fs-lsp, in RFC Editor's queue. 1122 [IS-IS] - International Organization for Standardization, 1123 "Intermediate system to Intermediate system intra-domain 1124 routeing information exchange protocol for use in conjunction 1125 with the protocol for providing the connectionless-mode Network 1126 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 1127 2002. 1129 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1130 dual environments", RFC 1195, December 1990. 1132 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1133 Requirement Levels", BCP 14, RFC 2119, March 1997. 1135 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 1136 "Randomness Requirements for Security", BCP 106, RFC 4086, June 1137 2005. 1139 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 1140 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1141 2008. 1143 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1144 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1145 5310, February 2009. 1147 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1148 Layer-2 Systems", RFC 6165, April 2011. 1150 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1151 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1152 Specification", RFC 6325, July 2011. 1154 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1155 Interconnection of Lots of Links (TRILL) Protocol Control 1156 Protocol", RFC 6361, August 2011. 1158 [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising 1159 Generic Information in IS-IS", RFC 6823, December 2012. 1161 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1162 and D. Dutt, "Transparent Interconnection of Lots of Links 1163 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 1165 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1166 D., and A. Banerjee, "Transparent Interconnection of Lots of 1167 Links (TRILL) Use of IS-IS", RFC 7176, May 2014. 1169 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1170 and V. Manral, "Transparent Interconnection of Lots of Links 1171 (TRILL): Adjacency", RFC 7177, May 2014. 1173 [RFC7180] - Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., 1174 and A. Banerjee, "Transparent Interconnection of Lots of Links 1175 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1176 May 2014. 1178 Informative References 1180 [802.1X] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 1181 networks / Port-Based Network Access Control", IEEE Std 1182 802.1X-2010, 5 February 2010. 1184 [FNV] - G. Fowler, L. Noll, K. Vo & D. Eastlake, "The FNV Non- 1185 Cryptographic Hash Algorithm", draft-eastlake-fnv, Work in 1186 progress. 1188 [RFC3748] - Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1189 Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 1190 3748, June 2004. 1192 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1193 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 1194 2011. 1196 [RFC6822] - Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and 1197 D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 1199 [MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai, 1200 "Multilevel TRILL (Transparent Interconnection of Lots of 1201 Links)", draft-perlman-trill-rbridge-multilevel, work in 1202 progress. 1204 [VLANmapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, 1205 and D. Eastlake, "RBridges: Campus VLAN and Priority Regions", 1206 draft-ietf-trill-rbridge-vlan-mapping, work in progress. 1208 Appendix A: Interoperability and Changes to [RFC6325] 1210 This appendix summarizes the significant changes this document makes 1211 to the TRILL base protocol specification [RFC6325]. Although 1212 simultaneous use of [RFC6325] ESADI and ESADI as specified in this 1213 document in a TRILL campus is very unlikely due to non-deployment of 1214 [RFC6325] ESADI, this Appendix also discusses, for each change, the 1215 interoperability considerations should such simultaneous use occur. 1217 A.1 ESADI PDU Changes 1219 The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is 1220 changed from the IS-IS Level 1 format [IS-IS] to the Extended Level 1 1221 Circuit Scoped format (E-L1CS) specified in [FS-LSP]. This change is 1222 not backwards compatible with [RFC6325]. It is made in light of the 1223 256 times greater information carrying capacity of the E- L1CS format 1224 compared with the base IS-IS format. It is anticipated that this 1225 greater carrying capacity will be needed, under some circumstances, 1226 to carry end station addressing information or other similar address 1227 and reachability information that is added to ESADI in the future. 1229 The PDU numbers used for the ESADI LSP, CSNP, and PSNP PDUs in 1230 [RFC6325] are 18, 24, and 26 [IS-IS]. With this document, the format 1231 changes and the PDU numbers change to 10, 11, and 12 [FS-LSP]. The 1232 use of different PDU numbers assures that a PDU will not be mis- 1233 parsed. Because of this, implementations of this document and 1234 implementations of [RFC6325] ESADI will discard each other's PDUs. 1235 Thus address reachability or other information distributed through 1236 either type of ESADI implementation will only be communicated to 1237 other implementations of the same type and the two communities will 1238 not communicate any information with each other. 1240 Note that RBridges can use the TRILL mandatory-to-implement, enabled- 1241 by-default data plane address learning in addition to ESADI. (Section 1242 5 of this document and the material it references explain how to 1243 handle conflicts between different sources of address reachability 1244 information.) Simply leaving data plane address learning enabled 1245 would enable smooth incremental migration from [RFC6325] EASDI to the 1246 ESADI specification in this document, should that be necessary. The 1247 data plane address learning would fill in any gaps due to non- 1248 communication between the two types of ESADI implementation although 1249 without the speed or security advantages of ESADI. 1251 A.2 Unicasting Changes 1253 Unicasting of ESADI PDUs is optionally supported including replacing 1254 Section 4.6.2.2 of [RFC6325] with the new text given in Section 4.1 1255 of this document. This unicast support is backwards compatible 1256 because it is only used when the recipient RBridge signals its 1257 support. 1259 A.3 Message Timing Changes and Suggestions 1261 The following timing relevant ESADI message changes and suggestions 1262 are included in this document: 1264 1. Provide for staggered delay for non-originators of ESADI-LSP 1265 fragments in response to requests for such fragments by CSNP and 1266 PSNP messages. 1268 2. Suggest staggered timing of unicast ESADI-LSPs when a new ESADI 1269 RBridge appears on the EASDI virtual link. 1271 These relate only to the timing of messages for congestion 1272 minimization. Should a message be lost, due to congestion or 1273 otherwise, it will be later retransmitted as a normal part of the 1274 robust flooding mechanism used by ESADI. 1276 A.4 Duplicate Address Reachability 1278 The handling of persistent reachability of the same MAC within the 1279 same Data Label from two or more RBridges is substantially modified 1280 including the explicit replacement of some text in Section 4.2.6 of 1281 [RFC6325] (see Section 5.3 of this document). There is no problem 1282 with a mixture of ESADI implementations in a TRILL campus, some 1283 conforming to [RFC6325] and some conforming with this document, for 1284 handling this condition. The more implementations conform to the 1285 improved behavior specified in this document for this condition, the 1286 better the traffic spreading will be and the less likely address 1287 flip-flopping problems are. 1289 Appendix Z: Change History 1291 RFC Editor: Please delete this section before publication. 1293 Z.1 From -00 to -01 1295 1. Add Section 6.3 "Default Authentication". 1297 2. Add "Acknowledgements" Section. 1299 3. Change requirement from "MAY" to "SHOULD" for an ESADI RBridge 1300 that is not DRB to send an ESADI-CSNP if it does not receive an 1301 ESADI-CSNP in long enough. 1303 4. Default CSNP Time was listed as 30 in one place and 40 in another. 1304 Change to uniformly specify 30. 1306 5. Update references to RFC 6326 to reference the 6326bis draft. 1308 6. Relax allocation criteria for TRILL APPsub-TLV type code points 1309 from Standard Action to IETF Review. 1311 7. Numerous Editorial changes. 1313 Z.2 From -01 to -02 1315 1. Extend to cover FGL and well as VLAN and introduce the term "Data 1316 Label" to cover both. 1318 2. Expand number of LSP fragments to 2**16. 1320 3. Simplify neighbor detection to no longer require possession of 1321 ESADI-LSP zero. 1323 4. Add update to last sentence of Section 4.2.6 of [RFC6325]. 1325 5. Update references for publication of RFCs 6822 and 6823. 1327 6. Additional minor changes. 1329 Z.3 From -02 to -03 1331 1. Replace instances of "IS-IS and data unreachable" with just "data 1332 unreachable" as data unreachability implies IS-IS unreachability 1333 [RFC7180]. 1335 2. With ESADI, there is just one virtual link on which all 1336 participating TRILL switches are adjacent. Thus, all of the useful 1337 ESADI-LSPs in an ESADI link state database are originated by a 1338 station on this virtual link. To avoid overworking the ESADI DRB 1339 on the link, ESADI-LSPs sent by a reachable TRILL switch in 1340 response to an ESADI-PSNP should be sent by the TRILL switch 1341 originating those EASDI-LSPs. 1343 3. Re-organize material on sending and receiving ESADI PDUs into more 1344 smaller subsections that cover all the different circumstances. 1346 4. Substantially expand Security Considerations section. 1348 5. Numerous editorial changes. 1350 Z.4 From -03 to -04 1352 1. Change to using Extended Level 1 Circuit Scope [FS-LSP] for EASDI- 1353 LSP, ESADI-CSNP, and ESADI-PSNP PDUs. 1355 2. Update references to RFC 6327 to the rfc6327bis draft. 1357 3. Sort Informational References RFCs in numeric order. 1359 4. Add Appendix A: summary of changes to [RFC6325]. 1361 5. Minor editing changes. 1363 Z.5 From -04 to -05 1365 1. Expand Appendix A to be more complete and precise. 1367 2. Add L2-IS-IS Ethertype to Figure 1 so figure and text match. 1369 3. For clarification, add an example pseudo-random function to the 1370 new text in Section 5.3. 1372 4. Eliminate possible unicasting of PSNPs. 1374 5. Provide for staggered delay for non-originators of ESADI-LSP 1375 fragments in response to requests for such fragments by CSNP and 1376 PSNP messages. 1378 6. In Section 7.2, cover inclusion in FS-LSPs as permitted by [FS- 1379 LSP]. 1381 7. Some editing changes including expanding "MAC&label". 1383 Z.6 From -05 to -06 1385 1. In Section 4.3: "a an adjacent" -> "an adjacent". 1387 2. In Section 4.4: "( 100 - Random (Jitter) )" -> Random(Jitter)". 1389 3. Add one Acknowledgement. 1391 Z.7 From -06 to -07 1393 Update based on GENART and IANA reviews: 1395 1. Update and extend the first paragraph of Section 1.1 and items 2 1396 and 3 in Appendix A with particular attention to how this 1397 document updates RFC 6325 and backwards compatibility. 1399 2. Minor edits to the first part of Section 2 to clarify "pseudo- 1400 nodes" and the use of common components inside an RBridge 1401 implementation of the independent ESADI instances. 1403 3. Add references to [RFC7172] inside Figures 2 and 3. 1405 4. Section 2.1, minor edits for clarity. 1407 5. Section 2.2, "is ignored" -> "MUST be ignored". 1409 6. Section 3, minor edit to clarify DRB election references. 1411 7. Explain source of "1470 bytes" in Section 6. 1413 8. Add new second paragraph to Section 8 to clarify cases where you 1414 might want authenticated end-station registration but would not 1415 need ESADI-PDU authentication. 1417 9. Substantial editorial changes to the IANA Considerations (Section 1418 7), based on IANA review, to clarify the requested IANA actions. 1420 10. Update Acknowledgements. 1422 11. Other minor editorial changes. 1424 Z.8 From -07 to -08 1426 Update primarily based on IESG review 1428 1. Re-write of Appendix A to add substantial interoperability 1429 considerations material. 1431 2. Addition of Privacy Considerations subsection to Security 1432 Considerations. 1434 3. Addition of references to [RFC5310] in connection with 1435 authentication of ESADI PDUs. 1437 4. Update draft references due to RFC publications and add some 1438 Acknowledgements. 1440 5. Minor editorial changes. 1442 Z.9 From -08 to -09 1444 1. Fix a few typos. 1446 2. Clarify encoding of Length field in Section 6.1. 1448 3. Clarify some wording in Section 1, list item 2. 1450 Authors' Addresses 1452 Hongjun Zhai 1453 ZTE Corporation 1454 68 Zijinghua Road 1455 Nanjing 200012 China 1457 Phone: +86-25-52877345 1458 Email: zhai.hongjun@zte.com.cn 1460 Fangwei Hu 1461 ZTE Corporation 1462 889 Bibo Road 1463 Shanghai 201203 China 1465 Phone: +86-21-68896273 1466 Email: hu.fangwei@zte.com.cn 1468 Radia Perlman 1469 Intel Labs 1470 2200 Mission College Blvd. 1471 Santa Clara, CA 95054-1549 USA 1473 Phone: +1-408-765-8080 1474 Email: Radia@alum.mit.edu 1476 Donald Eastlake 1477 Huawei Technologies 1478 155 Beaver Street 1479 Milford, MA 01757 USA 1481 Phone: +1-508-333-2270 1482 Email: d3e3e3@gmail.com 1484 Olen Stokes 1485 Extreme Networks 1486 Pamlico Building One, Suite 100 1487 3306 East NC Hwy 54 1488 RTP, NC 27709 USA 1490 Email: ostokes@extremenetworks.com 1492 Copyright and IPR Provisions 1494 Copyright (c) 2014 IETF Trust and the persons identified as the 1495 document authors. All rights reserved. 1497 This document is subject to BCP 78 and the IETF Trust's Legal 1498 Provisions Relating to IETF Documents 1499 (http://trustee.ietf.org/license-info) in effect on the date of 1500 publication of this document. Please review these documents 1501 carefully, as they describe your rights and restrictions with respect 1502 to this document. Code Components extracted from this document must 1503 include Simplified BSD License text as described in Section 4.e of 1504 the Trust Legal Provisions and are provided without warranty as 1505 described in the Simplified BSD License.