idnits 2.17.1 draft-ietf-trill-pseudonode-nickname-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2015) is 3098 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group H. Zhai 3 Internet-Draft JIT 4 Intended Status: Standards Track T. Senevirathne 5 Consultant 6 R. Perlman 7 EMC 8 M. Zhang 9 Y. Li 10 Huawei Technologies 11 Expires: March 28, 2016 September 25, 2015 13 TRILL: Pseudo-Nickname for Active-Active Access 14 draft-ietf-trill-pseudonode-nickname-07.txt 16 Abstract 18 The IETF TRILL (TRansparent Interconnection of Lots of Links) 19 protocol provides support for flow level multi-pathing for both 20 unicast and multi-destination traffic in networks with arbitrary 21 topology. Active-active access at the TRILL edge is the extension of 22 these characteristics to end stations that are multiply connected to 23 a TRILL campus as discussed in RFC 7379. In this document, the edge 24 RBridge (TRILL switch) group providing active-active access to such 25 an end station are represented as a Virtual RBridge. Based on the 26 concept of Virtual RBridge along with its pseudo-nickname, this 27 document specifies a method for TRILL active-active access by such 28 end stations. 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 5 69 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Virtual RBridge and its Pseudo-nickname . . . . . . . . . . . . 8 71 4. Member RBridges Auto-Discovery . . . . . . . . . . . . . . . . 9 72 4.1. Discovering Member RBridge for an RBv . . . . . . . . . . . 9 73 4.2. Selection of Pseudo-nickname for RBv . . . . . . . . . . . 12 74 5. Distribution Trees and Designated Forwarder . . . . . . . . . . 13 75 5.1. Different Trees for Different Member RBridges . . . . . . . 13 76 5.2. Designated Forwarder for Member RBridges . . . . . . . . . 14 77 5.3. Ingress Nickname Filtering . . . . . . . . . . . . . . . . 16 78 6. TRILL Traffic Processing . . . . . . . . . . . . . . . . . . . 17 79 6.1. Native Frames Ingressing . . . . . . . . . . . . . . . . . 17 80 6.2. Egressing TRILL Data Packets . . . . . . . . . . . . . . . 18 81 6.2.1. Unicast TRILL Data Packets . . . . . . . . . . . . . . 18 82 6.2.2. Multi-Destination TRILL Data Packets . . . . . . . . . 19 83 7. MAC Information Synchronization in Edge Group . . . . . . . . . 19 84 8. Member Link Failure in RBv . . . . . . . . . . . . . . . . . . 20 85 8.1. Link Protection for Unicast Frame Egressing . . . . . . . . 21 86 9. TLV Extensions for Edge RBridge Group . . . . . . . . . . . . . 21 87 9.1. PN-LAALP-Membership APPsub-TLV . . . . . . . . . . . . . . 22 88 9.2. PN-RBv APPsub-TLV . . . . . . . . . . . . . . . . . . . . . 23 89 9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs . . . . . . . . . . . 24 90 9.4. LAALP IDs . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 10. OAM Packets . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 11. Configuration Consistency . . . . . . . . . . . . . . . . . . 26 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 95 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 96 15. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 28 97 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 16.1. Normative References . . . . . . . . . . . . . . . . . . . 29 99 16.2. Informative References . . . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 102 1. Introduction 104 The IETF TRILL protocol [RFC6325] provides optimal pair-wise data 105 frame forwarding without configuration, safe forwarding even during 106 periods of temporary loops, and support for multi-pathing of both 107 unicast and multicast traffic. TRILL accomplishes this by using IS-IS 108 [IS-IS] [RFC7176] link state routing and encapsulating traffic using 109 a header that includes a hop count. Devices that implement TRILL are 110 called RBridges or TRILL switches. 112 In the base TRILL protocol, an end node can be attached to the TRILL 113 campus via a point-to-point link or a shared link such as a bridged 114 LAN (Local Area Network). Although there might be more than one edge 115 RBridge on a shared link, to avoid potential forwarding loops, one 116 and only one of the edge RBridges is permitted to provide forwarding 117 service for end station traffic in each VLAN (Virtual LAN). That 118 RBridge is referred to as the Appointed Forwarder (AF) for that VLAN 119 on the link [RFC6325] [RFC6439]. However, in some practical 120 deployments, to increase the access bandwidth and reliability, an end 121 station might be multiply connected to several edge RBridges and all 122 of the uplinks are handled via a Local Active-Active Link Protocol 123 (LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or 124 Distributed Resilient Network Interconnect (DRNI [802.1AX]). In this 125 case, it's required that traffic can be ingressed/egressed into/from 126 the TRILL campus by any of the RBridges for each given VLAN. These 127 RBridges constitutes an Active-Active Edge (AAE) RBridge group. 129 With an LAALP, traffic with the same VLAN and source MAC address but 130 belonging to different flows will frequently be sent to different 131 member RBridges of the AAE group and then ingressed into TRILL 132 campus. When an egress RBridge receives such TRILL data packets 133 ingressed by different RBridges, it learns different VLAN and MAC 134 address to nickname correspondences continuously when decapsulating 135 the packets if it has data plane address learning enabled. This issue 136 is known as the "MAC flip-flopping" issue, which makes most TRILL 137 switches behave badly and causes the returning traffic to reach the 138 destination via different paths resulting in persistent re-ordering 139 of the frames. In addition to this issue, other issues such as 140 duplicate egressing and loop back of multi-destination frames may 141 also disturb an end station multiply connected to the member RBridges 142 of an AAE group [RFC7379]. 144 This document addresses the AAE issues of TRILL by specifying how 145 members of an edge RBridge group can be represented by a Virtual 146 RBridge (RBv) and assigned a pseudo-nickname. A member RBridge of 147 such a group uses a pseudo-nickname, instead of its own nickname, as 148 the ingress RBridge nickname when ingressing frames received on 149 attached LAALP links. Other methods are possible: for example the 150 specification in this document and the specification in [MultiAttach] 151 could be simultaneously deployed for different AAE groups in the same 152 campus. If the method is [MultiAttach] is used, edge TRILL switches 153 need to support the capability indicated by the Capability Flags 154 APPsub-TLV as specified in Section 4.2 of [MultiAttach]. If the 155 method defined in this document is adopted, all TRILL switches need 156 to support the Affinity sub-TLV defined in [RFC7176] and [CMT]. For a 157 TRILL campus that deploys both these AAE methods, TRILL switches are 158 required to support both methods. However, it is desirable to only 159 adopt one method in a TRILL campus so that the operating expense, 160 complexity of troubleshooting, etc, can be reduced. 162 The main body of this document is organized as follows: Section 2 163 gives an overview of the TRILL active-active access issues and the 164 reason that a virtual RBridge (RBv) is used to resolve the issues. 165 Section 3 gives the concept of a virtual RBridge (RBv) and its 166 pseudo-nickname. Section 4 describes how edge RBridges can support an 167 RBv automatically and get a pseudo-nickname for the RBv. Section 5 168 discusses how to protect multi-destination traffic against disruption 169 due to Reverse Forwarding Path (RPF) check failure, duplication, 170 forwarding loops, etc. Section 6 covers the special processing of 171 native frames and TRILL data packets at member RBridges of an RBv 172 (also referred to as an Active-Active Edge (AAE) RBridge group). 173 Section 7 describes the MAC information synchronization among the 174 member RBridges of an RBv. Section 8 discusses protection against 175 downlink failure at a member RBridge; and Section 9 gives the 176 necessary TRILL code points and data structures for a pseudo-nickname 177 AAE RBridge group. 179 1.1. Terminology and Acronyms 181 This document uses the acronyms and terms defined in [RFC6325] and 182 [RFC7379] and the following additional acronyms: 184 AAE - Active-active Edge RBridge group, a group of edge RBridges to 185 which at least one CE is multiply attached with an LAALP. AAE is also 186 referred to as edge group or Virtual RBridge in this document. 188 Campus - A TRILL network consisting of TRILL switches, links, and 189 possibly bridges bounded by end stations and IP routers. For TRILL, 190 there is no "academic" implication in the name "campus". 192 CE - Customer Equipment (end station or bridge). The device can be 193 either physical or virtual equipment. 195 Data Label - VLAN or FGL. 197 DF - Designated Forwarder. 199 DRNI: Distributed Resilient Network Interconnect. A link aggregation 200 specified in [802.1AX] that can provide an LAALP between from 1 to 3 201 CEs and 2 or 3 RBridges. 203 E-L1FS - Extended Level 1 Flooding Scope [RFC7356]. 205 FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained 206 Label [RFC7172]. 208 LAALP - Local Active-Active Link Protocol [RFC7379] such as MC-LAG or 209 DRNI. 211 MC-LAG: Multi-Chassis LAG. Proprietary extensions of Link Aggregation 212 [802.1AX] that can provide an LAALP between one CE and 2 or more 213 RBridges. 215 OE flag - A flag used by the member RBridge of an LAALP to tell other 216 edge RBridges whether it is willing to share an RBv with other LAALPs 217 if they multiply attach to the same set of edge RBridges as it. When 218 this flag for an LAALP is 1, it means that the LAALP needs to be 219 served by an RBv by itself and is not willing to share, that is, it 220 should Occupy an RBv Exclusively (OE). 222 RBv - virtual RBridge, an alias for active-active edge RBridge group 223 in this document. 225 vDRB - The Designated RBridge in an RBv. It is responsible for 226 deciding the pseudo-nickname for the RBv. 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC 2119 [RFC2119]. 232 2. Overview 234 To minimize impact during failures and maximize available access 235 bandwidth, Customer Equipment (referred to as CE in this document) 236 may be multiply connected to TRILL campus via multiple edge 237 RBridges. 239 Figure 1 shows such a typical deployment scenario, where CE1 attaches 240 to RB1, RB2, ... RBk and treats all of the uplinks as an LAALP 241 bundle. Then RB1, RB2, ... RBk constitute an Active-active Edge (AAE) 242 RBridge group for CE1 in this LAALP. Even if a member RBridge or an 243 uplink fails, CE1 will still get frame forwarding service from the 244 TRILL campus if there are still member RBridges and uplinks available 245 in the AAE group. Furthermore, CE1 can make flow-based load balancing 246 across the available member links of the LAALP bundle in the AAE 247 group when it communicates with other CEs across the TRILL campus 248 [RFC7379]. 250 ---------------------- 251 | | 252 | TRILL Campus | 253 | | 254 ---------------------- 255 | | | 256 +-----+ | +--------+ 257 | | | 258 +------+ +------+ +------+ 259 |(RB1) | |(RB2) | | (RBk)| 260 +------+ +------+ +------+ 261 |..| |..| |..| 262 | +----+ | | | | 263 | +---|-----|--|----------+ | 264 | +-|---|-----+ +-----------+ | 265 | | | +------------------+ | | 266 LAALP1-->(| | |) (| | |) <--LAALPn 267 +-------+ . . . +-------+ 268 | CE1 | | CEn | 269 +-------+ +-------+ 271 Figure 1 Active-Active Connection to TRILL Edge RBridges 273 By design, an LAALP (say LAALP1) does not forward packets received on 274 one member port to other member ports. As a result, the TRILL Hello 275 messages sent by one member RBridge (say RB1) via a port to CE1 will 276 not be forwarded to other member RBridges by CE1. That is to say, 277 member RBridges will not see each other's Hellos via the LAALP. So 278 every member RBridge of LAALP1 thinks of itself as appointed 279 forwarder for all VLANs enabled on an LAALP1 link and can 280 ingress/egress frames simultaneously in these VLANs [RFC6439]. 282 The simultaneous flow-based ingressing/egressing can cause some 283 problems. For example, simultaneous egressing of multi-destination 284 traffic by multiple member RBridges will result in frame duplication 285 at CE1 (see Section 3.1 of [RFC7379]); simultaneous ingressing of 286 frames originated by CE1 for different flows in the same VLAN with 287 the same source MAC address will result in MAC address flip-flopping 288 at remote egress RBridges that have data plane address learning 289 enabled (see Section 3.3 of [RFC7379]). The flip-flopping would in 290 turn cause packet re-ordering in reverse traffic. 292 Edge RBridges learn Data Label and MAC address to nickname 293 correspondences by default via decapsulating TRILL data packets (see 294 Section 4.8.1 of [RFC6325] as updated by [RFC7172]). Assuming that 295 the default data-plane learning is enabled at edge RBridges, MAC 296 flip-flopping can be solved by using a Virtual RBridge together with 297 its pseudo-nickname. This document specifies a way to do so. 299 3. Virtual RBridge and its Pseudo-nickname 301 A Virtual RBridge (RBv) represents a group of edge RBridges to which 302 at least one CE is multiply attached using an LAALP. More exactly, it 303 represents a group of ports on the edge RBridges providing end 304 station service and the service provided to the CE(s) on these ports, 305 through which the CE(s) are multiply attached to the TRILL campus 306 using LAALP(s). Such end station service ports are called RBv ports; 307 in contrast, other access ports at edge RBridges are called regular 308 access ports in this document. RBv ports are always LAALP connecting 309 ports, but not vice versa (see Section 4.1). For an edge RBridge, if 310 one or more of its end station service ports are ports of an RBv, 311 that RBridge is a member RBridge of that RBv. 313 For the convenience of description, a Virtual RBridge is also 314 referred to as an Active-Active Edge (AAE) group in this document. In 315 the TRILL campus, an RBv is identified by its pseudo-nickname, which 316 is different from any RBridge's regular nickname(s). An RBv has one 317 and only one pseudo-nickname. Each member RBridge (say RB1, RB2 ..., 318 RBk) of an RBv (say RBvn) advertises RBvn's pseudo-nickname using a 319 Nickname sub-TLV in its TRILL IS-IS LSP (Link State PDU) [RFC7176] 320 and SHOULD do so with maximum priority of use (0xFF), along with 321 their regular nickname(s). (Maximum priority is recommended to avoid 322 the disruption to an AAE group that would occur if the nickname were 323 taken away by a higher priority RBridge.) Then, from these LSPs, 324 other RBridges outside the AAE group know that RBvn is reachable 325 through RB1 to RBk. 327 A member RBridge (say RBi) loses its membership in RBvn when its last 328 port in RBvn becomes unavailable due to failure, re-configuration, 329 etc. Then RBi removes RBvn's pseudo-nickname from its LSP and 330 distributes the updated LSP as usual. From those updated LSPs, other 331 RBridges know that there is no path to RBvn through RBi now. 333 When member RBridges receive native frames on their RBv ports and 334 decide to ingress the frames into the TRILL campus, they use that 335 RBv's pseudo-nickname instead of their own regular nicknames as the 336 ingress nickname to encapsulate them into TRILL Data packets. So when 337 these packets arrive at an egress RBridge, even if they are 338 originated by the same end station in the same VLAN but ingressed by 339 different member RBridges, no address flip-flopping is observed on 340 the egress RBridge when decapsulating these packets. (When a member 341 RBridge of an AAE group ingresses a frame from a non-RBv port, it 342 still uses its own regular nickname as the ingress nickname.) 344 Since RBv is not a physical node and no TRILL frames are forwarded 345 between its ports via an LAALP, pseudo-node LSP(s) MUST NOT be 346 created for an RBv. RBv cannot act as a root when constructing 347 distribution trees for multi-destination traffic and its pseudo- 348 nickname is ignored when determining the distribution tree root for 349 TRILL campus [CMT]. So the tree root priority of RBv's nickname MUST 350 be set to 0, and this nickname MUST NOT be listed in the "s" 351 nicknames (see Section 4.5 of [RFC6325]) by the RBridge holding the 352 highest priority tree root nickname. 354 NOTE: In order to reduce the consumption of nicknames, especially in 355 large TRILL campus with lots of RBridges and/or active-active 356 accesses, when multiple CEs attach to the exact same set of edge 357 RBridges via LAALPs, those edge RBridges should be considered as a 358 single RBv with a single pseudo-nickname. 360 4. Member RBridges Auto-Discovery 362 Edge RBridges connected to a CE via an LAALP can automatically 363 discover each other with minimal configuration through exchange of 364 LAALP connection information. 366 From the perspective of edge RBridges, a CE that connects to edge 367 RBridges via an LAALP can be identified by the ID of the LAALP that 368 is unique across the TRILL campus (for example, the MC-LAG or DRNI 369 System ID [802.1AX]), which is referred to as an LAALP ID in this 370 document. On each of such edge RBridges, the access port to such a CE 371 is associated with an LAALP ID for the CE. An LAALP is considered 372 valid on an edge RBridge only if the RBridge still has an operational 373 downlink to that LAALP. For such an edge RBridge, it advertises a 374 list of LAALP IDs for its valid local LAALPs to other edge RBridges 375 via its E-L1FS FS-LSP(s) [RFC7356][rfc7180bis]. Based on the LAALP 376 IDs advertised by other RBridges, each RBridge can know which edge 377 RBridges could constitute an AAE group (See Section 4.1 for more 378 details). Then one RBridge is elected from the group to allocate an 379 available nickname (the pseudo-nickname) for the group (See Section 380 4.2 for more details). 382 4.1. Discovering Member RBridge for an RBv 384 Take Figure 2 as an example, where CE1 and CE2 multiply attach to 385 RB1, RB2 and RB3 via LAALP1 and LAALP2 respectively; CE3 and CE4 386 attach to RB3 and RB4 via LAALP3 and LAALP4 respectively. Assume 387 LAALP3 is configured to occupy a Virtual RBridge by itself. 389 ------------------------ 390 / \ 391 | TRILL Campus | 392 \ / 393 ------------------------- 394 | | | | 395 +-------+ | | +----------+ 396 | | | | 397 +-------+ +-------+ +-------+ +-------+ 398 | RB1 | | RB2 | | RB3 | | RB4 | 399 +-------+ +-------+ +-------+ +-------+ 400 | | | | | | | | | | 401 | +--------|--+ | +-------|-+ | +-------|---+ | 402 | +----------+ | | | | | | | | 403 | | +-----------|-|-|-------+ | +-------+ | | 404 | | | | | | | | | | 405 LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |) 406 +-------+ +-------+ +-------+ +-------+ 407 | CE1 | | CE2 | | CE3 | | CE4 | 408 +-------+ +-------+ +-------+ +-------+ 410 Figure 2 Different LAALPs to TRILL Campus 412 RB1 and RB2 advertise {LAALP1, LAALP2} in the PN-LAALP-Membership 413 sub-TLV (see Section 9.1 for more details) via their TRILL E-L1FS 414 LSPs respectively; RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}; 415 and RB4 announces {LAALP3, LAALP4}, respectively. 417 An edge RBridge is called an LAALP related RBridge if it has at least 418 one LAALP configured on an access port. On receipt of the PN-LAALP- 419 Membership sub-TLVs, RBn ignores them if it is not an LAALP related 420 RBridge; otherwise, RBn SHOULD use the LAALP information contained in 421 the sub-TLVs, along with its own PN-LAALP-Membership sub-TLVs to 422 decide which RBv(s) it should join and which edge RBridges constitute 423 each of such RBvs. Based on the information received, each of the 4 424 RBridges knows the following information: 426 LAALP ID OE-flag Set of edge RBridges 427 --------- -------- --------------------- 428 LAALP1 0 {RB1, RB2, RB3} 429 LAALP2 0 {RB1, RB2, RB3} 430 LAALP3 1 {RB3, RB4} 431 LAALP4 0 {RB3, RB4} 433 Where the OE-flag indicates whether an LAALP is willing to share an 434 RBv with other LAALPs if they multiply attach to exact the same set 435 of edge RBridges as it. For an LAALP (for example LAALP3), if its OE- 436 flag is one, it means that LAALP3 does not want to share, so it MUST 437 Occupy an RBv Exclusively (OE). Support of OE is optional. RBridges 438 that do not support OE ignore the OE bit and act as if it was zero 439 (see Section 11 on Configuration Consistency). 441 Otherwise, the LAALP (for example LAALP1) will share an RBv with 442 other LAALPs if possible. By default, this flag is set to zero. For 443 an LAALP, this flag is considered 1 if any edge RBridge advertises it 444 as one (see Section 9.1). 446 In the above table, there might be some LAALPs that attach to a 447 single RBridge due to mis-configuration or link failure, etc. Those 448 LAALPs are considered as invalid entries. Then each of the LAALP 449 related edge RBridges performs the following algorithm to decide 450 which valid LAALPs can be served by an RBv. 452 Step 1: Take all the valid LAALPs that have their OE-flags set to 453 1 out of the table and create an RBv per such LAALP. 455 Step 2: Sort the valid LAALPs left in the table in descending 456 order based on the number of RBridges in their associated set of 457 multi-homed RBridges. In the case that several LAALPs have same 458 number of RBridges, these LAALPs are then ordered in ascending 459 order in the proper places of the table based on their LAALP IDs 460 considered as unsigned integers. (for example, in the above table, 461 both LAALP1 and LAALP2 have 3 member RBridges, assuming LAALP1 ID 462 is smaller than LAALP2 ID, so LAALP1 is followed by LAALP2 in the 463 ordered table.) 465 Step 3: Take the first valid LAALP (say LAALP_i) with the maximum 466 set of RBridges, say S_i, out of the table and create a new RBv 467 (Say RBv_i) for it. 469 Step 4: Walk through the remaining valid LAALPs in the table one 470 by one, pick up all the valid LAALPs that have their sets of 471 multi-homed RBridges contain exactly the same RBridges as that of 472 LAALP_i and take them out of the table. Then appoint RBv_i as the 473 servicing RBv for those LAALPs. 475 Step 5: Repeat Step 3-4 for any LAALPs left until all the valid 476 entries in the table are associated with an RBv. 478 After performing the above steps, all the 4 RBridges know that LAALP3 479 is served by an RBv, say RBv1, which has RB3 and RB4 as member 480 RBridges; LAALP1 and LAALP2 are served by another RBv, say RBv2, 481 which has RB1, RB2 and RB3 as member RBridges; and LAALP4 is served 482 by RBv3, which has RB3 and RB4 as member RBridges, shown as follows: 484 RBv Serving LAALPs Member RBridges 485 ----- ------------------- --------------- 486 RBv1 {LAALP3} {RB3, RB4} 487 RBv2 {LAALP1, LAALP2} {RB1, RB2, RB3} 488 RBv3 {LAALP4} {RB3, RB4} 490 In each RBv, one of the member RBridges is elected as the vDRB 491 (Designated RBridge) of the RBv. Then this RBridge picks up an 492 available nickname as the pseudo-nickname for the RBv and announces 493 it to all other member RBridges of the RBv via its TRILL E-L1FS LSPs 494 (refer to Section 9.2 for the relative extended sub-TLVs). 496 4.2. Selection of Pseudo-nickname for RBv 498 As described in Section 3, in the TRILL campus, an RBv is identified 499 by its pseudo-nickname. In an AAE group, one member RBridge is 500 elected for the duty to select a pseudo-nickname for this RBv; this 501 RBridge is called Designated RBridge of the RBv (vDRB) in this 502 document. The winner is the RBridge with the largest IS-IS System ID 503 considered as an unsigned integer, in the group. Then based on its 504 TRILL IS-IS link state database and the potential pseudo-nickname(s) 505 reported in the PN-LAALP-Membership sub-TLVs by other member RBridges 506 of this RBv (see Section 9.1 for more details), the vDRB selects an 507 available nickname as the pseudo-nickname for this RBv and advertises 508 it to the other RBridges via its E-L1FS FS-LSP(s) (see Section 9.2 509 and [rfc7180bis]). Except as provided below, the selection of a 510 nickname to use as the pseudo-nickname follows the usual TRILL rules 511 given in [RFC6325] as updated by [rfc7180bis]. 513 To reduce the traffic disruption caused by nickname changing, if 514 possible, vDRB SHOULD attempt to reuse the pseudo-nickname recently 515 used by the group when selecting nickname for the RBv. To help the 516 vDRB to do so, each LAALP related RBridge advertises a re-using 517 pseudo-nickname for each of its LAALPs in its LAALP Membership sub- 518 TLV if it has used such a pseudo-nickname for that LAALP recently. 519 Although it is up to the implementation of the vDRB as to how to 520 treat the re-using pseudo-nicknames, the following is RECOMMENDED: 522 o If there are multiple available re-using pseudo-nicknames that are 523 reported by all the member RBridges of some LAALPs in this RBv, 524 the available one that is reported by the largest number of such 525 LAALPs is chosen as the pseudo-nickname for this RBv. If a tie 526 exists, the re-using pseudo-nickname with the smallest value 527 considered as an unsigned integer is chosen. 529 o If only one re-using pseudo-nickname is reported, it SHOULD be 530 chosen if available. 532 If there is no available re-using pseudo-nickname reported, the vDRB 533 selects a nickname by its usual method. 535 Then the selected pseudo-nickname is announced by the vDRB to other 536 member RBridges of this RBv in the PN-RBv sub-TLV (see Section 9.2). 538 5. Distribution Trees and Designated Forwarder 540 In an AAE group, as each of the member RBridges thinks it is the 541 appointed forwarder for VLAN x, without changes made for active- 542 active connection support, they would all ingress/egress frames 543 into/from TRILL campus for all VLANs. For multi-destination frames, 544 more than one member RBridges ingressing them may cause some of the 545 resulting TRILL Data packets to be discarded due to failure of 546 Reverse Path Forwarding (RPF) Check on other RBridges; for a multi- 547 destination traffic, more than one RBridges egressing it may cause 548 local CE(s) receiving duplication frame. Furthermore, in an AAE 549 group, a multi-destination frame sent by a CE (say CEi) may be 550 ingressed into TRILL campus by one member RBridge, then another 551 member RBridge will receive it from TRILL campus and egress it to 552 CEi, which will result in loop back of frame for CEi. These problems 553 are all described in [RFC7379]. 555 In the following sub-sections, the first two issues are discussed in 556 Section 5.1 and Section 5.2, respectively; the third one is discussed 557 in Section 5.3. 559 5.1. Different Trees for Different Member RBridges 561 In TRILL, RBridges normally use distribution trees to forward multi- 562 destination frames. (Under some circumstances they can be unicast as 563 specified in [RFC7172].) An RPF Check along with other checking is 564 used to avoid temporary multicast loops during topology changes 565 (Section 4.5.2 of [RFC6325]). The RPF Check mechanism only accepts a 566 multi-destination frame ingressed by an RBridge RBi and forwarded on 567 a distribution tree if it arrives at another RBridge RBn on the 568 expected port. If arriving on any other port, the frame MUST be 569 dropped. 571 To avoid address flip-flopping on remote RBridges, member RBridges 572 use RBv's pseudo-nickname instead of their regular nicknames as 573 ingress nickname to ingress native frames, including multi- 574 destination frames. From the view of other RBridges, these frames 575 appear as if they were ingressed by the RBv. When multi-destination 576 frames of different flows are ingressed by different member RBridges 577 of an RBv and forwarded along the same distribution tree, they may 578 arrive at RBn on different ports. Some of them will violate the RPF 579 Check principle at RBn and be dropped, which will result in lost 580 traffic. 582 In an RBv, if different member RBridge uses different distribution 583 trees to ingress multi-destination frames, the RPF Check violation 584 issue can be fixed. Coordinated Multicast Trees (CMT) [CMT] proposes 585 such an approach, and makes use of the Affinity sub-TLV defined in 586 [RFC7176] to tell other RBridges which trees a member RBridge (say 587 RBi) may choose when ingressing multi-destination frames; then all 588 RBridges in the TRILL campus can calculate RPF Check information for 589 RBi on those trees taking the tree affinity information into account 590 [CMT]. 592 This document uses the approach proposed in [CMT] to fix the RPF 593 Check violation issue. Please refer to [CMT] for more details of the 594 approach. 596 5.2. Designated Forwarder for Member RBridges 598 Take Figure 3 as an example, where CE1 and CE2 are served by an RBv 599 that has RB1 and RB2 as member RBridges. In VLAN x, the three CEs can 600 communicate with each other. 602 --------------------- 603 / \ +-----+ 604 | TRILL Campus |---| RBn | 605 \ / +-----+ 606 ----------------------- 607 | | 608 +----+ +------+ 609 | | 610 +---------+ +--------+ 611 | RB1 | | RB2 | 612 | oooooooo|oooooooooooooooo|ooooo | 613 +o--------+ RBv +-----o--+ 614 o|oooo|oooooooooooooooooooo|o|o | 615 | +--|--------------------+ | | 616 | | +---------+ +----------+ | 617 (| |)<-LAALP1 (| |)<-LAALP2 | 618 +-------+ +-------+ +-------+ 619 | CE1 | | CE2 | | CE3 | 620 +-------+ +-------+ +-------+ 622 Figure 3 A Topology with Multi-homed and Single-homed CEs 624 When a remote RBridge (say RBn) sends a multi-destination TRILL Data 625 packet in VLAN x (or the FGL that VLAN x maps to if the packet is 626 FGL), both RB1 and RB2 will receive it. As each of them thinks it is 627 the appointed forwarder for VLAN x, without changes made for active- 628 active connection support, they would both forward the frame to 629 CE1/CE2. As a result, CE1/CE2 would receive duplicate copies of the 630 frame through this RBv. 632 In another case, assume CE3 is single-homed to RB2. When it transmits 633 a native multi-destination frame onto link CE3-RB2 in VLAN x, the 634 frame can be locally replicated to the ports to CE1/CE2, and also 635 encapsulated into TRILL Data packet and ingressed into TRILL campus. 636 When the packet arrives at RB1 across the TRILL campus, it will be 637 egressed to CE1/CE2 by RB1. Then CE1/CE2 receives duplicate copies 638 from RB1 and RB2. 640 In this document, the Designated Forwarder (DF) for a VLAN is 641 introduced to avoid the duplicate copies. The basic idea of the DF is 642 to elect one RBridge per VLAN from an RBv to egress multi-destination 643 TRILL Data traffic and replicate locally-received multi-destination 644 native frames to the CEs served by the RBv. 646 Note that the DF has an effect only on the egressing/replicating of 647 multi-destination traffic. It has no effect on the ingressing, 648 forwarding, or egressing of unicast frames. Furthermore, the DF check 649 is performed only for RBv ports, not on regular access ports. 651 Each RBridge in an RBv elects a DF using the same algorithm which 652 guarantees the same RBridge elected as DF per VLAN by all members of 653 the RBv. 655 Assuming there are m LAALPs and k member RBridges in an RBv; each 656 LAALP is referred to as LAALPi where 0 <= i < m, and each RBridge is 657 referred to as RBj where 0 <= j < k, the DF election algorithm per 658 VLAN is as follows: 660 Step 1: For LAALPi, sort all the RBridges in numerically ascending 661 order based on SHA-256(System IDj | LAALP IDi) considered as an 662 unsigned intger, where SHA-256 is the hash function in [RFC6234], 663 "System IDj" is the 6-byte IS-IS System ID of RBj, "|" means 664 concatenation, and LAALP IDi is the LAALP ID for LAALPi. System ID 665 and LAALP ID are considered as byte strings. In the case of a tie, 666 the tied RBridges are sorted in numerically ascending order by 667 their System IDs considered as unsigned integers. 669 Step 2: Each RBridge in the numerically sorted list is assigned a 670 monotonically increasing number j, such that increasing number j 671 corresponds to its position in the sorted list, i.e., the first 672 RBridge (the one with the smallest SHA-256(System ID | LAALP ID)) 673 is assigned zero and the last is assigned k-1. 675 Step 3: For each VLAN ID n, choose the RBridge whose number equals 676 (n mod k) as the DF. 678 Step 4: Repeat Step 1-3 for the remaining LAALPs until there is a 679 DF per VLAN per LAALP in the RBv. 681 For a multi-destination native frame of VLAN x received, if RBi is an 682 LAALP attached RBridge, there are three cases where RBi replicates 683 the multi-destination frame, as follows: 685 1) Local replication of the frame to regular (non-AAE) access 686 ports as per [RFC6325] (and [RFC7172] for FGL). 688 2) RBv ports associated with the same pseudo-nickname as that of 689 the incoming port, no matter whether RBi is the DF for the 690 frame's VLAN on the outgoing ports except that the frame MUST 691 NOT be replicated back to the incoming port. RBi cannot simply 692 depend on the DF to forward the multi-destination frame back 693 into the AAEs associated with pseudo-nickname as that would 694 cause the source CE to get the frame back, which is a violation 695 of basic Ethernet properties. The DF will not forward such a 696 frame back into the AAE due to ingress nickname filtering as 697 described in Section 5.3. 699 3) RBv ports on which RBi is the DF for the frame's VLAN while 700 they are associated with different pseudo-nickname(s) to that 701 of the incoming port. 703 For a multi-destination TRILL Data packet received, RBi MUST NOT 704 egress it out of the RBv ports where it is not DF for the frame's 705 Inner.VLAN (or for the VLAN corresponding to the Inner.Label if the 706 packet is an FGL one). Otherwise, whether or not egressing it out of 707 such ports is further subject to the filtering check result of the 708 frame's ingress nickname on these ports (see Section 5.3). 710 5.3. Ingress Nickname Filtering 712 As shown in Figure 3, CE1 may send multi-destination traffic in VLAN 713 x to TRILL campus via a member RBridge (say RB1). The traffic is then 714 TRILL-encapsulated by RB1 and delivered through the TRILL campus to 715 multi-destination receivers. RB2 may receive the traffic, and egress 716 it back to CE1 if it is the DF for VLAN x on the port to LAALP1. Then 717 the traffic loops back to CE1 (see Section 3.2 of [RFC7379). 719 To fix the above issue, an ingress nickname filtering check is 720 required by this document. The idea is to check the ingress nickname 721 of a multi-destination TRILL Data packet before egressing a copy of 722 it out of an RBv port. If the ingress nickname matches the pseudo- 723 nickname of the RBv (associated with the port), the filtering check 724 should fail and the copy MUST NOT be egressed out of that RBv port. 725 Otherwise, the copy is egressed out of that port if it has also 726 passed other checks, such as the appointed forwarder check in Section 727 4.6.2.5 of [RFC6325] and the DF check in Section 5.2. 729 Note that this ingress nickname filtering check has no effect on the 730 multi-destination native frames received on access ports and 731 replicated to other local ports (including RBv ports), since there is 732 no ingress nickname associated with such frames. Furthermore, for the 733 RBridge regular access ports, there is no pseudo-nickname associated 734 with them; so no ingress nickname filtering check is required on 735 those ports. 737 More details of data packet processing on RBv ports are given in the 738 next section. 740 6. TRILL Traffic Processing 742 This section provides more details of native frame and TRILL Data 743 packet processing as it relates to the RBv's pseudo-nickname. 745 6.1. Native Frames Ingressing 747 When RB1 receives a unicast native frame from one of its ports that 748 has end-station service enabled, it processes the frame as described 749 in Section 4.6.1.1 of [RFC6325] with the following exception. 751 o If the port is an RBv port, RB1 uses the RBv's pseudo-nickname, 752 instead of one of its regular nickname(s) as the ingress nickname 753 when doing TRILL encapsulation on the frame. 755 When RB1 receives a native multi-destination (Broadcast, Unknown 756 unicast or Multicast) frame from one of its access ports (including 757 regular access ports and RBv ports), it processes the frame as 758 described in Section 4.6.1.2 of [RFC6325] with the following 759 exceptions. 761 o If the incoming port is an RBv port, RB1 uses the RBv's pseudo- 762 nickname, instead of one of its regular nickname(s) as the ingress 763 nickname when doing TRILL encapsulation on the frame. 765 o For the copies of the frame replicated locally to RBv ports, there 766 are two cases as follows: 768 - If the outgoing port(s) is associated with the same pseudo- 769 nickname as that of the incoming port but not with the same 770 LAALP as the incoming port, the copies are forwarded out of 771 that outgoing port(s) after passing the appointed forwarder 772 check for the frame's VLAN. That is to say, the copies are 773 processed on such port(s) as Section 4.6.1.2 of [RFC6325]. 775 - Else, the Designated Forwarder (DF) check is also made on the 776 outgoing ports for the frame's VLAN after the appointed 777 forwarder check. The copies are not output through the ports 778 that failed the DF check (i.e., RB1 is not DF for the frame's 779 VLAN on the ports); otherwise, the copies are forwarded out of 780 the ports that pass the DF check (see Section 5.2). 782 For such a frame received, the MAC address information learned by 783 observing it, together with the LAALP ID of the incoming port SHOULD 784 be shared with other member RBridges in the group (see Section 7). 786 6.2. Egressing TRILL Data Packets 788 This section describes egress processing of the TRILL Data packets 789 received on an RBv member RBridge (say RBn). Section 6.2.1 describes 790 the egress processing of unicast TRILL Data packets and Section 6.2.2 791 specifies the multi-destination TRILL Data packets egressing. 793 6.2.1. Unicast TRILL Data Packets 795 When receiving a unicast TRILL data packet, RBn checks the egress 796 nickname in the TRILL header of the packet. If the egress nickname 797 is one of RBn's regular nicknames, the packet is processed as defined 798 in Section 4.6.2.4 of [RFC6325]. 800 If the egress nickname is the pseudo-nickname of a local RBv, RBn is 801 responsible for learning the source MAC address, unless data plane 802 learning has been disabled. The learned {Inner.MacSA, Data Label, 803 ingress nickname} triplet SHOULD be shared within the AAE group as 804 described in Section 7. 806 Then the packet is de-capsulated to its native form. The Inner.MacDA 807 and Data Label are looked up in RBn's local forwarding tables, and 808 one of the three following cases will occur. RBn uses the first case 809 that applies and ignores the remaining cases: 811 o If the destination end station identified by the Inner.MacDA and 812 Data Label is on a local link, the native frame is sent onto that 813 link with the VLAN from the Inner.VLAN or VLAN corresponding to 814 the Inner.Label if the packet is FGL. 816 o Else if RBn can reach the destination through another member 817 RBridge RBk, it tunnels the native frame to RBk by re- 818 encapsulating it into a unicast TRILL Data packet and sends it to 819 RBk. RBn uses RBk's regular nickname, instead of the pseudo- 820 nickname as the egress nickname for the re-encapsulation, and the 821 ingress nickname remains unchanged (somewhat similar to Section 822 2.4.2.1 of [rfc7180bis]). If the hop count value of the packet is 823 too small for it to reach RBk safely, RBn SHOULD increase that 824 value properly in doing the re-encapsulation. (NOTE: When 825 receiving that re-encapsulated TRILL Data packet, as the egress 826 nickname of the packet is RBk's regular nickname rather than the 827 pseudo-nickname of a local RBv, RBk will process it as Section 828 4.6.2.4 of [RFC6325], and will not re-forward it to another 829 RBridge.) 831 o Else, RBn does not know how to reach the destination; it sends the 832 native frame out of all the local ports on which it is appointed 833 forwarder for the Inner.VLAN (or appointed forwarder for the VLAN 834 into which the Inner.Label maps on that port for FGL TRILL Data 835 packet [RFC7172]). 837 6.2.2. Multi-Destination TRILL Data Packets 839 When RB1 receives a multi-destination TRILL Data Packet, it checks 840 and processes the packet as described in Section 4.6.2.5 of [RFC6325] 841 with the following exception. 843 o On each RBv port where RBn is the appointed forwarder for the 844 packet's Inner.VLAN (or for the VLAN to which the packet's 845 Inner.Label maps on that port if it is an FGL TRILL Data packet), 846 the Designated Forwarder check (see Section 5.2) and the Ingress 847 Nickname Filtering check (see Section 5.3) are further performed. 848 For such an RBv port, if either the DF check or the filtering 849 check fails, the frame MUST NOT be egressed out of that port. 850 Otherwise, it can be egressed out of that port. 852 7. MAC Information Synchronization in Edge Group 854 An edge RBridge, say RB1 in LAALP1, may have learned a { MAC address, 855 Data Label } to nickname correspondence for a remote host h1 when h1 856 sends a packet to CE1. The returning traffic from CE1 may go to 857 another member RBridge of LAALP1, for example RB2. RB2 may not have 858 that correspondence stored. Therefore it has to do the flooding for 859 unknown unicast. Such flooding is unnecessary since the returning 860 traffic is almost always expected and RB1 had learned the address 861 correspondence. To avoid the unnecessary flooding, RB1 SHOULD share 862 the correspondence with other RBridges of LAALP1. RB1 synchronizes 863 the correspondence by using the MAC-RI sub-TLV [RFC6165] in its 864 ESADI-LSPs [RFC7357]. 866 On the other hand, RB2 has learned the MAC address and Data Label of 867 CE1 when CE1 sends a frame to h1 through RB2. The returning traffic 868 from h1 may go to RB1. RB1 may not have CE1's MAC address and Data 869 Label stored even though it is in the same LAALP for CE1 as RB2. 870 Therefore it has to flood the traffic out of all its access ports 871 where it is appointed forwarder for the VLAN (see Section 6.2.1) or 872 the VLAN the FGL maps to on that port if the packet is FGL. Such 873 flooding is unnecessary since the returning traffic is almost always 874 expected and RB2 had learned the CE1's MAC and Data Label 875 information. To avoid that unnecessary flooding, RB2 SHOULD share the 876 MAC address and Data Label with other RBridges of LAALP1. RB2 877 synchronizes the MAC address and Data Label by enclosing the relative 878 MAC-RI TLV within a pair of boundary TRILL APPsub-TLVs for LAALP1 879 (see Section 9.3) in its ESADI-LSP [RFC7357]. After receiving the 880 enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1 881 related RBridges) treat the MAC address and Data Label as if it was 882 learned by them locally on their member port of LAALP1; the LAALP1 883 unrelated RBridges just ignore LAALP1's boundary APPsub-TLVs and 884 treat the MAC address and Data Label as specified in [RFC7357]. 885 Furthermore, in order to make the LAALP1 unrelated RBridges know that 886 the MAC and Data Label is reachable through the RBv that provides 887 service to LAALP1, the Topology-id/Nickname field of the MAC-RI TLV 888 SHOULD carry the pseudo-nickname of the RBv rather than zero or one 889 of the originating RBridge's (i.e., RB2's) regular nicknames. 891 8. Member Link Failure in RBv 893 As shown in Figure 4, suppose the link RB1-CE1 fails. Although a new 894 RBv will be formed by RB2 and RB3 to provide active-active service 895 for LAALP1 (see Section 5), the unicast traffic to CE1 might still be 896 forwarded to RB1 before the remote RBridge learns CE1 is attached to 897 the new RBv. That traffic might be disrupted by the link failure. 898 Section 8.1 discusses the failure protection in this scenario. 900 However, for multi-destination TRILL Data packets, they can reach all 901 member RBridges of the new RBv and be egressed to CE1 by either RB2 902 or RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the 903 packet's Inner.Label maps to in the new RBv). Although there might be 904 a transient hang time between failure and the establishment of the 905 new RBv, special actions to protect against downlink failure for such 906 multi-destination packets is not needed. 908 ------------------ 909 / \ 910 | TRILL Campus | 911 \ / 912 -------------------- 913 | | | 914 +---+ | +----+ 915 | | | 916 +------+ +------+ +------+ 917 | RB1 | | RB2 | | RB3 | 918 ooooooo|ooooo|oooooo|ooo|ooooo | 919 o+------+ RBv +------+ +-----o+ 920 o|oooo|ooooooo|oooo|ooooo|oo|o 921 | | | +-|-----+ | 922 \|/+--|-------+ | +------+ | 923 - B | +----------|------+ | | 924 /|\| +-----------+ | | | 925 (| | |)<--LAALP1 (| | |)<--LAALP2 926 +-------+ +-------+ 927 | CE1 | | CE2 | 928 +-------+ +-------+ 929 B - Failed Link or Link bundle 931 Figure 4 A Topology with Multi-homed and Single-homed CEs 933 8.1. Link Protection for Unicast Frame Egressing 935 When the link CE1-RB1 fails, RB1 loses its direct connection to CE1. 936 The MAC entry through the failed link to CE1 is removed from RB1's 937 local forwarding table immediately. Another MAC entry learned from 938 another member RBridge of LAALP1 (for example RB2, since it is still 939 a member RBridge of LAALP1) is installed into RB1's forwarding table 940 (see Section 9.3). In that new entry, RB2 (identified by one of its 941 regular nicknames) is the egress RBridge for CE1's MAC address. Then 942 when a TRILL Data packet to CE1 is delivered to RB1, it can be 943 tunneled to RB2 after being re-encapsulated (ingress nickname remains 944 unchanged and egress nickname is replaced by RB2's regular nickname) 945 based on the above installed MAC entry (see bullet 2 in Section 946 6.2.1). Then RB2 receives the frame and egresses it to CE1. 948 After the failure recovery, RB1 learns that it can reach CE1 via link 949 CE1-RB1 again by observing CE1's native frames or from the MAC 950 information synchronization by member RBridge(s) of LAALP1 described 951 in Section 7, then it restores the MAC entry to its previous one and 952 downloads it to its data plane fast path logic. 954 9. TLV Extensions for Edge RBridge Group 955 The following subsections specify the APPsub-TLVs needed to support 956 pseudo-nickname edge groups. 958 9.1. PN-LAALP-Membership APPsub-TLV 960 This APPsub-TLV is used by an edge RBridge to announce its associated 961 pseudo-nickname LAALP information. It is defined as a sub-TLV of the 962 TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs 963 [rfc7180bis]. It has the following format: 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Type = PN-LAALP-Membership | (2 bytes) 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Length | (2 bytes) 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 970 | LAALP RECORD(1) | (variable) 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 972 . . 973 . . 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 975 | LAALP RECORD(n) | (variable) 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 978 Figure 5 PN-LAALP-Membership Advertisement APPsub-TLV 980 where each LAALP RECORD has the following form: 982 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 .. 983 +--+-+-+-+-+-+-+-+ 984 |OE| RESV | (1 byte) 985 +--+-+-+-+-+-+-+-+ 986 | Size | (1 byte) 987 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Re-using Pseudo-nickname | (2 bytes) 989 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 990 | LAALP ID | (variable) 991 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 993 o PN-LAALP-Membership (2 bytes): Defines the type of this sub-TLV, 994 #tbd1. 996 o Length (2 bytes): the sum of the lengths of the LAALP RECORDs. 998 o OE (1 bit): a flag indicating whether or not the LAALP wants to 999 occupy an RBv by itself; 1 for occupying by itself (or Occupying 1000 Exclusively (OE)). By default, it is set to 0 on transmit. This 1001 bit is used for edge RBridge group auto-discovery (see Section 1002 4.1). For any one LAALP, the values of this flag might conflict in 1003 the LSPs advertised by different member RBridges of that LAALP. In 1004 that case, the flag for that LAALP is considered as 1. 1006 o RESV (7 bits): MUST be transmitted as zero and ignored on receipt. 1008 o Size (1 byte): Size of remaining part of LAALP RECORD (2 plus 1009 length of the LAALP ID). 1011 o Re-using Pseudo-nickname (2 bytes): Suggested pseudo-nickname of 1012 the AAE group serving the LAALP. If the LAALP is not served by any 1013 AAE group, this field MUST be set to zero. It is used by the 1014 originating RBridge to help the vDRB to reuse the previous pseudo- 1015 nickname of an AAE group (see Section 4.2). 1017 o LAALP ID (variable): The ID of the LAALP. See Section 9.4. 1019 On receipt of such an APPsub-TLV, if RBn is not an LAALP related edge 1020 RBridge, it ignores the sub-TLV; otherwise, it parses the sub-TLV. 1021 When new LAALPs are found or old ones are withdrawn compared to its 1022 old copy, and they are also configured on RBn, it triggers RBn to 1023 perform the "Member RBridges Auto-Discovery" procedure described in 1024 Section 4.1. 1026 9.2. PN-RBv APPsub-TLV 1028 The PN-RBv APPsub-TLV is used by a Designated RBridge of a Virtual 1029 RBridge (vDRB) to dictate the pseudo-nickname for the LAALPs served 1030 by the RBv. It is defined as a sub-TLV of TRILL GENINFO TLV [RFC7357] 1031 and is distributed in E-L1FS FS-LSP [rfc7180bis]. It has the 1032 following format: 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Type = PN-RBv | (2 bytes) 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Length | (2 bytes) 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | RBv's Pseudo-Nickname | (2 bytes) 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | LAALP ID Size | (1 byte) 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1043 | LAALP ID (1) | (variable) 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1045 . . 1046 . . 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1048 | LAALP ID (n) | (variable) 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1051 o PN-RBv (2 bytes): Defines the type of this sub-TLV, #tbd2. 1053 o Length (2 bytes): 3+n*k bytes, where there are n LAALP IDs, each 1054 of size k bytes. k is found in the LLALP ID Size field below. If 1055 Length is not 3 plus an integer time k, the sub-TLV is corrupt and 1056 MUST be ignored. 1058 o RBv's Pseudo-Nickname (2 bytes): The appointed pseudo-nickname for 1059 the RBv that serves for the LAALPs listed in the following fields. 1061 o LAALP ID Size (1 byte): The size of each of the following LAALP 1062 IDs in this sub-TLV. 8 if the LAALPs listed are MC-LAGs or DRNI 1063 (Section 6.3.2 in [802.1AX]). The value in this field is the k 1064 that appears in the formula for Length above. 1066 o LAALP ID (LAAP ID Size bytes): The ID of the LAALP. See Section 1067 9.4. 1069 This sub-TLV may occur multiple times with the same RBv pseudo- 1070 nickname with the meaning that all of the LAALPs listed are 1071 identified by that pseudo-nickname. For example, if there are LAALP 1072 IDs of different length, then the LAALP IDs of each size would have 1073 to be listed in a separate sub-TLV. 1075 Since a PN-RBv APPsub-TLV is distributed as part of the application 1076 link state, using the E-L1FS scope [rfc7180bis], changes in contents 1077 or withdrawal or creation of a PN-RBv APPsub-TLV is accomplished by 1078 the Designated RBridge updating and flooding an E-L1FS PDU. 1080 On receipt of such a sub-TLV, if RBn is not an LAALP related edge 1081 RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member 1082 RBridge of the RBv identified by the list of LAALPs, it associates 1083 the pseudo-nickname with the ports of these LAALPs and downloads the 1084 association to data plane fast path logic. At the same time, RBn 1085 claims RBv pseudo-nickname across the campus and announces RBv as its 1086 child on the corresponding tree or trees using the Affinity sub-TLV 1087 [RFC7176] [CMT]. 1089 9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs 1091 In this document, two APPsub-TLVs are used as boundary APPsub-TLVs 1092 for edge RBridge to enclose the MAC-RI TLV(s) containing the MAC 1093 address information leant form local port of an LAALP when this 1094 RBridge wants to share the information with other edge RBridges. They 1095 are defined as TRILL APPsub-TLVs [RFC7357]. The PN-MAC-RI-LAALP-INFO- 1096 START APPsub-TLV has the following format: 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 |Type=PN-MAC-RI-LAALP-INFO-START| (2 byte) 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Length | (2 byte) 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+ 1103 | LAALP ID | (variable) 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+ 1106 o PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this 1107 APPsub-TLV, #tbd3. 1109 o Length (2 bytes): the size of the following LAALP ID. 8 if the 1110 LAALP listed is an MAC-LAG or DRNI. 1112 o LAALP ID (variable): The ID of the LAALP (see Section 9.4). 1114 PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows: 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Type=PN-MAC-RI-LAALP-INFO-END | (2 byte) 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Length | (2 byte) 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 o PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this sub- 1123 TLV, #tbd4. 1125 o Length (2 bytes): 0. 1127 This pair of APPsub-TLVs can be carried multiple times in an ESADI 1128 LSP and in multiple ESADI-LSPs. When an LAALP related edge RBridge 1129 (say RBn) wants to share with other edge RBridges the MAC addresses 1130 learned on its local ports of different LAALPs, it uses one or more 1131 pairs of such APPsub-TLVs for each of such LAALPs in its ESADI-LSPs. 1132 Each encloses the MAC-RI TLVs containing the MAC addresses learned 1133 from a specific LAALP. Furthermore, if the LAALP is served by a local 1134 RBv, the value of Topology ID/Nickname field in the relative MAC-RI 1135 TLVs SHOULD be the pseudo-nickname of the RBv rather than one of the 1136 RBn's regular nickname or zero. Then on receipt of such a MAC-RI TLV, 1137 remote RBridges know that the contained MAC addresses are reachable 1138 through the RBv. 1140 On receipt of such boundary APPsub-TLVs, when the edge RBridge is not 1141 an LAALP related one or cannot recognize such sub-TLVs, it ignores 1142 them and continues to parse the enclosed MAC-RI TLVs per [RFC7357]. 1143 Otherwise, the recipient parses the boundary APPsub-TLVs. The PN-MAC- 1144 RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur within 1145 one TRILL GENINFO TLV. If an END is encountered without any previous 1146 START in the ESADI-LSP, the END APPsub-TLV is ignored. If, after 1147 encountering a START, the end of the ESADI-LSP is reached without 1148 encountering an END, then the end of the ESADI-LSP is treated as if 1149 it were a PN-MAC-RI-LAALP-INFO-END. The boundary APPsub-TLVs and TLVs 1150 between them are handled as follows: 1152 1) If the edge RBridge is configured with the contained LAALP and the 1153 LAALP is also enabled locally, it treats all the MAC addresses, 1154 contained in the following MC-RI TLVs enclosed by the 1155 corresponding pair of boundary APPsub-TLVs, as if they were 1156 learned from its local port of that LAALP; 1158 2) Else, it ignores these boundary APPsub-TLVs and continues to parse 1159 the following MAC-RI TLVs per [RFC7357] until another pair of 1160 boundary APPsub-TLVs is encountered. 1162 9.4. LAALP IDs 1164 The LAALP ID identifies an AAE RBridge Group in the TRILL campus and 1165 thus MUST be unique across the campus. In all of the APPsub-TLVs 1166 specified above, the length of the LAALP ID can be determined from a 1167 size field. If that length is 8 bytes, the LAALP ID is an MC-LAG or 1168 DRNI identifier as specified in Section 6.3.2 in [802.1AX]. The 1169 meaning and structure of LAALP IDs of other lengths is reserved and 1170 may be specified in future documents. 1172 10. OAM Packets 1174 Attention must be paid when generating OAM packets. To ensure the 1175 response messages can return to the originating member RBridge of an 1176 RBv, pseudo-nickname cannot be used as the ingress nickname in TRILL 1177 OAM messages, except in the response to an OAM message that has that 1178 RBv's pseudo-nickname as egress nickname. For example, assume RB1 is 1179 a member RBridge of RBvi, RB1 cannot use RBvi's pseudo-nickname as 1180 the ingress nickname when originating OAM messages; otherwise the 1181 responses to the messages may be delivered to another member RBridge 1182 of RBvi rather than RB1. But when RB1 responds to the OAM message 1183 with RBvi's pseudo-nickname as egress nickname, it can use that 1184 pseudo-nickname as the ingress nickname in the response message. 1186 Since RBridges cannot use OAM messages for the learning of MAC 1187 addresses (Section 3.2.1 of [RFC7174]), it will not lead to MAC 1188 address flip-flopping at a remote RBridge even though RB1 uses its 1189 regular nicknames as ingress nicknames in its TRILL OAM messages 1190 while uses RBvi's pseudo-nickname in its TRILL Data packets. 1192 11. Configuration Consistency 1193 The VLAN membership of all the RBridge ports in an LAALP MUST be the 1194 same. Any inconsistencies in VLAN membership may result in packet 1195 loss or non-shortest paths. 1197 Take Figure 1 for example, suppose RB1 configures VLAN1 and VLAN2 for 1198 the link CE1-RB1, while RB2 only configures VLAN1 for the CE1-RB2 1199 link. Both RB1 and RB2 use the same ingress nickname RBv for all 1200 frames originating from CE1. Hence, a remote RBridge RBx will learn 1201 that CE1's MAC address in VLAN2 is originating from RBv. As a 1202 result, on the returning path, remote RBridge RBx may deliver VLAN2 1203 traffic to RB2. However, RB2 does not have VLAN2 configured on CE1- 1204 RB2 link and hence the frame may be dropped or has to be redirected 1205 to RB1 if RB2 knows RB1 can reach CE1 in VLAN2. 1207 How LAALP implementations maintain consistent VLAN configuration on 1208 the TRILL switch LAALP ports is out of scope for the TRILL protocol. 1209 However, considering the consequences that might cause by the 1210 inconsistency, TRILL switches MUST disable the ports connected to an 1211 LAALP with inconsistent VLAN configuration. 1213 It is important that if any VLAN in an LAALP is being mapped by edge 1214 RBridges to an FGL [RFC7172], that the mapping MUST be same for all 1215 edge RBridge ports in the LAALP. Otherwise, for example, unicast FGL 1216 TRILL Data packets from remote RBridges may get mapped into different 1217 VLANs depending on which edge RBridge receives and egresses them. 1219 It is important that RBridges in an AAE group not be configured to 1220 assert the OE bit if any RBridge in the group does not implement it. 1221 Since, as stated in [RFC7379], the RBridges in an AAE edge group are 1222 expected to be from the same vendor, due to the proprietary nature of 1223 deployed LAALPs, this will normally follow automatically from all of 1224 the RBridge in an AAE edge group supporting or all not supporting OE. 1226 12. Security Considerations 1228 Authenticity for contents transported in IS-IS PDUs is enforced using 1229 regular IS-IS security mechanism [IS-IS] [RFC5310]. 1231 For security considerations pertain to extensions transported by 1232 TRILL ESADI, see the Security Considerations section in [RFC7357]. 1234 Since currently deployed LAALPs [RFC7379] are proprietary, security 1235 over membership in and internal management of active-active edge 1236 groups is proprietary. If authentication is not used, a rogue RBridge 1237 that insinuates itself into an active-active edge group can disrupt 1238 end station traffic flowing into or out of that group. For example, 1239 if there are N RBridges in the group, it could typically control 1240 1/Nth of the traffic flowing out of that group and a similar amount 1241 of unicast traffic flowing into that group. For multi-destination 1242 traffic flowing into that group, it could control all that was in a 1243 VLAN for which it was DF and it can exercise substantial control over 1244 the DF election by changing its own System ID. 1246 For general TRILL Security Considerations, see [RFC6325]. 1248 13. IANA Considerations 1250 IANA is requested to allocate code points tbd1, tbd2, tbd3 and tbd4 1251 from the range below 255 for the 4 TRILL APPsub-TLVs specified in 1252 Section 9 and add them to the TRILL APPsub-TLV Types registry as 1253 follows: 1255 Type Name Reference 1256 ---- -------------------------- --------------- 1257 tbd1 PN-LAALP-Membership [this document] 1258 tbd2 PN-RBv [this document] 1259 tbd3 PN-MAC-RI-LAALP-INFO-START [this document] 1260 tbd4 PN-MAC-RI-LAALP-INFO-END [this document] 1262 14. Acknowledgments 1264 We would like to thank Mingjiang Chen for his contributions to this 1265 document. Additionally, we would like to thank Erik Nordmark, Les 1266 Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan 1267 Pathang, Jon Hudson and Fangwei Hu for their good questions and 1268 comments. 1270 15. Contributing Authors 1272 Weiguo Hao 1273 Huawei Technologies 1274 101 Software Avenue, 1275 Nanjing 210012 1276 China 1278 Phone: +86-25-56623144 1279 Email: haoweiguo@huawei.com 1280 Donald E. Eastlake, III 1281 Huawei Technologies 1282 155 Beaver Street 1283 Milford, MA 01757 USA 1285 Phone: +1-508-333-2270 1286 Email: d3e3e3@gmail.com 1288 16. References 1290 16.1. Normative References 1292 [CMT] T. Senevirathne, J. Pathangi, and J. Hudson, "Coordinated 1293 Multicast Trees (CMT) for TRILL", draft-ietf-trill-cmt 1294 Work in Progress. 1296 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1297 Requirement Levels", BCP 14, RFC 2119, March 1997. 1299 [RFC5310] M. Bhatia, V. Manral, T. Li, et al, "IS-IS Generic 1300 Cryptographic Authentication", RFC 5310, February 2009. 1302 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 1303 Systems", RFC 6165, April 2011. 1305 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1306 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1308 [RFC6325] R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. 1309 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1310 Specification", RFC 6325, July 2011. 1312 [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. 1313 Hu, "Routing Bridges (RBridges): Appointed Forwarders", 1314 RFC 6439, November 2011. 1316 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 1317 D. Dutt, "Transparent Interconnection of Lots of Links 1318 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 1320 [RFC7176] D. Eastlake, A. Banerjee, A. Ghanwani, and R. Perlman, 1321 "Transparent Interconnection of Lots of Links (TRILL) Use 1322 of IS-IS", RFC 7176, May 2014. 1324 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1325 Stokes, "Transparent Interconnection of Lots of Links 1326 (TRILL): End Station Address Distribution Information 1327 (ESADI) Protocol", RFC 7357, September 2014. 1329 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1330 Scope Link State PDUs (LSPs)", RFC 7356, September 2014. 1332 [rfc7180bis] D. Eastlake, et al., draft-ietf-trill-rfc7180bis, work 1333 in progress. 1335 [802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area/ 1336 networks Link Aggregation", IEEE Std 802.1AX-2014, 24 1337 December 2014. 1339 16.2. Informative References 1341 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Information 1342 technology -- Telecommunications and information exchange 1343 between systems -- Intermediate System to Intermediate 1344 System intra-domain routeing information exchange protocol 1345 for use in conjunction with the protocol for providing the 1346 connectionless-mode network service (ISO 8473)", 2002. 1348 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 1349 3rd, "Transparent Interconnection of Lots of Links (TRILL) 1350 Operations, Administration, and Maintenance (OAM) 1351 Framework", RFC 7174, May 2014. 1353 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 1354 "Problem Statement and Goals for Active-Active Connection 1355 at the Transparent Interconnection of Lots of Links 1356 (TRILL) Edge", RFC 7379, October 2014. 1358 [MultiAttach] Zhang, M., et al, "TRILL Active-Active Edge Using 1359 Multiple MAC Attachments", draft-ietf-trill-aa-multi- 1360 attach, Work in Progress. 1362 Authors' Addresses 1364 Hongjun Zhai 1365 Jinling Institute of Technology 1366 99 Hongjing Avenue, Jiangning District 1367 Nanjing, Jiangsu 211169 1368 China 1370 Email: honjun.zhai@tom.com 1372 Tissa Senevirathne 1373 Consultant 1374 Email: tsenevir@gmail.com 1376 Radia Perlman 1377 EMC 1378 2010 256th Avenue NE, #200 1379 Bellevue, WA 98007 1380 USA 1382 Email: Radia@alum.mit.edu 1384 Mingui Zhang 1385 Huawei Technologies 1386 Huawei Building, No.156 Beiqing Rd. 1387 Beijing, Beijing 100095 1388 China 1390 Email: zhangmingui@huawei.com 1392 Yizhou Li 1393 Huawei Technologies 1394 101 Software Avenue, 1395 Nanjing 210012 1396 China 1398 Phone: +86-25-56625409 1399 Email: liyizhou@huawei.com