idnits 2.17.1 draft-hu-trill-rbridge-esadi-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2012) is 4399 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) Summary: 3 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: October 10, 2012 April 11, 2012 10 TRILL: The ESADI Protocol 11 13 Abstract 15 The IETF TRILL (TRansparent Interconnection of Lots of Links) 16 protocol provides least cost pair-wise data forwarding without 17 configuration in multi-hop networks with arbitrary topologies and 18 link technologies. TRILL supports the multi-pathing of both unicast 19 and multicast traffic. Devices that implement the TRILL protocol are 20 called RBridges (Routing Bridges) or TRILL Switches. 22 The ESADI (End System Address Distribution Information) protocol is a 23 VLAN (Virtual Local Area Network) scoped way that TRILL switches can 24 communicate end station addresses to each other. An RBridge 25 announcing VLAN-x connectivity (normally a VLAN-x appointed 26 forwarder) and running the TRILL ESADI protocol can receive remote 27 address information and/or transmit local address information for 28 VLAN-x to other such RBridges. This document updates RFC 6325, 29 specifically the documentation of the ESADI protocol. 31 Status of This Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Distribution of this document is unlimited. Comments should be sent 37 to the TRILL working group mailing list: . 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft 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 State.........................................8 63 4. ESADI PDU processing....................................9 64 4.1 Sending of ESASI PDUs..................................9 65 4.2 Receipt of ESADI PDUs.................................10 67 5. ESADI-LSP Contents.....................................11 68 5.1 ESADI Parameter Data..................................11 69 5.2 MAC Reachability TLV..................................12 71 6. IANA Considerations....................................13 72 6.1 ESADI Participation Flag..............................13 73 6.2 TRILL GENAPP TLV......................................13 75 7. Security Considerations................................15 77 8. References.............................................16 78 8.1 Normative references..................................16 79 8.2 Informative References................................17 81 1. Introduction 83 The IETF TRILL (TRansparent Interconnection of Lots of Links) 84 protocol [RFC6325] provides least cost pair-wise data forwarding 85 without configuration in multi-hop networks with arbitrary topologies 86 and link technologies, safe forwarding even during periods of 87 temporary loops, and support for multi-pathing of both unicast and 88 multicast traffic. TRILL accomplishes this by using the IS-IS 89 (Intermediate System to Intermediate System) [IS-IS] [RFC1195] 90 [RFC6326] link state routing protocol and encapsulating traffic using 91 a header that includes a hop count. The design supports VLANs 92 (Virtual Local Area Networks) and optimization of the distribution of 93 multi-destination frames based on VLANs and IP multicast groups. 94 Devices that implement TRILL are called RBridges (Routing Bridges) or 95 TRILL switches. 97 There are five ways an RBridge can learn end station addresses as 98 described in Section 4.8 of [RFC6325]. The ESADI (End Station 99 Address Distribution Information) protocol is an optional VLAN scoped 100 way RBridges can communicate end station addresses with each other. 101 An RBridge that is announcing connectivity to VLAN-x (normally a 102 VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce 103 the end station address of some or all of its attached VLAN-x end 104 nodes to other RBridges that are running ESADI for VLAN-x. 106 By default, RBridges with connected end stations learn addresses from 107 the data plane when ingressing and egressing native frames. The ESADI 108 protocol's potential advantages over data plane learning include the 109 following: 111 1. Security advantages: The ESADI protocol can be used to announce 112 end stations with an authenticated enrollment (for example 113 enrollment authenticated by cryptographically based EAP 114 (Extensible Authentication Protocol [RFC3748]) methods via 115 [802.1X]). In addition, the ESADI protocol supports cryptographic 116 authentication of its message payloads for more secure 117 transmission. 119 2. Fast update advantages: ESADI protocol provides a fast update of 120 end nodes MAC (Media Access Control) addresses. If an end station 121 is unplugged from one RBridge and plugged into another, frames 122 addressed to that older RBridge can be black holed. They can be 123 sent just to the older RBridge that the end station was connected 124 to until cached address information at some remote RBridge times 125 out, possibly for tens of seconds [RFC6325]. 127 MAC address reachability information and some ESADI parameters are 128 carried in ESADI frames rather than in the TRILL IS-IS protocol. As 129 described below, ESADI is, for each VLAN, a virtual logical topology 130 overlay in the TRILL topology. An advantage of using ESADI is that 131 the end station attachment information is not flooded to all RBridges 132 through TRILL IS-IS but only to participating RBridges advertising 133 ESADI support for the VLAN in which those end stations occur. 135 1.1 Content and Precedence 137 This document updates [RFC6325], the TRILL basic specification, 138 particularly the description of the ESADI protocol, and prevails over 139 [RFC6325] in the case of conflicts. 141 Section 2 is the ESADI protocol overview. Section 3 specifies ESADI 142 DRB state. Section 4 discusses the processing of ESADI PDUs. Section 143 5 describes the ESADI-LSP contents. 145 1.2 Terminology 147 This document uses the acronyms defined in [RFC6325] and the 148 following phrase: 150 LSP number zero - A Link State PDU with fragment number equal to 151 zero. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. ESADI Protocol Overview 159 ESADI is a VLAN scoped way that RBridges can announce and learn end 160 station addresses rapidly and securely. An RBridge that is 161 announcing itself as connected to one or more VLANs (usually because 162 it is an Appointed Forwarder for those VLANs) and participates in the 163 ESADI protocol is called an ESADI RBridge. 165 ESADI is a separate protocol from the TRILL IS-IS implemented by all 166 RBridges in a campus. There is a separate ESADI instance for each 167 VLAN. In essence, for each VLAN, there is a modified instance of the 168 IS-IS reliable flooding mechanism in which ESADI RBridges may choose 169 to participate. (These are not the instances being specified in 170 [MultiInstance].) It is an implementation decision how independent 171 the implementations of multiple ESADI instances at an RBridge are. 172 For example, the ESADI link state could be in a single database with 173 a field in each record indicating the VLAN to which it applies or 174 could be a separate database per VLAN. But the update processes 175 operate separately for each ESADI instance. 177 After the TRILL header, ESADI frames have an inner Ethernet header 178 with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All- 179 ESADI-RBridges"), an Inner.VLAN tag specifying the VLAN of interest, 180 and the "L2-IS-IS" Ethertype followed by the ESADI payload as shown 181 in Figure 1. For more detail see Section 4.2.5 in the TRILL base 182 protocol specification [RFC6325]. 184 TRILL ESADI frame Structure 186 +--------------------------------+ 187 | Link Header | 188 +--------------------------------+ 189 | TRILL Data Header | 190 +--------------------------------+ 191 | Inner Ethernet Header | 192 +--------------------------------+ 193 | ESADI Payload | 194 +--------------------------------+ 195 | Link Trailer | 196 +--------------------------------+ 198 Figure 1 200 All transit RBridges forward ESADI frames as if they were ordinary 201 multicast TRILL Data frames. Because of this forwarding, it appears 202 to an instance of the ESADI protocol at an RBridge that it is 203 directly connected by a multi-access virtual link to all other 204 RBridges in the campus running ESADI for that VLAN. No "routing" 205 computation or routing decisions ever have to be performed by ESADI. 206 An ESADI RBridge merely transmits the ESADI frames it originates on 207 this virtual link as described for any multicast frame in [RFC6325] 208 using any distribution tree that it might use for a normal TRILL Data 209 frame. RBridges that do not implement the ESADI protocol, do not have 210 it enabled, or are not participating for the Inner.VLAN of an ESADI 211 frame do not decapsulate or locally process any TRILL ESADI frames 212 they receive. Thus the ESADI frames are transparently tunneled 213 through transit RBridges. 215 TRILL ESADI frame payloads are structured like IS-IS PDUs, except as 216 indicated below, but are always TRILL encapsulated on the wire as if 217 they were TRILL Data frames. 219 The ESADI instance for VLAN-x at an RBridge RB1 determines who its 220 ESADI potential neighbors are by logically examining the TRILL IS-IS 221 link state database for RBridges that are data and IS-IS reachable 222 from RB1 (see Section 2 of [ClearCorrect]) and are announcing their 223 participation in VLAN-x ESADI. When an RBridge RB2 becomes IS-IS or 224 data unreachable from RB1 or any of the relevant entries for RB2 are 225 purged from the core IS-IS link state database, it is lost as a 226 potential neighbor and also dropped from any ESADI instances. And 227 when RB2 is no longer announcing participation in VLAN-x ESADI, it 228 ceases to be a potential neighbor for the VLAN-x ESADI instance. RB2 229 becomes an actual ESADI adjacency for RB1 when it is a potential 230 neighbor and RB1 holds an ESADI-LSP zero for RB2, all these 231 considerations being VLAN scoped. Because of these mechanisms, there 232 are no "Hellos" sent in ESADI. 234 The information distributed by the ESADI protocol is a list of local 235 end station MAC addresses connected to the originating RBridge and, 236 for each such address, a one octet unsigned "confidence" rating in 237 the range 0-254 (see Section 5.2). It is entirely up to the 238 originating RBridge which locally connected MAC addresses it wishes 239 to advertise via ESADI and with what confidence. It MAY advertise 240 all, some, or none of such addresses. Future uses of ESADI may 241 distribute additional types of information. 243 TRILL ESADI-LSPs MUST NOT contain a VLAN ID in their payload. The 244 VLAN ID to which the ESADI data applies is the Inner.VLAN of the 245 TRILL Data frame enclosing the ESADI payload. If a VLAN ID could 246 occur within the payload, it might conflict with the Inner.VLAN and 247 could conflict with any future VLAN mapping scheme that may be 248 adopted [VLANmapping]. If a VLAN ID field within an ESADI-LSP PDU 249 does include a VLAN ID, its contents is ignored. 251 (In the future, TRILL may be extended to provide more fine-grained 252 labeling of data and ports. If so, it is expected that ESADI will be 253 extended by allowing such labeling of ESADI frames, in addition to 254 the current Inner.VLAN labeling. As with this specification, it would 255 generally be prohibited for such fine-grained labeling information to 256 appear inside such extended ESADI frame payloads.) 258 3. ESADI DRB State 260 Generally speaking, the DRB state on an ESADI link operate similarly 261 to a TRILL IS-IS broadcast link with the following exception: 263 In the ESADI-DRB election at RB1 on an ESADI link, comparing with 264 [RFC6327], the candidates are the local ESADI instance for VLAN-x and 265 all remote ESADI instances at RBridges that (1) are data and IS-IS 266 reachable from RB1 [ClearCorrect], (2) are announcing in their TRILL 267 IS-IS LSP that they are participating in ESADI for VLAN-x, and (3) 268 for which RB1 is holding an ESADI-LSP zero with an ESADI Pararmeters 269 APPsub-TLV. The winner is the instance with the highest ESADI 270 Parameter 7-bit priority field with ties broken by System ID, 271 comparing fields as unsigned integers with the larger magnitude 272 considered higher priority. In particular "SNPA/MAC address" is not 273 considered and there is no "Port ID". 275 Because ESADI does no routing, the ESADI-DRB does not create a 276 pseudo-node. 278 4. ESADI PDU processing 280 VLAN-x ESADI neighbors are usually not connected directly by a 281 physical link, but are always logically connected by a virtual link. 282 There could be hundreds of ESADI RBridges on the virtual link. There 283 are only EASDI-LSP, EASDI-CSNP and EASDI-PSNP PDUs used in ESADI. In 284 particular, there are no Hello or MTU PDUs because ESADI does not 285 build a topology and does not do any routing. 287 In Layer 3 IS-IS, PDU multicasting is normally on a local link and no 288 effort is made to optimize to unicast because under the original 289 conditions when IS-IS was designed (commonly a piece of multi-access 290 Ethernet cable) any frame made the entire link busy for that frame 291 time. But in ESADI what appears to be a simple multi-access link is 292 generally a set of multi-hop distribution trees that may or may not 293 be pruned. Thus, transmitting a multicast frame on such a tree 294 imposes a greater load than transmitting a unicast frame. This load 295 may be justified if there are likely to be multiple listeners but may 296 not be justified if there is only one recipient of interest. For this 297 reason, under some circumstances, ESADI PDUs MAY be TRILL unicast. 299 Section 4.1 describes the sending of ESADI PDUs. Section 4.2 covers 300 the receipt of ESADI PDUs. 302 4.1 Sending of ESASI PDUs 304 The MTU available to instances of ESADI is at least 24 bytes less 305 than that available to TRILL IS-IS because of the additional fields 306 required (2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 307 6(Innter.MacSA) + 4(Inner.VLAN)). Thus the inner ESADI payload, 308 starting with the Intradomain Routeing Protocol Discriminator, MUST 309 NOT exceed Sz minus 24; however, if a larger payload is received, it 310 is processed normally. 312 Once an ESADI instance is operationally up, it multicasts it self- 313 originated LSP number zero on the virtual link to announce its ESADI 314 parameters. When the other ESADI instances receive the LSP number 315 zero and find a new neighbor, their self-originated LSP fragments are 316 scheduled to be sent and MAY be unicast to that neighbor. If all the 317 other ESADI instances send their self-originated LSPs immediately, 318 there may be a surge of traffic to that new neighbor. So the other 319 ESADI instances should wait an interval time before sending the LSP 320 to a new neighbor. The interval time value is up to the device 321 implementation. One suggestion is that the interval time can be 322 assigned a random value with a range based on the ESADI priority when 323 implementation. 325 If the ESADI instance is DRB, it multicasts an ESADI-CSNP 326 periodically to keep the Link State Database synchronized among its 327 neighbors on the virtual link. After receiving an ESADI-PSNP PDU, the 328 DRB will multicast the LSPs requested by the PSNP on the virtual 329 link. 331 For robustness, if an ESADI instance has two or more ESADI neighbors 332 and is not DRB and it receives no ESADI-CSNP PDUs for at least the 333 CSNP Time (see Section 5.1) of the DRB, it MAY transmit an ESADI- 334 CSNP. 336 In the case of receiving an ESADI-LSP with a smaller sequence number 337 than the copy stored in local EASDI Link State Database, the local 338 ESADI instance will also schedule to transmit the stored copy and MAY 339 unicast it to the sender. 341 The format of a unicast ESADI frame is the format of TRILL ESADI 342 frame, in section 4.2 in [RFC6325], except that, in the TRILL header, 343 the M bit is set to zero and the Egress Nickname is the nickname of 344 the destination RBridge. 346 4.2 Receipt of ESADI PDUs 348 Because ESADI adjacency is in terms of System ID, all PDU acceptance 349 tests that check that the PDU is from an adjacent system check that 350 the System ID is that of an ESADI neighbor and do not check the 351 source SNPA/MAC. 353 Because all ESADI instance for VLAN-x are adjacent, when RB1 receives 354 an ESADI-CSNP from RB2 and detects that it has ESADI-LSPs that RB1 is 355 missing, it sets the transmission flag only for its own EASDI-LSPs 356 that RB1 is missing. Missing EASDI-LSPs originated by other ESADI 357 instances will be detected by those other instances. 359 When receiving an ESADI-PSNP PDU, if the local ESADI instance is DRB, 360 ESADI-LSP PDU requested by the ESADI-PSNP will be multicast on the 361 virtual link. 363 5. ESADI-LSP Contents 365 The only PDUs used in ESADI are the Level 1 ESADI-LSP, ESADI-CSNP, 366 and ESADI-PSNP PDUs. The content of an ESADI-LSP consists of zero or 367 more MAC Reachability TLVs, optionally an Authentication TLV, and 368 exactly one ESADI parameter APPsub-TLV in ESADI-LSP zero. This 369 section specifies the format for ESADI parameter data APPsub-TLV and 370 gives the reference for the ESADI MAC Reachability TLV. In the 371 future, there may be other TLVs or sub-TLVs carried in EASDAI-LSPs. 373 ESADI-LSP number zero MUST NOT exceed 1470 minus 24 bytes in length 374 (1446 bytes) but if received longer, it is still processed normally. 376 5.1 ESADI Parameter Data 378 The figure below presents the format of the ESADI parameter data. 379 This APPsub-TLV MUST be included in a TRILL GENAPP TLV in ESADI-LSP 380 number zero. If it is missing, priority is assumed to be zero and 381 CSNP time 40. If there is more than one occurrnce, the first 382 occurrence will be used. 384 +-+-+-+-+-+-+-+-+ 385 | Type | (1 byte) 386 +-+-+-+-+-+-+-+-+ 387 | Length | (1 byte) 388 +-+-+-+-+-+-+-+-+ 389 |R| Priority | (1 byte) 390 +-+-+-+-+-+-+-+-+ 391 | CSNP Time | (1 byte 392 +-+-+-+-+-+-+-+-+ 393 | Reserved for expansion (variable) 394 +-+-+-+-... 396 Type: set to ESADI-PARAM subTLV (TRILL APPsub-TLV type 1). 398 Length: Set to 2 to 255. 400 R: A reserved bit that MUST be sent as zero and ignored on receipt. 402 Priority: The Priority field gives the ESADI instance's priority for 403 being DRB on the TRILL ESADI virtual link for the VLAN in which 404 the PDU containing the parameter data was sent. It is an unsigned 405 seven-bit integer with larger magnitude indication higher 406 priority. It defaults to 0x40. 408 CSNP Time: An unsigned byte that give the amount of time in seconds 409 during which the originating RBridge, if it is DRB on the ESADI 410 link, will send at least 3 EASDI-CSNP PDUs. It defaults to 30 411 seconds. 413 Reserved for future expansion: Future versions of the ESADI 414 Parameters APPsub-TLV may have additional information. A receiving 415 ESADI RBridge ignores any additional data here unless it 416 implements such future expansion(s). 418 5.2 MAC Reachability TLV 420 The primary information in TRILL ESADI-LSP PDUs consists of MAC 421 Reachability (MAC-RI) TLVs as specified in [RFC6165]. These TLVs 422 contain one or more unicast MAC addresses of end stations that are 423 both on a port and in a VLAN for which the originating RBridge is 424 appointed forwarder, along with the one octet unsigned Confidence in 425 this information with a value in the range 0-254. If such a TLV is 426 received with a confidence of 255, it is treated as if the confidence 427 was 254. 429 To avoid conflict with the Inner.VLAN ID, the TLVs in TRILL ESADI 430 PDUs, including the MAC-RI TLV, MUST NOT contain the VLAN ID. If a 431 VLAN-ID is present in the MAC-RI TLV, it is ignored. The VLAN to 432 which the ESADI-LSP applies is indicated only by the Inner.VLAN tag 433 in the encapsulated TRILL ESADI frame. 435 6. IANA Considerations 437 IANA allocation considerations are given below. 439 6.1 ESADI Participation Flag 441 IANA is requested to allocate an "ESADI Participation" bit in the 442 Interested VLANs and Spanning Tree Roots sub-TLV [RFC6326]. (bit 2 in 443 the Interested VLANs field recommended) If this bit is a one, it 444 indicates that the originating RBridge is participating in ESADI for 445 the indicated VLAN or VLANs. 447 6.2 TRILL GENAPP TLV 449 IANA is requested to allocate an IS-IS Application Identifier under 450 the Generic Information TLV (#251) for TRILL [RFCgenapp] and to 451 create a subregistry in the TRILL Parameters Registry for "TRILL 452 APPsub-TLVs under IS-IS TLV #251 Application Identifier #TBD". The 453 initial contents of this subregistry are as follows: 455 Type Name Reference 456 ------ -------- ----------- 457 0 Reserved 458 1 ESADI-PARAM 459 2-254 Available 460 255 Reserved 462 TRILL APPsub-TLV Types 2 through 254 are available for allocation by 463 Standard Action, as modified by [RFC4020]. The standards track RFC 464 causing such an allocation will also include a discussion of security 465 issues and of the rate of change of the information being advertised. 466 TRILL APPsub-TLVs MUST NOT alter basic TRILL IS-IS protocol operation 467 including the establishment of IS-IS adjacencies, the update process, 468 and the decision process for TRILL IS-IS [IS-IS] [RFC1195] [RFC6327]. 469 The TRILL Generic Information TLV MUST NOT be used in TRILL IS-IS 470 instance zero. 472 The V, I, D, and S flags in the initial flags byte of a TRILL Generic 473 Information TLV have the meanings specified in [RFCgenapp] but are 474 not currently used as TRILL operates as a Level 1 IS-IS area and no 475 semantics is hereby assigned to the inclusion of an IPv4 and/or IPv6 476 address via the I and V flags. Thus these flags MUST be zero; 477 however, use of multi-level IS-IS is an obvious extension for TRILL 478 [MultiLevel] and future IETF Standards Actions may update or obsolete 479 this specification to provide for the use of any or all of these 480 flags in the TRILL GENAPP TLV. 482 The ESADI Parameters information, for which APPsub-TLV 1 is hereby 483 assigned, is compact and slow changing (see Section 5.1). 485 For Security Considerations related to ESADI and the ESADI parameters 486 APPsub-TLV, see Section 7. 488 7. Security Considerations 490 For general TRILL Security Considerations, see [RFC6325]. 492 More TBD 494 8. References 496 Normative and informative references for this document are below. 498 8.1 Normative references 500 [IS-IS] - International Organization for Standardization, 501 "Intermediate system to Intermediate system intra-domain 502 routeing information exchange protocol for use in conjunction 503 with the protocol for providing the connectionless-mode Network 504 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 505 2002. 507 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 508 dual environments", RFC 1195, December 1990. 510 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 514 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 516 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 517 Layer-2 Systems", RFC 6165, April 2011. 519 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 520 Ghanwani, "Routing Bridges (RBridges): Base Protocol 521 Specification", RFC 6325, July 2011. 523 [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 524 Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) 525 Use of IS-IS", RFC 6326, July 2011. 527 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 528 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 529 6327, July 2011. 531 [RFCgenapp] - Ginsberg, L., S. Previdi, M. Shand, "Advertising 532 Generic Information in IS-IS", draft-ietf-isis-genapp-04.txt, 533 in RFC Editor's queue. 535 [ClearCorrect] - draft-ietf-trill-clear-correct, work in progress. 537 8.2 Informative References 539 [802.1X] - IEEE 802.1, "IEEE Standard for Local and metropolitan area 540 networks / Port-Based Network Access Control", IEEE Std 541 802.1X-2010, 5 February 2010. 543 [MultiInstance] - Previdi, S., L. Ginsberg, M. Shand, A. Roy, D. 544 Ward, draft-ietf-isis-mi, work in progress. 546 [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in 547 progress. 549 [RFC3748] - Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 550 Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 551 3748, June 2004. 553 [VLANmapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, 554 and D. Eastlake, "RBridges: Campus VLAN and Priority Regions", 555 draft-ietf-trill-rbridge-vlan-mapping, work in progress. 557 Authors' Addresses 559 Hongjun Zhai 560 ZTE Corporation 561 68 Zijinghua Road 562 Nanjing 200012 China 564 Phone: +86-25-52877345 565 Email: zhai.hongjun@zte.com.cn 567 Fangwei Hu 568 ZTE Corporation 569 889 Bibo Road 570 Shanghai 201203 China 572 Phone: +86-21-68896273 573 Email: hu.fangwei@zte.com.cn 575 Radia Perlman 576 Intel Labs 577 2200 Mission College Blvd. 578 Santa Clara, CA 95054-1549 USA 580 Phone: +1-408-765-8080 581 Email: Radia@alum.mit.edu 583 Donald Eastlake 584 Huawei R&D USA 585 155 Beaver Street 586 Milford, MA 01757 USA 588 Phone: +1-508-333-2270 589 Email: d3e3e3@gmail.com 591 Copyright and IPR Provisions 593 Copyright (c) 2012 IETF Trust and the persons identified as the 594 document authors. All rights reserved. 596 This document is subject to BCP 78 and the IETF Trust's Legal 597 Provisions Relating to IETF Documents 598 (http://trustee.ietf.org/license-info) in effect on the date of 599 publication of this document. Please review these documents 600 carefully, as they describe your rights and restrictions with respect 601 to this document. Code Components extracted from this document must 602 include Simplified BSD License text as described in Section 4.e of 603 the Trust Legal Provisions and are provided without warranty as 604 described in the Simplified BSD License. The definitive version of 605 an IETF Document is that published by, or under the auspices of, the 606 IETF. Versions of IETF Documents that are published by third parties, 607 including those that are translated into other languages, should not 608 be considered to be definitive versions of IETF Documents. The 609 definitive version of these Legal Provisions is that published by, or 610 under the auspices of, the IETF. Versions of these Legal Provisions 611 that are published by third parties, including those that are 612 translated into other languages, should not be considered to be 613 definitive versions of these Legal Provisions. For the avoidance of 614 doubt, each Contributor to the IETF Standards Process licenses each 615 Contribution that he or she makes as part of the IETF Standards 616 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 617 language to the contrary, or terms, conditions or rights that differ 618 from or are inconsistent with the rights and licenses granted under 619 RFC 5378, shall have any effect and shall be null and void, whether 620 published or posted by such Contributor, or included with or in such 621 Contribution.