idnits 2.17.1 draft-ietf-trill-esadi-00.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 25, 2012) is 4320 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. 'IS-IS' ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 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 Expires: December 24, 2012 June 25, 2012 10 TRILL (Transparent Interconnection of Lots of Links): 11 The ESADI (End Station Address Distribution Information) Protocol 12 14 Abstract 16 The IETF TRILL (Transparent Interconnection of Lots of Links) 17 protocol provides least cost pair-wise data forwarding without 18 configuration in multi-hop networks with arbitrary topologies and 19 link technologies. TRILL supports for multi-pathing of both unicast 20 and multicast traffic. Devices that implement the TRILL protocol are 21 called RBridges (Routing Bridges) or TRILL Switches. 23 The ESADI (End Station Address Distribution Information) protocol is 24 a VLAN (Virtual Local Area Network) scoped way that TRILL switches 25 can communicate end station addresses to each other. An RBridge 26 announcing VLAN-x connectivity (normally a VLAN-x appointed 27 forwarder) and running the TRILL ESADI protocol can receive remote 28 address information and/or transmit local address information for 29 VLAN-x to other such RBridges. This document updates RFC 6325, 30 specifically the documentation of the ESADI protocol. 32 Status of This Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Distribution of this document is unlimited. Comments should be sent 38 to the TRILL working group mailing list: . 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 51 Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Table of Contents 56 1. Introduction............................................4 57 1.1 Content and Precedence.................................5 58 1.2 Terminology............................................5 60 2. ESADI Protocol Overview.................................6 61 3. ESADI DRB Determination................................10 63 4. ESADI PDU processing...................................11 64 4.1 Sending of ESADI PDUs.................................12 65 4.2 Receipt of ESADI PDUs.................................13 67 5. End Station Addresses..................................14 68 5.1 Learning Confidence Level.............................14 69 5.2 Forgetting End Station Addresses......................14 71 6. ESADI-LSP Contents.....................................15 72 6.1 ESADI Parameter Data..................................15 73 6.2 MAC Reachability TLV..................................16 75 7. IANA Considerations....................................17 76 7.1 ESADI Participation and Capability Flags..............17 77 7.2 TRILL GENAPP TLV......................................17 79 8. Security Considerations................................19 81 9. References.............................................20 82 9.1 Normative references..................................20 83 9.2 Informative References................................21 85 1. Introduction 87 The IETF TRILL (Transparent Interconnection of Lots of Links) 88 protocol [RFC6325] provides least cost pair-wise data forwarding 89 without configuration in multi-hop networks with arbitrary topologies 90 and link technologies, safe forwarding even during periods of 91 temporary loops, and support for multi-pathing of both unicast and 92 multicast traffic. TRILL accomplishes this by using the IS-IS 93 (Intermediate System to Intermediate System) [IS-IS] [RFC1195] 94 [RFC6326] link state routing protocol and encapsulating traffic using 95 a header that includes a hop count. The design supports VLANs 96 (Virtual Local Area Networks) and optimization of the distribution of 97 multi-destination frames based on VLANs and IP multicast groups. 98 Devices that implement TRILL are called RBridges (Routing Bridges) or 99 TRILL switches. 101 There are five ways an RBridge can learn end station addresses as 102 described in Section 4.8 of [RFC6325]. The ESADI (End Station 103 Address Distribution Information) protocol is an optional VLAN scoped 104 way RBridges can communicate locally learned end station addresses 105 with each other. An RBridge that is announcing connectivity to VLAN-x 106 (normally a VLAN-x appointed forwarder [RFC6439]) MAY use the ESADI 107 protocol to announce the end station address of some or all of its 108 attached VLAN-x end nodes to other RBridges that are running ESADI 109 for VLAN-x. 111 By default, RBridges with connected end stations learn addresses from 112 the data plane when ingressing and egressing native frames. The ESADI 113 protocol's potential advantages over data plane learning include the 114 following: 116 1. Security advantages: The ESADI protocol can be used to announce 117 end stations with an authenticated enrollment (for example 118 enrollment authenticated by cryptographically based EAP 119 (Extensible Authentication Protocol [RFC3748]) methods via 120 [802.1X]). In addition, the ESADI protocol supports cryptographic 121 authentication of its message payloads for more secure 122 transmission. 124 2. Fast update advantages: The ESADI protocol provides a fast update 125 of end stations MAC (Media Access Control) addresses. If an end 126 station is unplugged from one RBridge and plugged into another, 127 frames addressed to that older RBridge can be black holed. They 128 can be sent just to the older RBridge that the end station was 129 connected to until cached address information at some remote 130 RBridge times out, possibly for tens of seconds or more [RFC6325]. 132 MAC address reachability information and some ESADI parameters are 133 carried in ESADI frames rather than in the TRILL IS-IS protocol. As 134 described below, ESADI is, for each VLAN, a virtual logical topology 135 overlay in the TRILL topology. An advantage of using ESADI is that 136 the end station attachment information is not flooded to all RBridges 137 through TRILL IS-IS but only to participating RBridges advertising 138 ESADI support for the VLAN in which those end stations occur. 140 1.1 Content and Precedence 142 This document updates [RFC6325], the TRILL basic specification, 143 essentially replacing the description of the ESADI protocol, and 144 prevails over [RFC6325] where they conflict. 146 Section 2 is the ESADI protocol overview. Section 3 specifies ESADI 147 DRB state. Section 4 discusses the processing of ESADI PDUs. Section 148 5 discusses interaction with other modes of end station address 149 learning. And Section 6 describes the ESADI-LSP contents. 151 1.2 Terminology 153 This document uses the acronyms defined in [RFC6325] and the 154 following phrase: 156 LSP number zero - A Link State PDU with fragment number equal to 157 zero. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. ESADI Protocol Overview 165 ESADI is a VLAN scoped way that RBridges can announce and learn end 166 station addresses rapidly and securely. An RBridge that is 167 announcing itself as connected to one or more VLANs (usually because 168 it is an Appointed Forwarder for those VLANs [RFC6439]) and 169 participates in the ESADI protocol is called an ESADI RBridge. 171 ESADI is a separate protocol from the TRILL IS-IS implemented by all 172 RBridges in a campus. There is a separate ESADI instance for each 173 VLAN. In essence, for each VLAN, there is a modified instance of the 174 IS-IS reliable flooding mechanism in which ESADI RBridges may choose 175 to participate. (These are not the instances being specified in 176 [MultiInstance].) It is an implementation decision how independent 177 the multiple ESADI instances at an RBridge are. For example, the 178 ESADI link state could be in a single database with a field in each 179 record indicating the VLAN to which it applies or could be a separate 180 database per VLAN. But the update process operates separately for 181 each ESADI instance and independently from the TRILL IS-IS update 182 process. 184 After the TRILL header, ESADI frames have an inner Ethernet header 185 with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All- 186 ESADI-RBridges"), an Inner.VLAN tag specifying the VLAN of interest, 187 and the "L2-IS-IS" Ethertype followed by the ESADI payload as shown 188 in Figure 1. 190 TRILL ESADI frame Structure 192 +--------------------------------+ 193 | Link Header | 194 +--------------------------------+ 195 | TRILL Data Header | 196 +--------------------------------+ 197 | Inner Ethernet Header | 198 +--------------------------------+ 199 | ESADI Payload | 200 +--------------------------------+ 201 | Link Trailer | 202 +--------------------------------+ 204 Figure 1. 206 TRILL ESADI frames sent on an Ethernet link are structured as shown 207 below. The outer VLAN tag will not be present if it was stripped by 208 the port out of which the frame was sent. 210 Outer Ethernet Header: 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | All-RBridges Multicast Address | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | All-RBridges Multicast Addr. | Sending RBridge Port MAC Addr.| 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Sending RBridge Port MAC Address | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Ethertype = C-Tag 0x8100 | Outer.VLAN Tag Information | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Ethertype = TRILL 0x22F3 | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | V | R |M|Op-Length| Hop Count | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Egress Nickname | Ingress (Origin) Nickname | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Inner Ethernet Header: 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Next Hop Destination Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Next Hop Dest. Address cont. | Origin RBridge MAC Address | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Origin RBridge MAC Address continued | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Ethertype = C-Tag 0x8100 | Inner.VLAN Tag Information | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Ethertype = L2-IS-IS 0x22F4 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 ESADI Payload (formatted as IS-IS): 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Frame Check Sequence: 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | FCS (Frame Check Sequence) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: ESADI Ethernet Link Frame Format 250 The VLAN specified in the Outer.VLAN information will always be the 251 Designated VLAN for the link on which the frame is sent. The V and R 252 fields will be zero while the M field will be one unless the RBridge 253 supports unicasting ESADI PDUs, in which case the M field MAY be 254 zero. The VLAN specified in the Inner.VLAN information will be the 255 VLAN to which the ESADI frame applies. The Origin RBridge MAC Address 256 or Inner.MacSA MUST be a globally unique MAC address owned by the 257 RBridge originating the ESADI frame, for example, any of its port MAC 258 addresses, and each RBridge MUST use the same Inner.MacSA for all of 259 the ESADI frames that RBridge originates. 261 TRILL ESADI frames sent on a PPP link are structured as shown below. 263 PPP Header: 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | PPP = TNP (TRILL data) 0x005D | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | V | R |M|Op-Length| Hop Count | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Egress Nickname | Ingress (Origin) Nickname | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Inner Ethernet Header: 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Next Hop Destination Address | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Next Hop Dest. Address cont. | Origin RBridge MAC Address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Origin RBridge MAC Address continued | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Ethertype = C-Tag 0x8100 | Inner.VLAN Tag Information | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Ethertype = L2-IS-IS 0x22F4 | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 ESADI Payload (formatted as IS-IS): 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 PPP Check Sequence: 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | PPP Check Sequence | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 3: ESADI PPP Link Frame Format 295 All transit RBridges forward ESADI frames as if they were ordinary 296 TRILL Data frames. Because of this forwarding, it appears to an 297 instance of the ESADI protocol at an RBridge that it is directly 298 connected by a multi-access virtual link to all other RBridges in the 299 campus running ESADI for that VLAN. No "routing" computation or 300 routing decisions ever have to be performed by ESADI. An ESADI 301 RBridge merely transmits the ESADI frames it originates on this 302 virtual link as described for TRILL Data frames in [RFC6325]. For 303 multicast ESADI frames, which is the normal case, it may use any 304 distribution tree that it might use for a normal multi-destination 305 TRILL Data frame. RBridges that do not implement the ESADI protocol, 306 do not have it enabled, or are not participating for the Inner.VLAN 307 of an ESADI frame do not decapsulate or locally process any multicast 308 TRILL ESADI frames they receive. Thus the ESADI frames are 309 transparently tunneled through transit RBridges. 311 TRILL ESADI frame payloads are structured like IS-IS PDUs, except as 312 indicated below, but are always TRILL encapsulated on the wire as if 313 they were TRILL Data frames. The ESADI instance for VLAN-x at an 314 RBridge RB1 determines who its ESADI potential neighbors are by 315 logically examining the TRILL IS-IS link state database for RBridges 316 that are data and IS-IS reachable from RB1 (see Section 2 of 317 [ClearCorrect]) and are announcing their participation in VLAN-x 318 ESADI. When an RBridge RB2 becomes IS-IS or data unreachable from RB1 319 or any of the relevant entries for RB2 are purged from the core IS-IS 320 link state database, it is lost as a potential neighbor and also 321 dropped from any ESADI instances. And when RB2 is no longer 322 announcing participation in VLAN-x ESADI, it ceases to be a potential 323 neighbor for the VLAN-x ESADI instance. RB2 becomes an actual ESADI 324 adjacency for RB1 when it is a potential neighbor and RB1 holds an 325 ESADI-LSP zero for RB2, all these considerations being VLAN scoped. 326 Because of these mechanisms, there are no "Hellos" sent in ESADI. 328 The information distributed by the ESADI protocol is a list of local 329 end station MAC addresses connected to the originating RBridge and, 330 for each such address, a one octet unsigned "confidence" rating in 331 the range 0-254 (see Section 6.1). It is entirely up to the 332 originating RBridge which locally connected MAC addresses it wishes 333 to advertise via ESADI and with what confidence. It MAY advertise 334 all, some, or none of such addresses. Future uses of ESADI may 335 distribute additional types of information. 337 TRILL ESADI-LSPs MUST NOT contain a VLAN ID in their payload. The 338 VLAN ID to which the ESADI data applies is the Inner.VLAN of the 339 TRILL Data frame enclosing the ESADI payload. If a VLAN ID could 340 occur within the payload, it might conflict with the Inner.VLAN and 341 could conflict with any future VLAN mapping scheme that may be 342 adopted [VLANmapping]. If a VLAN ID field within an ESADI-LSP PDU 343 does include a VLAN ID, its contents is ignored. 345 3. ESADI DRB Determination 347 Generally speaking, the DRB state on the ESADI link operates 348 similarly to a TRILL IS-IS broadcast link with the following 349 exception: 351 In the VLAN-x ESADI-DRB election at RB1 on an ESADI virtual link, 352 comparing with [RFC6327], the candidates are the local ESADI instance 353 for VLAN-x and all remote ESADI instances at RBridges that (1) are 354 data and IS-IS reachable from RB1 [ClearCorrect], (2) are announcing 355 in their TRILL IS-IS LSP that they are participating in ESADI for 356 VLAN-x, and (3) for which RB1 is holding an ESADI-LSP zero with an 357 ESADI Parameters APPsub-TLV. The winner is the instance with the 358 highest ESADI Parameter 7-bit priority field with ties broken by 359 System ID, comparing fields as unsigned integers with the larger 360 magnitude considered higher priority. In particular "SNPA/MAC 361 address" is not considered and there is no "Port ID". 363 Because ESADI does no routing, the ESADI-DRB does not create a 364 pseudonode. 366 4. ESADI PDU processing 368 VLAN-x ESADI neighbors are usually not connected directly by a 369 physical link, but are always logically connected by a virtual link. 370 There could be hundreds or thousands of ESADI RBridges on the virtual 371 link. There are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used 372 in ESADI. In particular, there are no Hello or MTU PDUs because ESADI 373 does not build a topology and does not do any routing. 375 In Layer 3 IS-IS, PDU multicasting is normally on a local link and no 376 effort is made to optimize to unicast because under the original 377 conditions when IS-IS was designed (commonly a piece of multi-access 378 Ethernet cable) any frame made the link busy for that frame time. But 379 in ESADI what appears to be a simple multi-access link is generally a 380 set of multi-hop distribution trees that may or may not be pruned. 381 Thus, transmitting a multicast frame on such a tree imposes a greater 382 load than transmitting a unicast frame. This load may be justified if 383 there are likely to be multiple listeners but may not be justified if 384 there is only one recipient of interest. For this reason, under some 385 circumstances, ESADI PDUs MAY be TRILL unicast if it is confirmed 386 that the destination RBridge supports receiving unicast ESADI PDUs. 388 To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is 389 replaced with the following: 391 "4.6.2.2. TRILL ESADI Frames 393 If M=1, the egress nickname designates the distribution tree. The 394 frame is forwarded as described in Section 4.6.2.5. In addition, 395 if the forwarding RBridge is (1) interested in the specified VLAN, 396 for example it is Appointed Forwarder for that VLAN on at least 397 one port, (2) implements the TRILL ESADI protocol, and (3) ESADI 398 is enabled for that VLAN, the inner frame is decapsulated and 399 provided to that local ESADI protocol. 401 If M=0 and the egress nickname is not that of the receiving 402 RBridge, the frame is forwarded as for known unicast TRILL Data in 403 Section 4.6.2.4. If M=0 and the egress nickname is that of the 404 receiving RBridge and the receiving RBridge supports unicast ESADI 405 PDUs, then the ESADI frame is decapsulated and processed if it 406 meets the three numbered conditions in the paragraph above, 407 otherwise it is discarded." 409 The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above 410 references to those sections in [RFC6325]. 412 Section 4.1 describes the sending of ESADI PDUs. Section 4.2 covers 413 the receipt of ESADI PDUs. 415 4.1 Sending of ESADI PDUs 417 The MTU available to instances of ESADI is at least 24 bytes less 418 than that available to TRILL IS-IS because of the additional fields 419 required (2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 420 6(Inner.MacSA) + 4(Inner.VLAN)). Thus the inner ESADI payload, 421 starting with the Intradomain Routeing Protocol Discriminator byte, 422 MUST NOT exceed Sz minus 24; however, if a larger payload is 423 received, it is processed normally. 425 Once an ESADI instance is operationally up for VLAN-x, it multicasts 426 its self-originated ESADI-LSP number zero on the virtual link to 427 announce its ESADI parameters. When the other ESADI instances receive 428 the ESADI-LSP number zero and find a new neighbor, their self- 429 originated LSP fragments are scheduled to be sent and MAY be unicast 430 to that neighbor if the neighbor is announcing in its LSP that it 431 supports unicast ESADI. If all the other ESADI instances send their 432 self-originated ESADI-LSPs immediately, there may be a surge of 433 traffic to that new neighbor. So the other ESADI instances should 434 wait an interval time before sending the ESADI-LSP to a new neighbor. 435 The interval time value is up to the device implementation. One 436 suggestion is that the interval time can be assigned a random value 437 with a range based on the ESADI priority when implementation. 439 If the ESADI instance believes it is DRB, it multicasts an ESADI-CSNP 440 periodically to keep the Link State Database synchronized among its 441 neighbors on the virtual link. After receiving an ESADI-PSNP PDU, the 442 DRB will multicast the ESADI-LSPs requested by the ESADI-PSNP on the 443 virtual link. 445 For robustness, if an ESADI instance has two or more ESADI neighbors 446 and is not DRB and it receives no ESADI-CSNP PDUs for at least the 447 CSNP Time (see Section 6.1) of the DRB, it MAY transmit an ESADI- 448 CSNP. 450 In the case of receiving an ESADI-LSP with a smaller sequence number 451 than the copy stored in the local EASDI Link State Database, the 452 local ESADI instance will also schedule to transmit the stored copy 453 and MAY unicast it to the sender of the received ESADI-LSP if it is 454 confirmed that the sender supports receiving unicast ESADI PDUs. 456 The format of a unicast ESADI frame is the format of TRILL ESADI 457 frame, in Section 4.2 in [RFC6325], except as follows: 459 o On an Ethernet link, in the Outer Ethernet Header the Outer.MacDA 460 is the unicast address of the next hope RBridge. 462 o In the TRILL header, the M bit is set to zero and the Egress 463 Nickname is the nickname of the destination RBridge. 465 4.2 Receipt of ESADI PDUs 467 Because ESADI adjacency is in terms of System ID, all PDU acceptance 468 tests that check that the PDU is from an adjacent system check that 469 the System ID is that of an ESADI neighbor and do not check ether the 470 source Inner or Outer SNPA/MAC. 472 Because all ESADI instance for VLAN-x are adjacent, when RB1 receives 473 an ESADI-CSNP from RB2 and detects that it has ESADI-LSPs that RB1 is 474 missing, it sets the transmission flag only for its own ESADI-LSPs 475 that RB1 is missing. Missing ESADI-LSPs originated by other ESADI 476 instances will be detected by those other instances. 478 When receiving an ESADI-PSNP PDU, if the local ESADI instance is DRB, 479 ESADI-LSP PDU requested by the ESADI-PSNP will be multicast on the 480 virtual link. 482 5. End Station Addresses 484 5.1 Learning Confidence Level 486 The confidence level mechanism allows an RBridge campus manager to 487 cause certain address learning sources to prevail over others. MAC 488 address information learned through a registration protocol, such as 489 [802.1X] with a cryptographically based EAP [RFC3748] method, might 490 be considered more reliable than information learned through the mere 491 observation of data frames. When such authenticated learned address 492 information is transmitted via the ESADI protocol, the use of 493 authentication in the TRILL ESADI-LSP frames could make tampering 494 with it in transit very difficult. As a result, it might be 495 reasonable to announce such authenticated information via the ESADI 496 protocol with a high confidence, so it would be used in preference to 497 any alternative learning from data observation. 499 5.2 Forgetting End Station Addresses 501 The end station addresses learned through TRILL ESADI protocol should 502 be forgotten by its ESADI-LSP. The time out of the learned end 503 station address is up to the originating RBridge to decide when to 504 remove such information from its ESADI-LSPs (or up to ESADI protocol 505 timeouts if the originating RBridge becomes inaccessible). 507 If RBridge RBn participating in the TRILL ESADI protocol for VLAN-x 508 is no longer appointed forwarder for VLAN-x on any port where it is 509 providing end station service, it ceases to participate in ESADI 510 after sending a final ESADI-LSP nulling out its ESADI-LSP 511 information. (All other RBridges that are VLAN-x forwarder on at 512 least one of their ports notice that the link state data for RBn has 513 changed to show that it no longer has a link in VLAN-x. In response, 514 they forget all end station address information they have learned 515 from decapsulating VLAN-x frames that show RBn as the ingress 516 RBridge.) 518 6. ESADI-LSP Contents 520 The only PDUs used in ESADI are the Level 1 ESADI-LSP, ESADI-CSNP, 521 and ESADI-PSNP PDUs. The content of an ESADI-LSP consists of zero or 522 more MAC Reachability TLVs, optionally an Authentication TLV, and 523 exactly one ESADI parameter APPsub-TLV in ESADI-LSP zero. This 524 section specifies the format for ESADI parameter data APPsub-TLV and 525 gives the reference for the ESADI MAC Reachability TLV. In the 526 future, there may be other TLVs or sub-TLVs carried in EASDAI-LSPs. 528 ESADI-LSP number zero MUST NOT exceed 1470 minus 24 bytes in length 529 (1446 bytes) but if received longer, it is still processed normally. 531 6.1 ESADI Parameter Data 533 The figure below presents the format of the ESADI parameter data. 534 This APPsub-TLV MUST be included in a TRILL GENAPP TLV in ESADI-LSP 535 number zero. If it is missing from ESADI-LSP number zero, priority is 536 assumed to be zero and CSNP time 40. If there is more than one 537 occurrence in ESADI-LSP zero, the first occurrence will be used. 538 Occurrences of the ESADI parameter data APPsub-TLV in non-zero ESADI- 539 LSP fragments are ignored. 541 +-+-+-+-+-+-+-+-+ 542 | Type | (1 byte) 543 +-+-+-+-+-+-+-+-+ 544 | Length | (1 byte) 545 +-+-+-+-+-+-+-+-+ 546 |R| Priority | (1 byte) 547 +-+-+-+-+-+-+-+-+ 548 | CSNP Time | (1 byte 549 +-+-+-+-+-+-+-+-+ 550 | Reserved for expansion (variable) 551 +-+-+-+-... 553 Figure 4. ESADI Parameter APPsub-TLV 555 Type: set to ESADI-PARAM subTLV (TRILL APPsub-TLV type 1). 557 Length: Set to 2 to 255. 559 R: A reserved bit that MUST be sent as zero and ignored on receipt. 561 Priority: The Priority field gives the ESADI instance's priority for 562 being DRB on the TRILL ESADI virtual link for the VLAN in which 563 the PDU containing the parameter data was sent. It is an unsigned 564 seven-bit integer with larger magnitude indication higher 565 priority. It defaults to 0x40 for an RBridge participating in 566 ESADI for which it has not been configured. 568 CSNP Time: An unsigned byte that gives the amount of time in seconds 569 during which the originating RBridge, if it is DRB on the ESADI 570 link, will send at least 3 EASDI-CSNP PDUs. It defaults to 30 571 seconds for an RBridge participating in ESADI for which it has not 572 been configured. 574 Reserved for future expansion: Future versions of the ESADI 575 Parameters APPsub-TLV may have additional information. A receiving 576 ESADI RBridge ignores any additional data here unless it 577 implements such future expansion(s). 579 6.2 MAC Reachability TLV 581 The primary information in TRILL ESADI-LSP PDUs consists of MAC 582 Reachability (MAC-RI) TLVs as specified in [RFC6165]. These TLVs 583 contain one or more unicast MAC addresses of end stations that are 584 both on a port and in a VLAN for which the originating RBridge is 585 appointed forwarder, along with the one octet unsigned Confidence in 586 this information with a value in the range 0-254. If such a TLV is 587 received with a confidence of 255, it is treated as if the confidence 588 was 254. 590 To avoid conflict with the Inner.VLAN ID, the TLVs in TRILL ESADI 591 PDUs, including the MAC-RI TLV, MUST NOT contain the VLAN ID. If a 592 VLAN-ID is present in the MAC-RI TLV, it is ignored. In the 593 encapsulated TRILL ESADI frame, only the Inner.VLAN tag indicates the 594 VLAN to which the ESADI-LSP applies. 596 7. IANA Considerations 598 IANA allocation considerations are given below. 600 7.1 ESADI Participation and Capability Flags 602 IANA is requested to allocate an "ESADI Participation" and the 603 "capability of receiving unicast ESADI PDU" bit in the Interested 604 VLANs and Spanning Tree Roots sub-TLV [RFC6326]. (bit 2 and 3 605 respectively in the Interested VLANs field recommended) If bit 2 is a 606 one, it indicates that the originating RBridge is participating in 607 ESADI for the indicated VLAN or VLANs. If bit 3 is a one, it 608 indicates that the originating RBridge has the capability of 609 receiving and processing unicast ESADI PDUs. 611 7.2 TRILL GENAPP TLV 613 IANA is requested to allocate an IS-IS Application Identifier under 614 the Generic Information TLV (#251) for TRILL [RFCgenapp] and to 615 create a subregistry in the TRILL Parameters Registry for "TRILL 616 APPsub-TLVs under IS-IS TLV #251 Application Identifier #TBD". The 617 initial contents of this subregistry are as follows: 619 Type Name Reference 620 ------ -------- ----------- 621 0 Reserved 622 1 ESADI-PARAM 623 2-254 Available 624 255 Reserved 626 TRILL APPsub-TLV Types 2 through 254 are available for allocation by 627 Standard Action, as modified by [RFC4020]. The standards track RFC 628 causing such an allocation will also include a discussion of security 629 issues and of the rate of change of the information being advertised. 630 TRILL APPsub-TLVs MUST NOT alter basic TRILL IS-IS protocol operation 631 including the establishment of IS-IS adjacencies, the update process, 632 and the decision process for TRILL IS-IS [IS-IS] [RFC1195] [RFC6327]. 633 The TRILL Generic Information TLV MUST NOT be used in an IS-IS 634 instance zero [MultiInstance]. 636 The V, I, D, and S flags in the initial flags byte of a TRILL Generic 637 Information TLV have the meanings specified in [RFCgenapp] but are 638 not currently used as TRILL operates as a Level 1 IS-IS area and no 639 semantics is hereby assigned to the inclusion of an IPv4 and/or IPv6 640 address via the I and V flags. Thus these flags MUST be zero; 641 however, use of multi-level IS-IS is an obvious extension for TRILL 642 [MultiLevel] and future IETF Standards Actions may update or obsolete 643 this specification to provide for the use of any or all of these 644 flags in the TRILL GENAPP TLV. 646 The ESADI Parameters information, for which APPsub-TLV 1 is hereby 647 assigned, is compact and slow changing (see Section 6.1). 649 For Security Considerations related to ESADI and the ESADI parameters 650 APPsub-TLV, see Section 8. 652 8. Security Considerations 654 For general TRILL Security Considerations, see [RFC6325]. 656 More TBD 658 9. References 660 Normative and informative references for this document are below. 662 9.1 Normative references 664 [IS-IS] - International Organization for Standardization, 665 "Intermediate system to Intermediate system intra-domain 666 routeing information exchange protocol for use in conjunction 667 with the protocol for providing the connectionless-mode Network 668 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 669 2002. 671 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 672 dual environments", RFC 1195, December 1990. 674 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 678 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 680 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 681 Layer-2 Systems", RFC 6165, April 2011. 683 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 684 Ghanwani, "Routing Bridges (RBridges): Base Protocol 685 Specification", RFC 6325, July 2011. 687 [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 688 Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) 689 Use of IS-IS", RFC 6326, July 2011. 691 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 692 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 693 6327, July 2011. 695 [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 696 Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 697 6439, November 2011. 699 [RFCgenapp] - Ginsberg, L., S. Previdi, M. Shand, "Advertising 700 Generic Information in IS-IS", draft-ietf-isis-genapp-04.txt, 701 in RFC Editor's queue. 703 [ClearCorrect] - draft-ietf-trill-clear-correct, work in progress. 705 9.2 Informative References 707 [802.1X] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 708 networks / Port-Based Network Access Control", IEEE Std 709 802.1X-2010, 5 February 2010. 711 [MultiInstance] - Previdi, S., L. Ginsberg, M. Shand, A. Roy, D. 712 Ward, draft-ietf-isis-mi, work in progress. 714 [MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai, draft- 715 perlman-trill-rbridge-multilevel, work in progress. 717 [RFC3748] - Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 718 Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 719 3748, June 2004. 721 [VLANmapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, 722 and D. Eastlake, "RBridges: Campus VLAN and Priority Regions", 723 draft-ietf-trill-rbridge-vlan-mapping, work in progress. 725 Authors' Addresses 727 Hongjun Zhai 728 ZTE Corporation 729 68 Zijinghua Road 730 Nanjing 200012 China 732 Phone: +86-25-52877345 733 Email: zhai.hongjun@zte.com.cn 735 Fangwei Hu 736 ZTE Corporation 737 889 Bibo Road 738 Shanghai 201203 China 740 Phone: +86-21-68896273 741 Email: hu.fangwei@zte.com.cn 743 Radia Perlman 744 Intel Labs 745 2200 Mission College Blvd. 746 Santa Clara, CA 95054-1549 USA 748 Phone: +1-408-765-8080 749 Email: Radia@alum.mit.edu 751 Donald Eastlake 752 Huawei R&D USA 753 155 Beaver Street 754 Milford, MA 01757 USA 756 Phone: +1-508-333-2270 757 Email: d3e3e3@gmail.com 759 Copyright and IPR Provisions 761 Copyright (c) 2012 IETF Trust and the persons identified as the 762 document authors. All rights reserved. 764 This document is subject to BCP 78 and the IETF Trust's Legal 765 Provisions Relating to IETF Documents 766 (http://trustee.ietf.org/license-info) in effect on the date of 767 publication of this document. Please review these documents 768 carefully, as they describe your rights and restrictions with respect 769 to this document. Code Components extracted from this document must 770 include Simplified BSD License text as described in Section 4.e of 771 the Trust Legal Provisions and are provided without warranty as 772 described in the Simplified BSD License. The definitive version of 773 an IETF Document is that published by, or under the auspices of, the 774 IETF. Versions of IETF Documents that are published by third parties, 775 including those that are translated into other languages, should not 776 be considered to be definitive versions of IETF Documents. The 777 definitive version of these Legal Provisions is that published by, or 778 under the auspices of, the IETF. Versions of these Legal Provisions 779 that are published by third parties, including those that are 780 translated into other languages, should not be considered to be 781 definitive versions of these Legal Provisions. For the avoidance of 782 doubt, each Contributor to the IETF Standards Process licenses each 783 Contribution that he or she makes as part of the IETF Standards 784 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 785 language to the contrary, or terms, conditions or rights that differ 786 from or are inconsistent with the rights and licenses granted under 787 RFC 5378, shall have any effect and shall be null and void, whether 788 published or posted by such Contributor, or included with or in such 789 Contribution.