idnits 2.17.1 draft-ietf-trill-centralized-replication-05.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 11 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 115: '... MUST use this pseudo-nickname rathe...' RFC 2119 keyword, line 134: '...fic to a centralized node, that SHOULD...' RFC 2119 keyword, line 163: '...ized node. The centralized node SHOULD...' RFC 2119 keyword, line 183: '...r TRILL base protocol. It SHOULD use a...' RFC 2119 keyword, line 464: '...ion solution, edge group RBridges MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 46 has weird spacing: '... months and ...' -- The document date (March 08, 2016) is 2943 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) == Missing Reference: 'RFC2119' is mentioned on line 147, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group W. Hao 2 INTERNET-DRAFT Y. Li 3 Intended Status: Standard Track Huawei Technologies 4 M. Durrani 5 Cisco 6 S. Gupta 7 IP Infusion 8 A. Qu 9 MediaTec 10 T. Han 11 Huawei Technologies 12 Expires: September 2016 March 08, 2016 14 Centralized Replication for Active-Active BUM Traffic 15 draft-ietf-trill-centralized-replication-05.txt 17 Abstract 19 In TRILL active-active access, an RPF check failure issue may occur 20 when using the pseudo-nickname mechanism specified in RFC 7781. This 21 draft describes a solution to resolve this RPF check failure issue 22 through centralized replication. All ingress RBridges send BUM 23 (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized 24 node with unicast TRILL encapsulation. When the centralized node 25 receives the BUM traffic, it decapsulates the packets and forwards 26 them to all destination RBridges using a distribution tree 27 established as per TRILL base protocol RFC 6325. To avoid RPF check 28 failure on a RBridge sitting between the ingress RBridge and the 29 centralized replication node, some change in the RPF calculation 30 algorithm is required. RPF calculation on each RBridge should use 31 the centralized node as the ingress RBridge, instead of the real 32 ingress RBridge, which is denoted as RBv in RFC 7781, to perform the 33 calculation. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with 38 the provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other 47 documents at any time. It is inappropriate to use Internet-Drafts 48 as reference material or to cite them other than as "work in 49 progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction ................................................ 3 75 2. Conventions used in this document ............................ 4 76 3. Centralized Replication Solution Overview .................... 4 77 4. Frame duplication from remote RBridge ........................ 6 78 5. Local forwarding behavior on ingress RBridge ................. 6 79 6. Loop prevention among RBridges in a edge group ............... 7 80 7. Centralized replication forwarding process ................... 8 81 8. BUM traffic loadbalancing among multiple centralized nodes... 10 82 9. Co-existing with the CMT solution ........................... 11 83 10. Network Upgrade Analysis ................................... 12 84 11. TRILL protocol extension ................................... 12 85 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV...... 12 86 12. Security Considerations .................................... 13 87 13. IANA Considerations ........................................ 13 88 14. References ................................................ 13 89 14.1. Normative References .................................. 13 90 14.2. Informative References ................................ 14 91 15. Acknowledgments ........................................... 14 93 1. Introduction 95 The IETF TRILL (Transparent Interconnection of Lots of Links) 96 [RFC6325] protocol provides loop free and per hop based multipath 97 data forwarding with minimum configuration. TRILL uses IS-IS 98 [RFC6165] [RFC7176] as its control plane routing protocol and 99 defines a TRILL specific header for user data. 101 In active-active, Classic Ethernet (CE) devices typically are multi- 102 homed to edge RBridges which form an edge group. All of the uplinks 103 from CE are handled via a Local Active-Active Link Protocol (LAALP 104 [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or 105 Distributed Resilient Network Interconnect (DRNI) [802.1AX]. An 106 active-active flow-based load sharing mechanism is normally 107 implemented to achieve better load balancing and high reliability. A 108 CE device can be a layer 3 end system by itself or a bridge switch 109 through which layer 3 end systems access to TRILL campus. 111 In active-active access, the pseudo-nickname solution in [RFC7781] 112 can be used to avoid MAC flip-flop on remote RBridges. The basic 113 idea is to use a virtual RBridge RBv with a single pseudo-nickname 114 to represent an edge group. Any member RBridge of that edge group 115 MUST use this pseudo-nickname rather than its own nickname as the 116 ingress nickname when it injects TRILL data frames to TRILL campus. 117 The use of the nickname solves the address flip flop issue by 118 binding the MAC address learnt by remote RBridge to the pseudo- 119 nickname. However, it introduces another issue of incorrect packet 120 dropping which will be described as follows: When a pseudo-nickname 121 is used by an edge RBridge as the ingress nickname to forward BUM 122 traffic, any RBridges (RBn) sitting between the ingress RBridge and 123 the distribution tree root will treat the traffic as if it was 124 ingressed from the virtual RBridge RBv. If the same distribution 125 tree is used by different edge RBridges of the same RBv, the traffic 126 may arrive at RBn from different ports. Then the RPF check fails, 127 and the BUM traffic received from unexpected ports will be dropped 128 by RBn. 130 This document proposes a centralized replication solution for 131 broadcast, unknown unicast and multicast (BUM) traffic forwarding to 132 resolve the issue of incorrect packet drop caused by RPF check 133 failure in the virtual RBridge case. The basic idea is that all 134 ingress RBridges send BUM traffic to a centralized node, that SHOULD 135 be a distribution tree root, using unicast TRILL encapsulation. When 136 the centralized node receives the packets, it decapsulates and 137 forwards them to all destination RBridges using a distribution tree 138 established as per the TRILL base protocol. 140 2. Conventions used in this document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC-2119 145 [RFC2119].The acronyms and terminology in [RFC6325] is used herein 146 with the following additions: 148 BUM - Broadcast, Unknown unicast and Multicast 150 CE - As in [RFC7783], Classic Ethernet device (end station or 151 bridge). The device can be either physical or virtual equipment. 153 FGL - Fine Grained Label [RFC7172]. 155 LAALP - Local Active-Active Link Protocol [RFC7379]. 157 MC-LAG - Multi-Chassis Link Aggregation. 159 3. Centralized Replication Solution Overview 161 When an edge RBridge receives BUM traffic from a CE device, it uses 162 unicast TRILL encapsulation instead of multicast encapsulation to 163 send the packets to a centralized node. The centralized node SHOULD 164 be a distribution tree root. 166 The TRILL header of the unicast TRILL encapsulation contains an 167 "ingress RBridge nickname" field and an "egress RBridge nickname" 168 field. If the ingress RBridge receives the BUM packet from a port 169 which is in an active-active edge group, it should set the ingress 170 RBridge nickname to be the pseudo-nickname rather than its own 171 nickname to avoid MAC flip-flop on remote RBridges as per [RFC7781]. 173 The egress RBridge nickname is set to the special nickname of the 174 centralized node which is used to differentiate the centralized 175 replication purpose unicast TRILL encapsulation from a normal 176 unicast TRILL encapsulation. The special nickname is called an R- 177 nickname. 179 When the centralized RBridge receives a unicast TRILL encapsulated 180 packet with its R-nickname as egress nickname, it decapsulates the 181 packet. Then the centralized RBridge replicates and forwards the BUM 182 packet to all destination RBridges using one of the distribution 183 trees established as per TRILL base protocol. It SHOULD use a 184 distribution tree whose tree root is the centralized RBridge itself. 185 When the centralized RBridge forwards the BUM traffic, the ingress 186 nickname remains same as that in the packet it received to ensure 187 that the MAC address learning by all egress RBridges is bound to the 188 pseudo-nickname. 190 When the replicated packet is forwarded by each RBridge along the 191 distribution tree starting from the centralized node, the RPF check 192 will be performed as per [RFC6325]. For any RBridge sitting between 193 the ingress RBridge and the centralized replication node, the 194 incoming port of such BUM packet should be the centralized node 195 facing port as the multicast traffic always comes from the 196 centralized node in this solution. However the RPF port as the 197 result of distribution tree calculation as per [RFC6325] will be the 198 real ingress RBridge facing port as it uses virtual RBridge as the 199 ingress RBridge, so the RPF check will fail. To solve this problem, 200 some change in the RPF calculation algorithm is required. The RPF 201 calculation on each RBridge should use the centralized node as the 202 ingress RBridge instead of the real ingress virtual RBridge to 203 perform the calculation. As a result, RPF check will accept traffic 204 on the centralized node facing port of the RBridge for multi- 205 destination traffic. This prevents incorrect frame drops by the RPF 206 check. 208 To differentiate the centralized replication unicast TRILL 209 encapsulation from normal unicast TRILL encapsulation, the R- 210 nickname is introduced for centralized replication. When the 211 centralized node receives unicast TRILL encapsulation traffic with 212 the egress nickname R-nickname, it decapsulates the packet and then 213 forwards the packet to all destination RBridges through a 214 distribution tree by re-encapsulation as aforementioned. The campus 215 through the TRILL LSP extension specified in Section 11. 217 4. Frame duplication from remote RBridge 219 Frame duplication may occur when a remote host sends a multi- 220 destination frame to a local CE which has an active-active 221 connection to the TRILL campus. To avoid local CE receiving multiple 222 copies from a remote RBridge, the designated forwarder (DF) 223 mechanism is supported for egress direction multicast traffic. 225 The DF election mechanism [RFC7781] allows only one port of one 226 RBridge in an active-active group to forward multicast traffic from 227 the TRILL campus to the local access side for each VLAN. The basic 228 idea of DF is to elect one RBridge per VLAN from an edge group to be 229 responsible for egressing the BUM traffic. [RFC7781] describes the 230 detailed DF election mechanism among member RBridges involving in an 231 edge group. 233 If the DF election mechanism is used for frame duplication 234 prevention, access ports on an RBridge are categorized as three 235 types: non-group, group DF port and group non-DF port. The last two 236 types can be called group ports. Each of the group ports is 237 associated with a pseudo-nickname. If consistent nickname allocation 238 to edge group RBridges is used, it is possible that same pseudo- 239 nickname is associated with more than one port on a single RBridge. 240 A typical scenario is that CE1 is connected to RB1 & RB2 by LAALP1 241 while CE2 is connected to RB1 & RB2 by LAALP2. In order to conserve 242 the number of pseudo-nicknames used, member ports for both LAALP1 243 and LAALP2 on RB1 & RB2 are all associated with the same pseudo- 244 nickname. 246 5. Local forwarding behavior on ingress RBridge 248 When an ingress RBridge (RB1) receives BUM traffic from a local 249 active-active accessing CE (CE1) device, the traffic will be 250 injected into the TRILL campus with TRILL encapsulation, and it will 251 be replicated and forwarded to all destination RBridges through 252 central replication, including the ingress RBridge itself, along a 253 TRILL distribution tree. To avoid the traffic looping back to the 254 original sender CE, an ingress nickname of the CE group's pseudo- 255 nickname can be used for traffic filtering. 257 However, if there are two CEs, say CE1 and CE2, connecting to the 258 ingress RB1 and each associated with same pseudo-nickname, RB1 needs 259 to locally replicate and forward to CE2, because another copy of the 260 BUM traffic between CE1 and CE2 through TRILL campus will be blocked 261 by the traffic filtering. 263 If CE1 and CE2 are not associated with same pseudo-nickname, the 264 copy of the BUM traffic between CE1 and CE2 through TRILL campus 265 won't be blocked by the traffic filtering. To avoid duplicated 266 traffic on receiver CE, there should be no local replicated BUM 267 traffic between these two CEs on ingress RB1. 269 In summary, to ensure correct BUM traffic forwarding behavior for 270 each CE, the local replication behavior on ingress RBridge should be 271 carefully designed as follows: 273 1. Replicate to the ports associated with the same pseudo- 274 nickname as that associated to the incoming port. 276 2. Do not replicate to active-active group ports associated with 277 different pseudo-nicknames. 279 3. Do not replicate to non-edge-group ports. 281 The above local forwarding behavior on the ingress RBridge of RB1 282 can be called centralized replication local forwarding behavior A. 284 If ingress RBridge RB1 itself is the centralized replication node, 285 BUM traffic injected by RB1 to the TRILL campus won't loop back to 286 RB1. In this case, the local forwarding behavior is called 287 centralized replication local forwarding behavior B. Behavior B on 288 RB1 is as follows: 290 1. Local replication to the ports associated with the same 291 pseudo-nickname as that associated to the incoming port. 293 2. Local replication to the group DF port associated with 294 different pseudo-nicknames. Do not replicate to group non-DF port 295 associated with different pseudo-nicknames. 297 3. Local replication to non-edge-group ports. 299 6. Loop prevention among RBridges in a edge group 301 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 302 packet through a DF port to an ingress RBridge, that RBridge will 303 forward that packet to all or a subset of the other RBridges that 304 only have non-DF ports for that active-active group. Because BUM 305 traffic forwarding to non-DF ports isn't allowed, in this case the 306 frame won't loop back to the CE. 308 If a CE sends a BUM packet through a non-DF port to a ingress 309 RBridge, say RB1, then RB1 will forward that packet to other 310 RBridges that have a DF port for that active-active group. In this 311 case the frame will loop back to the CE and the traffic split- 312 horizon filtering mechanism is used to avoid looping back among 313 RBridges in the edge group. 315 This split-horizon mechanism relies on the ingress nickname to check 316 if a packet's egress port belongs to a same active-active group as 317 the packet's incoming port to the TRILL campus. 319 When the ingress RBridge receives BUM traffic from an active-active 320 accessing CE device, the traffic will be injected into the TRILL 321 campus with TRILL encapsulation, and it will be replicated and 322 forwarded to all destination RBridges, which include ingress RBridge 323 itself, through a TRILL distribution tree. If the same pseudo- 324 nickname is used for two active-active access CEs as ingress 325 nickname, an egress RBridge can use that nickname to filter traffic 326 forwarding to all local CEs. In this case, the traffic between these 327 two CEs goes through the local RBridge and another copy of the 328 traffic from the TRILL campus is filtered. If different ingress 329 nicknames are used for two connecting CE devices, the access ports 330 connecting to these two CEs should be isolated from each other. The 331 BUM traffic between these two CEs should go through the TRILL campus, 332 otherwise the destination CE connected to same RBridge with the 333 sender CE will receive two copies of the traffic. 335 7. Centralized replication forwarding process 336 +-----------+ 337 | (RB5) | 338 +-----------+ 339 | 340 +-----------+ 341 | (RB4) | 342 +-----------+ 344 | | | 345 -------- | -------- 346 | | | 347 +------+ +------+ +------+ 348 |(RB1) | |(RB2) | | (RB3)| 349 +------+ +------+ +------+ 350 * | * | * | ^ 351 * | * | * | ^ 352 * ----------*-------------*-- ^ 353 ***************************** | ^ 354 LAALP1 * LAALP2 | ^ 355 +------+ +------+ +------+ 356 | CE1 | | CE2 | | CE3 | 357 +------+ +------+ +------+ 358 Figure 1 TRILL Active-active access 360 Assuming the centralized replication solution is used in the example 361 network of above figure 1, RB5 is the distribution tree root and 362 centralized replication node, CE1 and CE2 are active-active accessed 363 to RB1,RB2 and RB3 through LAALP1 and LAALP2 respectively, CE3 is 364 single homed to RB3. The RBridge's own nickname of RB1 to RB5 are 365 nick1 to nick5 respectively. RB1, RB2, and RB3 use the same pseudo- 366 nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The 367 R-nickname on the centralized replication node of RB5 is S-nick. 369 The BUM traffic forwarding process from CE1 to CE2 and CE3 is as 370 follows: 372 1. CE1 sends BUM traffic to RB3. 374 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 375 also sends the traffic to RB5 using unicast TRILL encapsulation. In 376 the TRILL Header, the ingress nickname is set as P-nick and the 377 egress nickname is set as S-nick. 379 3. RB5 decapsulates the unicast TRILL Data packet. Then it uses 380 the distribution tree whose root is RB5 to forward the packet as a 381 multi-destination TRILL Data packet. The egress nickname in the 382 multi-destination TRILL Header is the nick5and the ingress nickname 383 is still P-nick. 385 4. RB4 receives multicast TRILL traffic from RB5. Traffic 386 incoming port is the up port facing the distribution tree root, 387 RB4's RPF check will be correct based on the changed RPF port 388 calculation algorithm in this document. After the RPF check is 389 performed, it forwards the traffic to all other egress RBridges(RB1, 390 RB2, and RB3). 392 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 393 the multi-destination TRILL Data packet. Because the ingress 394 nickname of P-nick is equivalent to the nickname of local LAALPs 395 connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 396 and CE2 to avoid duplicated frame. RB3 only forwards the packet to 397 CE3. 399 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 400 forwarding process is similar to the process on RB3, i.e, because 401 the ingress nickname of P-nick is equivalent to the nickname of the 402 local LAALPs connecting CE1 and CE2, they also don't forward the 403 traffic to local CE1 and CE2. 405 8. BUM traffic loadbalancing among multiple centralized nodes 407 To support unicast TRILL encapsulation BUM traffic load balancing, 408 multiple centralized replication nodes can be deployed and the 409 traffic can be load balanced between these nodes based on VLAN or 410 FGL. 412 Assuming there are k centralized nodes in TRILL campus, each 413 centralized node has a different R-nickname, the VLAN-based (or FGL- 414 based [RFC7172]) load balancing algorithm used by ingress active- 415 active access RBridge is as follows: 417 1. All R-nicknames are ordered and numbered from 0 to k-1 in 418 ascending order treating the nicknames as unsigned 16-bit integers. 420 2. For VLAN or FGL ID m, choose the R-nickname whose number 421 equals (m mod k) as egress nickname for BUM traffic unicast TRILL 422 encapsulation. 424 For examples, there are 3 centralized nodes (CN) each having one R- 425 nickname. The CN nodes will be ordered based on the R-nickname from 426 CN0 to CN2. Assuming there are 5 VLANs from VLAN ID 1 to OD 5 427 spreading among edge RBridges, the traffic in VLAN 1 will go to CN1, 428 VLAN 2 will go to CN2, and so on. 430 When an ingress RBridge participating in active-active connection 431 receives BUM traffic from local CE, the RBridge decides which 432 centralized node to send the traffic to based on the VLAN-based load 433 balancing algorithm, thus VLAN/FGL-based load balancing for the BUM 434 traffic can be achieved among multiple centralized nodes. 436 9. Co-existing with the CMT solution 438 +------+ +------+ 439 |(RB6) | |(RB7) | 440 +------+ +------+ 441 ------------------|-----------|---------------------- 442 | | | | | 443 +------+ +------+ +------+ +------+ +------+ 444 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 445 +------+ +------+ +------+ +------+ +------+ 446 | | | | | 447 ------------ ------------------------- 448 | | 449 +------+ +------+ 450 | CE1 | | CE2 | 451 +------+ +------+ 452 Figure 1 CMT and centralized replication co-existing scenario 454 Both the centralized replication solution and the CMT [RFC7783] 455 solution rely on using pseudo-nicknames to avoid MAC flip-flop on 456 remote RBridges. These two solutions can co-exist in a single TRILL 457 campus. Each solution can be selected by each active-active edge 458 group of RBridges independently. 460 As illustrated in figure 2, RB1 and RB2 use CMT for CE1's active- 461 active access, RB3, RB4, and RB5 use the centralized replication for 462 CE2's active-active access. 464 For the centralized replication solution, edge group RBridges MUST 465 announce the local pseudo-nickname using Nickname Flags APPsub-TLV 466 with C-flag. A nickname with the C-flag set is called a "C-nickname". 467 A transit RBridge will perform the centralized replication specific 468 RPF check algorithm if it receives TRILL Data packets with a C- 469 nickname as ingress nickname. 471 10. Network Upgrade Analysis 473 Centralized nodes will typically need software and hardware upgrades 474 to support centralized replication, which stitches TRILL unicast 475 traffic decapsulation process and the process of normal TRILL 476 multicast traffic forwarding along distribution tree. 478 Active-active connection edge RBridges will typically need software 479 and hardware upgrade to support unicast TRILL encapsulation for BUM 480 traffic; the process is similar to other head-end replication 481 processes. 483 Transit nodes typically need a software upgrade to support the 484 changed RPF port calculation algorithm. 486 11. TRILL protocol extension 488 Two Flags of "R" and "C" are specified in the Nickname Flags APPsub- 489 TLV [RFC7780]. The nickname with "R" flag set is called the R- 490 nickname and the nickname with the "C" flag set is called the C- 491 nickname. The R-nickname is a specialized nickname attached on a 492 centralized node to differentiate unicast TRILL encapsulation BUM 493 traffic from normal unicast TRILL traffic. The C-nickname flag is 494 set on each edge group RBridge, C-nickname is a specialized pseudo- 495 nickname for which transit RBridges perform a different RPF check 496 algorithm. 498 When active-active edge RBridges use centralized replication to 499 forward BUM traffic, the R-nickname is used as the egress nickname 500 and the C-nickname is used as ingress nickname in the TRILL header 501 for the unicast TRILL encapsulation of BUM traffic. 503 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV 505 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 506 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 507 | Nickname | 508 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 509 |IN|SE|R | C| RESV | 510 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 511 NICKFLAG RECORD 513 o R = If R flag is one, it indicates that the advertising 514 TRILL switch is a centralized replication node, and the nickname is 515 used as egress nickname for edge group RBridges to inject BUM 516 traffic to TRILL campus when the edge group RBridges use centralized 517 replication solution for active-active access. If flag is zero, that 518 nickname will not be used for that purpose. 520 o C = If C flag is one, it indicates that the TRILL traffic 521 with this nickname as an ingress nickname requires the special RPF 522 check algorithm. If flag is zero, that nickname will not be used for 523 that purpose. 525 12. Security Considerations 527 This draft does not introduce any extra security risks. For general 528 TRILL Security Considerations, see [RFC6325]. For Security 529 Considerations related to pseudo-nickname active-active, see 530 [RFC7781]. 532 13. IANA Considerations 534 IANA is requested to assign two bits in the Nickname Flags APPsubTLV 535 flags for the R and C bits discussed in Section 11.1 [Bits 3 and 4 536 suggested] and update the ''NickFlags'' Bits registry on the TRILL 537 Parameters page as follows: 539 Bit Mnemonic Description Reference 540 --- -------- -------------------- ----------- 541 3 R Replication Nickname [This document] 542 4 C Special RFC Check [This document] 544 14. References 546 14.1. Normative References 548 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 549 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, . 552 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 553 Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 554 6325, DOI 10.17487/RFC6325, July 2011, . 557 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. 558 Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained 559 Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, . 562 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and 563 A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of 564 IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, . 567 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 568 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links 569 (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 570 10.17487/RFC7780, February 2016, . 572 14.2. Informative References 574 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, 575 "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for 576 Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, 577 . 579 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem 580 Statement and Goals for Active-Active Connection at the Transparent 581 Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 582 10.17487/RFC7379, October 2014, . 584 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated 585 Multicast Trees (CMT) for Transparent Interconnection of Lots of Links 586 (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, . 589 15. Acknowledgments 591 The authors wish to acknowledge the important contributions of 592 Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia. 594 Authors' Addresses 596 Weiguo Hao 597 Huawei Technologies 598 101 Software Avenue, 599 Nanjing 210012 600 China 601 Email: haoweiguo@huawei.com 603 Yizhou Li 604 Huawei Technologies 605 101 Software Avenue, 606 Nanjing 210012 607 China 608 Email: liyizhou@huawei.com 610 Muhammad Durrani 611 Cisco 612 Email: mdurrani@cisco.com 614 Sujay Gupta 615 IP Infusion 616 RMZ Centennial 617 Mahadevapura Post 618 Bangalore - 560048 619 India 620 Email: sujay.gupta@ipinfusion.com 622 Andrew Qu 623 MediaTec 624 Email: laodulaodu@gmail.com 626 Tao Han 627 Huawei Technologies 628 101 Software Avenue, 629 Nanjing 210012 630 China 631 Email: billow.han@huawei.com