idnits 2.17.1 draft-hu-trill-pseudonode-nickname-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3718 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) -- Looks like a reference, but probably isn't: '6325' on line 110 -- Looks like a reference, but probably isn't: '6439' on line 110 == Missing Reference: 'RBChannel' is mentioned on line 288, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-trill-cmt-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group H. Zhai 3 Internet-Draft ZTE Corperation 4 Intended status: Standards Track T. Senevirathne 5 Expires: August 18, 2014 Cisco Systems 6 R. Perlman 7 Intel Labs 8 D. Eastlake 3rd 9 M. Zhang 10 Huawei Technologies 11 February 14, 2014 13 RBridge: Pseudo-Nickname 14 draft-hu-trill-pseudonode-nickname-06 16 Abstract 18 The IETF TRILL (Transparent Interconnection of Lots of Links) 19 protocol provides loop free connectivity to Local Area Network (LAN) 20 via choice of an Appoint Forwarder (AF) for a set of VLANs and to end 21 node via point-to-point link. The active-active access, as an 22 extension access of legacy network or end-device to TRILL campus has 23 not been specified. This document gives the concept of Virtual 24 RBridge(RBv), and based on it, specifies the active-active access of 25 a legacy network or an end node via a switch that multi-homes to 26 TRILL campus. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 18, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 4 64 1.2. Contributors . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Concept of Virtual RBridge and Pseudo-nickname . . . . . . . 5 67 3.1. VLAN-x Appointed Forwarder for Member Interfaces in RBv . 6 68 3.2. Announcing Pseudo-Nickname of RBv . . . . . . . . . . . . 6 69 4. Acquision of RBv's Pseudo-nickname . . . . . . . . . . . . . 7 70 4.1. Picking up RBridges for Different RBvs . . . . . . . . . 7 71 5. Distribution Trees for Member RBridges in RBv . . . . . . . . 9 72 6. Frame Processing . . . . . . . . . . . . . . . . . . . . . . 10 73 6.1. Native Frames Ingressing . . . . . . . . . . . . . . . . 10 74 6.2. TRILL Data Frames Egressing . . . . . . . . . . . . . . . 11 75 6.2.1. Unicast TRILL Data Frames . . . . . . . . . . . . . . 11 76 6.2.2. Multi-Destination TRILL Data Frames . . . . . . . . . 12 77 7. Member Link Failure in RBv . . . . . . . . . . . . . . . . . 12 78 7.1. Link Protection for Unicast Frame Egressing . . . . . . . 13 79 8. TLV Extensions for RBv . . . . . . . . . . . . . . . . . . . 14 80 8.1. LAG Membership (LM) Sub-TLV . . . . . . . . . . . . . . . 14 81 8.2. PN-RBv sub-TLV . . . . . . . . . . . . . . . . . . . . . 16 82 9. OAM Frames . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 10. Configuration Consistency . . . . . . . . . . . . . . . . . . 16 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 87 14. Normative References . . . . . . . . . . . . . . . . . . . . 17 88 Appendix A. Rationale for MAC Sharing among Member RBridges . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 The IETF TRILL protocol [RFC6325] provides optimal pair-wise data 94 frame forwarding without configuration, safe forwarding even during 95 periods of temporary loops, and support for multi-pathing of both 96 unicast and multicast traffic. TRILL accomplishes this by using IS- 97 IS [RFC1195] link state routing and encapsulating traffic using a 98 header that includes a hop count. The design supports VLANs and 99 optimization of the distribution of multi-destination frames based on 100 VLANs and IP derived multicast groups. Devices that implement TRILL 101 are called RBridges or TRILL Switchs. 103 In the current TRILL protocol, an end node can be attached to TRILL 104 campus via a point-to-point link or a shared link (such as a Local 105 Area Network (LAN) segment). Although there might be more than one 106 edge RBridge on a shared link, to avoid potential forwarding loops, 107 only one of the RBridges is permitted to provide forwarding service 108 for end station traffic in each VLAN (Virtual LAN). That RBridge is 109 referred as Appointed Forwarder (AF) for that VLAN on the link 110 [6325][6439]. However, in some practical deployments, to increase 111 the access bandwidth and reliability, an end node might be multi- 112 homed to several edge RBridges and treat all of the uplinks as a 113 single Multi-Chassis Link Aggregation (MC-LAG) bundle. In this case, 114 it's required that data traffic within a specific VLAN from this end 115 node can be ingressed and egressed by any of these RBridges 116 simultaneously. These RBridges constitute an Active-Active Edge 117 (AAE) RBridge Group. 119 Since a packet from each end node can be ingressed by any RBridge in 120 the AAE group, a remote RBridge may observe multiple attachment 121 points (i.e., egress RBridges) for this endnode which is identified 122 by its MAC address. This issue is known as the "MAC flip-flopping" 123 issue. In addition to this issue, other issues such as echo of 124 multi-destination frames originated from the MC-LAG or duplication 125 egressing of multi-destination from campus might be encountered by 126 the AAE group (see Section 5 for more details). 128 In this document, the concept of a Virtual RBridge(RBv) group, 129 together with its Pseudo-nickname, is introduced to address the AAE 130 issues in the scope of TRILL. For a member RBridge of such a group, 131 it uses the pseudo-nickname of the RBv, instead of its own nickname, 132 as the ingress RBridge nickname when ingressing frames into TRILL 133 campus. So, in such a AAE Group, even if there are multiple RBridges 134 providing frame forwarding service for an end node simultaneously, 135 the ingress RBridge nickname associated to that end node's MAC 136 address(s) still remains unchanged in remote RBridges' forwarding 137 tables. 139 This document is organized as follows. Section 2 is problem 140 statement, which describes why virtual RBridge and its pseudo- 141 nickname are required. Section 3 gives the concept of virtual 142 RBridge. Section 4 disusses how a RBv gets its pseudo-nickname. 143 Section 5 describes the consideration for pseudo-nickname used in 144 ingressing multi-destination frames. Section 6 covers processing of 145 data frame traffic when considering pseudo-nickname. Section 7 146 dissusses the processing of MC_LAG links failure. And Section 8 147 gives TLV extensions needed by RBv. 149 Familiarity with [RFC6325] is assumed in this document. 151 1.1. Terminology and Acronyms 153 This document uses the acronyms defined in [RFC6325] and the 154 following additional acronym: 156 AF - Appointed Forwarder 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 When used in lower case, these words convey their typical use in 163 common language, and are not to be interpreted as described in 164 [RFC2119]. 166 1.2. Contributors 168 We would like to thank Mingjiang Chen for his contributions to this 169 document. Additionally, we would like to thank Erik Nordmark, Les 170 Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan 171 Pathang, and Jon Hudson for their good questions and comments. 173 2. Overview 175 In order to improve the reliability of connection to a TRILL network, 176 multi-homing technique may be employed by a legacy device which can 177 be a switch or end host. Take Figure 1 as an example, switch SW1 178 multi-homed to the TRILL network by connecting to RB1 and RB2 with 179 respective links. Then the end station S1 can continue to get frame 180 forwarding service from the TRILL network even if one of its up-links 181 (e.g., SW1-RB1) fails. 183 .......................................... 184 : TRILL Network : 185 :+-----+ /\-/\-/\-/\-/\ : 186 +-----| RB1 |-----/ \ : 187 | :+-----+ / \ : 188 +---+ : | / Transit \ +-----+ : 189 S1 o--|SW1| +---+ < RBridges >---| RBx |---o Sx 190 +---+ | : \ Campus / +-----+ : 191 | | :+-----+ \ / : 192 +-----| RB2 |-----\ / : 193 | :+-----+ \/\-/\-/\-/\-/ : 194 | : | : 195 S2 o----+ : 196 .......................................... 198 Figure 1 Multi-homed to TRILL Network 200 SW1 may treat the two links as a link bundle, so that the two links 201 form active-active load sharing model instead of the previous active- 202 standby model. That is to say, in Figure 1, two RBridges (i.e., RB1 203 and RB2) provides frame forwarding service to S1 simultaneously in a 204 VLAN. As stated previously, simultaneous frame forwarding may result 205 in frame duplication, loops and the flip-flopping of the ingress 206 RBridge associated to the MAC of S1 in remote RBridges' (e.g., RBx) 207 forwarding tables. The flip-flopping in turn causes packet disorder 208 in reverse traffic and worsens the traffic disruption. Therefore, 209 the concept of Virtual RBridge, together with its nickname, is 210 introduced in the following section to fix these issues. 212 3. Concept of Virtual RBridge and Pseudo-nickname 214 A Virtual RBridge (RBv) represents a group of different end station 215 service ports on different edge RBridges. After joining RBv, such a 216 RBridge port is called a member port of RBv, and such a RBridge 217 becomes a member RBridge of RBv. An RBv is identified by its virtual 218 nickname in TRILL campus, and this nickname is also referred to as 219 pseudo-nickname in this document. 221 After joining a RBv, a member RBridge will announce its connection to 222 RBv by including the information of that RBv, e.g., the pseudo- 223 nickname of RBv, in its self-originated LSP. From such LSPs, other 224 RBridges that are not members of the RBv believe those member 225 RBridges are connected to RBv. 227 When a native frame from an end station S1 is received from such a 228 port, the member RBridge encapsulates the frame with the RBv's 229 nickname, instead of its own nickname, as the ingress nickname. When 230 the destination RBridges receive and de-capsulate this frame, they 231 will learn that S1 is reachable through RBv. 233 For a member RBridge, it MUST move out of a RBv and clear the RBv's 234 information from its self-originated LSPs when it loses all of its 235 member ports of the RBv, due to port failure, configuration, etc. 237 NOTE1: In the multi-homing scenario of same a RBv, it is RECOMMENDED 238 that all devices multi-homed to that RBv SHOULD have operational 239 links to all the member RBridges of that RBv unless one or more of 240 the links failed or administratively down. 242 3.1. VLAN-x Appointed Forwarder for Member Interfaces in RBv 244 Since member RBridges in RBv cannot see each others' Hellos on their 245 member ports in the multi-homing scenario, then each RBridge becomes 246 Designated RBridge (DRB) for that port and appoints itself as AF for 247 all VLANs. 249 This extended AF framework allows: 251 o Detection and protection against mis-configuration at the edge, 252 e.g., on the device SW1 the two interfaces are not configured as 253 multi-homing then RB1 and RB2 work in an unexpected active-standby 254 mode rather than expected active-active mode for S1 or 256 o Avoidance of loops in the event that S1 and S2 were connected by a 257 native Ethernet Link. In this event, RB1's Hellos originated on 258 link RB1-SW1 will be forwarded by S1 through the Ethernet Link to 259 S2 then received by RB2, and vice versa. Therefore, RB1 and RB2 260 work in an active-standby mode for S1 (or S2) in any VLAN to avoid 261 potential forwarding loops. 263 3.2. Announcing Pseudo-Nickname of RBv 265 Each member RBridge advertises the RBv's pseudo-nickname using the 266 nickname sub-TLV [rfc6326bis], along with its regular nickname(s), in 267 its LSPs. For a member RBridge, when its last member port is 268 disconnected to RBv, it MUST leave from RBv and clear RBv's pseudo- 269 nickname from its update LSPs. 271 RBv's pseudo-nickname is ignored when determining the distribution 272 tree root for the campus. The tree root priority of RBv's nickname 273 SHOULD be set to 0, and this nickname SHOULD NOT be listed in the "s" 274 nicknames by the RBridge holding the highest priority tree root 275 nickname. 277 4. Acquision of RBv's Pseudo-nickname 279 In active-active connection scenario, a device is typically connected 280 to multiple edge RBridges via a link bundle. From the perspective of 281 the edge RBridges, the device can be identified by a globally unique 282 identifier; and this identifier is called Link Aggregation Group 283 Identifier (LAG-ID) in this document. 285 For an edge RBridge, if it has one or more operational ports through 286 which a device multi-homed to it, it MUST announce that LAG-ID of the 287 device to all other edge RBridges via RBridge Channel messages 288 [RBChannel]. Based on the LAG-IDs received from other edge RBridges, 289 edge RBridges can pick up, from TRILL campus, all the edge RBridges 290 that can join same a RBv(See Section Section 4.1 for more details) 291 and elect one of them as the Designated RBridge (DRB) for that RBv. 292 That DRB is responsible for appointing an available pseudo-nickname 293 for that RBv. 295 4.1. Picking up RBridges for Different RBvs 297 --------------------- 298 / \ 299 | TRILL Campus | 300 \ / 301 ----------------------- 302 | | | | 303 +-------+ | | +--------+ 304 | | | | 305 +-------+ +-------+ +-------+ +-------+ 306 | RB1 | | RB2 | | RB3 | | RB4 | 307 +-------+ +-------+ +-------+ +-------+ 308 | | | | | | | | | | 309 | +--|-------+ | +-------|-+ | +-------|--+ | 310 | | +--------+ | | | | | | | 311 | | +---------|-|-|-------+ | +-------+ | | 312 LAG1->(| | |) LAG2->(| | |) LAG3->(| |) LAG4->(| |) 313 +-------+ +-------+ +-------+ +-------+ 314 | CE1 | | CE2 | | CE3 | | CE4 | 315 +-------+ +-------+ +-------+ +-------+ 317 Figure 2 Different LAGs to TRILL Campus 319 For each edge RBridge with available multi-homed devices connected, 320 it MUST announce a list of LAG-IDs of all of those devices to all 321 other edge RBridges via RBridge Channel message (See Section 8.1 for 322 more details). Take Figure 2 as an example, RB1 and RB2 announce 323 {LAG1, LAG2} in their lists respectively; RB3 announces {LAG1, LAG2, 324 LAG3, LAG4}; and RB4 announces {LAG3, LAG4}, respectively. 326 Based on the LAG-IDs contained in these lists, each RBridge can know 327 which set of RBridges each LAG is multi-homed to. For example, all 328 the 4 RBridges know the information as follows: 330 LAG-ID OE-flag Set of multi-homed RBridges 331 ------ ------- --------------------------- 332 LAG1 0 {RB1, RB2, RB3} 333 LAG2 0 {RB1, RB2, RB3} 334 LAG3 1 {RB3, RB4} 335 LAG4 0 {RB3, RB4} 337 In the above table, there might be some LAGs that multi-homes only to 338 one single RBridge due to mis-configuration or link failure, etc. 339 Those LAGs are considered as invalid entries. Then each of the 340 relative edge RBridges performs the following approach to pick up 341 which valid LAGs can be served by same a RBv. 343 Step 1: Take all the valid LAGs that have their OE-flags (Occupying 344 Exclusively a RBv) set 1 out of the table and create a RBv per such 345 LAG. 347 Step 2: Sort the left valid LAGs in the table in descending order 348 based on the mumber of RBriges in their associated set of multi-homed 349 RBridges. 351 Step 3: Take the valid LAG (say LAG_i) with the maximum set of 352 RBridges, say S_i, out of the table and create a new RBv (Say RBv_i) 353 for it. 355 Step 4: Walk through the remainder valid LAGs in the table one by 356 one, pick up all the valid LAGs that their sets of multi-homed 357 RBridges contain the same RBridges as that of LAG_i and take the LAGs 358 out of the table. Then appoint RBv_i as those LAGs' servicing RBv. 360 Step 5: Repeat Step 3-4 for the left LAGs in the table. 362 For the example given in Figure 2, after performing the above steps, 363 all the 4 RBridges know that LAG3 is served by a RBv, say RBv1, which 364 has RB3 and RB4 as member RBrdigs; LAG1 and LAG2 are served by 365 another RBv, say RBv2, which has RB1, RB2 and RB3 as member RBridges; 366 and LAG4 is served by RBv3, which has RB3 and RB4 as member RBrdigs, 367 shown as follows: 369 RBv Serving LAGs Member RBridges 370 ----- ------------- --------------- 371 RBv1 {LAG3} {RB3, RB4} 372 RBv2 {LAG1, LAG2} {RB1, RB2, RB3} 373 RBv3 {LAG4} {RB3, RB4} 375 In each RBv, one of its member RBridges is elected as DRB. The 376 winner is the member RBridge with the maximum device nickname in this 377 RBv. Then this DRB picks up an available nickname as this RBv's 378 pseudo-nickname and announce it to all other member RBridges in this 379 RBv via RBridge Channel message (Refer Section 8.3 for more details). 381 If possible, the DRB SHOULD attempt to reuse the RBv's previous 382 pseudo-nickname to avoid traffic disruption caused by pseudo-nickname 383 changing. If there is no such a previous nickname available, the DRB 384 will acquire a new available nickname from TRILL campus and announce 385 it as the RBv's pseudo-nickname among the RBv's member RBridges. 387 5. Distribution Trees for Member RBridges in RBv 389 In TRILL, RBridges use distribution trees to forward multi- 390 destination frames. In the TRILL header of the multi-destination 391 frames, the ingress nickname identifies the ingress RBridge and the 392 egress nickname specifies the root of the chosen distribution tree. 393 After receiving a multi-destination TRILL data frame, RBn performs 394 Reverse Path Forwarding (RPF) check on the multi-destination frame to 395 avoid temporary multicast loops during topology changes. 397 RPF specifies that a multi-destination TRILL data frame ingressed by 398 an RBridge and forwarded on a distribution tree can only be received 399 by RBn on an expected port. If the frame is not received from that 400 port, it MUST be dropped. 402 However, member RBridges use RBv's pseudo-nickname other than their 403 own nicknames as the ingress nickname when they forward unicast or 404 non-unicast native frames. Therefore, when these TRILL data frames 405 arrive at RBn, they will be treated as frames ingressed by the same 406 RBridge, i.e., RBv. If they are multi-destination frames and the 407 same distribution tree is chosen by different member RBridges to 408 forward these frames, they may travel on the tree and arrive at RBn 409 on different ports. Then the RPF check is violated, and some of the 410 frames reaching the RBridge on unexpected ports will be dropped by 411 RBn. 413 [CMT] proposes to assign different distribution trees for each member 414 RBridge to fix the above RPF check issue, and makes use of the 415 Affinity sub-TLV defined in [rfc6326bis] to achieve this kind of 416 assignment. When the distribution tree Tx is assigned to member 417 RBridge RBn in a RBv, RBn is called Tx's Designated Forwarder and Tx 418 is called the Assigned Tree of RBn in the scope of this RBv. 420 This document assumes the approach proposed in [CMT] is supported by 421 member RBridges of RBv. 423 To avoid duplication traffic being egressed through RBv to a multi- 424 homing end-device, multi-destination TRILL traffic arriving at member 425 RBridges of RBv on a tree (say Tx), only the Tx's Designated 426 Forwarder is allowed to egress it to the device. 428 When RBn receives a native frame on its member ports of RBv, and 429 decides to ingress it as a multi-deistinaiton frame(for exampe, the 430 native frame is a broadcast frame or the destination is unknown), RBn 431 can only choose one of its Assigned Trees to distribute the TRILL- 432 encapsulated frame. 434 Since different member RBridge has different Assigned Trees and acts 435 as Designated Forwarder on different trees in the socpe of its RBv, 436 the multi-destination frames ingressed from a MC_LAG by one member 437 RBridge will not be egressed back to the MC_LAG by another member 438 RBridges in the scope. That is to say, no echo of multi-destination 439 traffic occurs in RBv. 441 When a member RBridge joins in or leaves from a virtual RBridge 442 group, the assignment of distribution trees may change. That change 443 has been discussed in [CMT] and is beyond the scope of this document. 445 6. Frame Processing 447 Although, there are five types of Layer 2 frames in [RFC6325], e.g., 448 native frame, TRILL data frame, TRILL control frames, etc., pseudo- 449 nickname of RBv is only used for native frame and TRILL data frame in 450 this specification. 452 6.1. Native Frames Ingressing 454 When RB1 receives a native frame on one of its valid member ports of 455 RBv, it uses the pseudo-nickname of RBv, instead of its own nickname, 456 as ingress nickname, if it is the appointed forwarder for the VLAN of 457 the frame on the port. If the frame is not received on a member 458 port, RB1 MUST NOT use RBv's pseudo-nickname as ingress nickname when 459 doing TRILL-encapsulation on the frame. Otherwise, the reverse 460 traffic may be forwarded to another member RBridge that does not 461 connect to the link containing the destination, which may cause the 462 traffic disruption. 464 If the above native frame is ingressed by RB1 as a multi-destination 465 TRILL data frame, e.g., its destination is unknown to RB1 or it is 466 non-unicast frame, RB1 can only choose one of its assigned 467 distribution trees in the RBv to distribute the TRILL-encapsulated 468 frame [CMT]. If not so, the multi-destination TRILL data frame will 469 fail RPF check on another RBridge and be dropped. 471 Furthermore, for such a frame, its source MAC address information ( { 472 VLAN, Outer.MacSA, port } ) is learned by default if its source 473 address is unicast. Then the learned information is shared with 474 other member RBridges of the RBv (See Appendix A for more details for 475 the information sharing). 477 6.2. TRILL Data Frames Egressing 479 6.2.1. Unicast TRILL Data Frames 481 When receiving a unicast TRILL data frame, RBn checks the egress 482 nickname in the TRILL header of the frame. If the egress nickname is 483 one of RBn's own nicknames, the frame is processed as defined in in 484 [RFC6325]. 486 If the egress nickname is RBv's pseudo-nickname and RBn is a member 487 RBridge of the RBv, RBn is responsible to learn the source MAC 488 address. If the learned { Inner.MacSA, Inner.VLAN ID, ingress 489 nickname } triplet is a new one or it updates a previously learned 490 one, this triplet SHOULD be shared with other member RBridges of the 491 RBv (See Appendix A for more details for the triplet sharing). 493 Then the frame is de-capsulated to its native form. The Inner.MacDA 494 and Inner.VLAN ID are looked up in RBn's local forwarding address 495 cache, and one of the three following cases occurs: 497 o If the destination end station identified by the Inner.MacDA and 498 Inner.VLAN ID is on a local link to RBv, this frame is egressed 499 onto that link. 501 o Else if RBn can reach the destination through another member 502 RBridge RBk, it tunnels the frame to RBk [ClearCorrect] by re- 503 encapsulating the native frame into a unicast TRILL data frame. 504 RBn uses RBk's own nickname, instead of RBv's pseudo-nickname as 505 the egress nickname for the re-encapsulation, and remains the 506 ingress nickname remains unchanged. If the hop count value of the 507 frame is too small for the frame to reach RBk safely, RBn SHOULD 508 increase that value properly in doing the re-encapsulation. 509 [NOTE: When receiving that re-encapsulated TRILL frame, as the 510 egress nickname of the frame is RBk's own nickname rather than the 511 RBv's pseudo-nickname, RBk will process it as Section 4.6.2.4 in 512 [RFC6325], and will not re-forward it to another RBridge. 514 o Else, RBn does not know how to reach the destination; it sends the 515 native frame out of all its member ports of RBv on which it is 516 appointed forwarder for the Inner.VLAN. 518 6.2.2. Multi-Destination TRILL Data Frames 520 To avoid multiple copies of a multi-destination TRILL data frames in 521 VLAN x are egressed to same a MC_LAG, when receiving such a frame on 522 tree Tx by multiple member RBridges of this MC_LAG, only the 523 Designated Forwarder of Tx in the MC_LAG is permitted to egress the 524 frame to this MC_LAG. 526 That is to say, if RBn is the the Designated Forwarder of Tx in 527 MC_LAGi, a copy of the frame is de-capsulated by RBn into its native 528 form, and sent to MC_LAGi. The { Inner.MacSA, Inner.VLAN ID, ingress 529 nickname } triplet is also learned based on the de-capsulation. If 530 the learned triplet is a new one or updates the previously learned 531 one, it SHOULD be shared among the members RBridges of the virtual 532 RBridge group (See Appendix A for more details for the triplet 533 sharing). 535 7. Member Link Failure in RBv 537 As shown in Figure 3, suppose the link RB2-CE1 fails. Both unicast 538 frames and multi-destination frames cannot be sent from RB2 to CE1. 539 Section 7.1 discusses the failure protection for unicast frames 540 egressing. 542 ------------------ 543 / \ 544 | TRILL Campus | 545 \ / 546 --------------------- 547 | | | 548 +---+ | +----+ 549 | | | 550 +------+ +------+ +------+ 551 | RB1 | | RB2 | | RB3 | 552 o|oooooo|ooo|oooooo|ooo|oooooo|o 553 o +------+ +------+ +------+ o 554 o | | \|/ | | | | o 555 o | +-|-- B --+ +------|-+ | o 556 o | | | /|\ +-------+ | | o 557 oo|o|o|ooooooooo|ooooooooo|o|ooo 558 | | +---------|-------+ | | 559 | | +---------+ | | | 560 (| | |)<--MC_LAG1 (| | |)<--MC_LAG2 561 +-------+ +-------+ 562 | CE1 | | CE2 | 563 +-------+ +-------+ 565 B - Failed Link or Link bundle 567 Figure 3 Member Link Failure in LAG1 569 7.1. Link Protection for Unicast Frame Egressing 571 When the link CE1-RB2 fails, RB2 loses its direct connection to CE1. 572 The MAC entry through the failed link to CE1 is removed from RB2's 573 local forwarding table immediately. Another MAC entry through 574 another member RBridge (say RB1) that has local link to CE1 is 575 installed into RB2's forwarding table only if RB2 is still a member 576 RBridge of RBv. Then when the TRILL data frames to CE1 are delivered 577 to RB2, they can be re-encapsulated (ingress nickname remains 578 unchanged and egress nickname is replaced with RB1's nickname) by RB2 579 and forwarded based on the above installed MAC entry. The member 580 RBridge who receives the redirected frames will egress them to CE1. 582 When the failure recovers, RB2 will be aware that it can reach CE1 by 583 observing CE1's native frames. Then RB2 installs the MAC entry for 584 link CE1-RB2. 586 8. TLV Extensions for RBv 588 8.1. LAG Membership (LM) Sub-TLV 590 We propose to use LM sub-TLV to advertise the state of the RBridges' 591 MC_LAG membership. There are following 3 different events, as 592 follows: 594 o Membership Add 596 o Membership Withdrawal 598 o Membership Refresh 600 +-+-+-+-+-+-+-+-+ 601 | Type= LM | (1 byte) 602 +-+-+-+-+-+-+-+-+ 603 | Length | (1 byte) 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | RBv Nickname | (2 bytes) 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | RESV |OC | (1 byte) 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | LAG-ID (1) | (10 bytes) 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 . . 612 . . 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | LAG-ID (n) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 4 Edge Membership advertisement sub-TLV 619 where each LAG_ID record is of the following form: 621 +-+-+-+-+-+-+-+--+ 622 | RESV |OE| (1 byte) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Virtual Network ID(VNID) | (3 bytes) 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | LAG ID | (6 bytes) 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 o LM (1 byte): Defines the type of Edge Membership sub-TLV. 631 o Length (1 byte): Defines the length of this sub-TLV which should 632 be greater than 3. 634 o RBv Nickname (2 bytes): 2 byte nickname of the RBv. By default, 635 this field is zero. Otherwise, it indicates the pseudo-nickname 636 that the originator of the TLV considers the RBv has used, which 637 providing information for the DRB to reuse the RBv's previous 638 pseudo-nickname. 640 o RESV (6 bits): Transmitted as zero and ignored on receipt. 642 o OE(1 bit): an flag indicating whether the end-device identified by 643 the combination of the VNID and LAG-ID needs to Occupy a RBv 644 exclusively or can share a RBv with other end-devices; 1 for 645 occupying exclusively, and 0 for sharing. By default, it is set 646 to 0. 648 o OC (2 bits): Define the operation code. 650 * 00: Add (LAG-IDs in this sub-TLV are new and will trigger the 651 process of picking up member RBridge for a RBv and the 652 Designated Forwarder election on the relative edge RBridges). 654 * 01: Withdrawal (LAG-IDs in this sub-TLV do not have an active 655 links from the announcing RBridge for RBv, the process of 656 picking up member RBridge for a RBv and Designated Forwarder 657 election MUST be triggered on the relative edge RBridges). 659 * 10: Refresh (LAG-IDs in this sub-TLV are being refreshed and no 660 state change from the perspective of the announcing RBridge). 662 * 11: Reserved and currently unused. 664 o VNID(24 bits): an identifier of an Virtual Network where the end- 665 device populated. By default, this field is set to zero. 667 o LAG-ID (2 bytes): an unsigned positive integer that uniquely 668 identifies an end device multi-homed to the RBv. This ID along 669 with the VNIT is globally meaningful in the scope of the TRILL 670 campus. For convenience, this ID can be one of the MAC addresses 671 of the end-device.. 673 When receiving such a sub-TLV, if the RBridge has no membership for 674 the listed LAGs in the RBv, it ignores the sub-TLV. If it has the 675 membership, receiving such a sub-TLV where the operation code is 00 676 or 01 will triggers it to re-calculate the Designated Forwarder on 677 each tree for the listed LAGs. 679 8.2. PN-RBv sub-TLV 681 The DRB employs PN-RBv sub-TLV to announce the RBv's pseudo-nickname, 682 along with all the LAGs serviced by this RBv, to other relative edge 683 RBridges. 685 The format of this sub-TLV is as follows, where the LAG-ID Record has 686 the same format as the Record of LM Sub-TLV. 688 +-+-+-+-+-+-+-+-+ 689 | Type= PN_RBv | (1 byte) 690 +-+-+-+-+-+-+-+-+ 691 | Length | (1 byte) 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | RBv's Pseudo-Nickname | (2 bytes) 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | RESV | (1 byte) 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | LAG-ID RECORD (1) | (10 bytes) 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 . . 700 . . 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | LAG-ID RECORD (n) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 LAG-ID RECORDs list all the end-devices to which the RBv identified 706 by the pseudo-nickname provides services. 708 After receiving such a sub-TLV, if the receipt RBridge has membership 709 for at least one of the listed LAGs and accepts the DRB membership of 710 the originator of the TLV, it uses the RBv identified by the pseudo- 711 nickname to service the end-devices identified by some of the listed 712 LAGs and multi-homed to it. Otherwise, the received sub-TLV is 713 ignored. 715 9. OAM Frames 717 Attention must be paid when generating the OAM frames. When an OAM 718 frame is generated with the ingress nickname of RBv, the originator 719 RBridge's nickname MUST be included in the OAM message to ensure the 720 response is returned to the originating member of the RBv group. 722 10. Configuration Consistency 724 It is important that VLAN membership of member ports of end switch 725 SW1 is consistent across all of the member ports in the point-point 726 scenario. Any inconsistencies in VLAN membership may result in 727 packet loss or non-shortest paths. 729 Take Figure 1 for example, suppose RB1 configures VLAN1 and VLAN2 for 730 the link SW1-RB1, while RB2 only configures VLAN1 for the SW1-RB2 731 link. Both RB1 and RB2 use the same ingress nickname RBv for all 732 frames originating from S1. Hence, a remote RBridge RBx will learn 733 that MAC addresses from S1 on VLAN2 are originating from RBv. As a 734 result, on the returning path, RBx may deliver VLAN2 traffic to RB2. 735 However, RB2 does not have VLAN2 configured on SW1-RB2 link and hence 736 the frame may be dropped or has to be redirected to RB1 if RB2 knows 737 RB1 can reach S1 in VLAN2. 739 11. IANA Considerations 741 TBD. 743 12. Security Considerations 745 TBD. 747 13. Acknowledgements 749 We would like to thank Mingjiang Chen for his contributions to this 750 document. Additionally, we would like to thank Erik Nordmark, Les 751 Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan 752 Pathang, and Jon Hudson for their good questions and comments. 754 14. Normative References 756 [CMT] Senevirathne, T., Pathangi, J., and J. Hudson, 757 "Coordinated Multicast Trees (CMT)for TRILL", draft-ietf- 758 trill-cmt-00.txt Work in Progress, April 2012. 760 [ClearCorrect] 761 Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and 762 A. Banerjee, "TRILL: Clarifications, Corrections, and 763 Updates", draft-ietf-trill-clear-correct-06.txt In RFC 764 Editting Queue, July 2012. 766 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 767 dual environments", RFC 1195, December 1990. 769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 770 Requirement Levels", BCP 14, RFC 2119, March 1997. 772 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 773 Ghanwani, "Routing Bridges (RBridges): Base Protocol 774 Specification", RFC 6325, July 2011. 776 [rfc6326bis] 777 Eastlake 3rd, D., Banerjee, A., Ghanwani, A., and R. 778 Perlman, "Transparent Interconnection of Lots of Links 779 (TRILL) Use of IS-IS", draft-eastlake-isis- 780 rfc6326bis-07.txt Work in Progress, March 2012. 782 Appendix A. Rationale for MAC Sharing among Member RBridges 784 With the introduction of virtual RBridge, MAC flip-flopping problem 785 in LAN or LAG is resolved. However, in order to forward traffic 786 effectively, member RBridges should share some of their learned MAC 787 addresses with each other. For example, see Figure 5 shown below. 789 ........................................... 790 : TRILL Network : 791 ^ : +-----+ /\-/\-/\-/\-/\ : 792 +-----| RB1 |-----/ \ : 793 / : +-----+ / \ : 794 / : | / Transit \ +-----+ : 795 S1 o RBv : | < RBridges >---| RBx |---o Sx 796 \ : | \ Campus / +-----+ : 797 \ : +-----+ \ / : 798 +-----| RB2 |-----\ / : 799 V : +-----+ \/\-/\-/\-/\-/ : 800 : : 801 ........................................... 803 Figure 5 RBv in LAG scenario 805 Take Figure 5 as an example, the VLAN-x native frames from S1 to Sx 806 will enter TRILL campus via one member RBridge of the RBv (say RB1). 807 RB1 learns the location of S1 in VLAN-x. However, RBx may deliver the 808 reverse traffic to RB2 if it thinks the shortest path to RBv is 809 through RB2. If RB2 has not learned the location of S1 in VLAN-x 810 from the MAC sharing, RB2 has to transmit the reverse traffic to S1 811 as unknown unicast. 813 Thus, the learned MAC addresses of attached end stations on one 814 member RBridge SHOULD be shared with rest of the member RBridges in 815 the same RBv. With these information shared, when RB2 receives 816 reverse frames, it can determine how to forward them to S1. For 817 example, it can redirect them to RB1 if link RB2-S1 fails. 819 Since RBx always delivers the reverse traffic to RBv via RB2, RB2 820 egresses the traffic and learns the location of Sx. But RB1 will not 821 know where Sx is, if RB2 does not share this information with RB1. 822 As a result, RB1 has to treat the traffic from S1 to Sx as traffic 823 with unknown destination and flood it in TRILL, which adds additional 824 forwarding burden on the TRILL network. 826 Therefore, in addition to local attached end station MAC addresses, 827 the learned remote MAC addresses should also be shared among all 828 member RBridges of a RBv. With such information shared, RB1 can 829 treat the traffic to Sx as known destination traffic and unicast it 830 to RBx. 832 The design for above MAC sharing is currently beyond the scope of 833 this document. 835 Authors' Addresses 837 Hongjun Zhai 838 ZTE Corperation 839 68 Zijinghua Road, Yuhuatai District 840 Nanjing, Jiangsu 210012 841 China 843 Phone: +86 25 52877345 844 Email: zhai.hongjun@zte.com.cn 846 Tissa Senevirathne 847 Cisco Systems 848 375 East Tasman Drive 849 San Jose, CA 95134 850 USA 852 Phone: +1-408-853-2291 853 Email: tsenevir@cisco.com 854 Radia Perlman 855 Intel Labs 856 2200 Mission College Blvd 857 Santa Clara, CA 95054-1549 858 USA 860 Phone: +1-408-765-8080 861 Email: Radia@alum.mit.edu 863 Donald Eastlake 3rd 864 Huawei Technologies 865 155 Beaver Street 866 Milford, MA 01757 867 USA 869 Phone: +1-508-333-2270 870 Email: d3e3e3@gmail.com 872 Mingui Zhang 873 Huawei Technologies 874 Huawei Building, No.156 Beiqing Rd. 875 Beijing, Beijing 100095 876 China 878 Email: zhangmingui@huawei.com