idnits 2.17.1 draft-ietf-trill-centralized-replication-09.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 too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 43 has weird spacing: '... months and ...' == Line 105 has weird spacing: '...chanism can a...' -- The document date (October 27, 2017) is 2373 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: 'RFC7370' is mentioned on line 163, but not defined Summary: 1 error (**), 0 flaws (~~), 4 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: Standards Track Huawei Technologies 4 M. Durrani 5 Cisco 6 S. Gupta 7 IP Infusion 8 A. Qu 9 MediaTec 10 Expires: May 2018 October 27, 2017 12 Centralized Replication for Active-Active BUM Traffic 13 draft-ietf-trill-centralized-replication-09.txt 15 Abstract 17 In TRILL active-active access, an RPF check failure issue may occur 18 when using the pseudo-nickname mechanism specified in RFC 7781. This 19 draft describes a solution to resolve this RPF check failure issue 20 through centralized replication. All ingress RBridges send BUM 21 (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized 22 node with unicast TRILL encapsulation. When the centralized node 23 receives the BUM traffic, it decapsulates the packets and forwards 24 them to their destination RBridges using a distribution tree 25 established as per TRILL base protocol RFC 6325. To avoid RPF check 26 failure on a RBridge sitting between the ingress RBridge and the 27 centralized replication node, some change in the RPF calculation 28 algorithm is required. RPF checks on each RBridge should be calculated 29 as if the centralized node was the ingress RBridge, instead of being 30 calculated using the actual ingress RBridge. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with 35 the provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other 44 documents at any time. It is inappropriate to use Internet-Drafts 45 as reference material or to cite them other than as "work in 46 progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction ................................................3 72 2. Conventions used in this document............................4 73 3. Centralized Replication Solution Overview....................4 74 4. Frame duplication from remote RBridge........................6 75 5. Local forwarding behavior on ingress RBridge.................7 76 6. Loop prevention among RBridges in a edge group...............8 77 7. Centralized replication forwarding process...................9 78 8. BUM traffic load balancing among multiple centralized nodes..10 79 9. Co-existing with the CMT solution........................... 11 80 10. Network Upgrade Analysis................................... 12 81 11. TRILL protocol extensions.................................. 13 82 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV......13 84 12. Security Considerations.................................... 14 85 13. IANA Considerations........................................ 14 86 14. References ................................................ 15 87 14.1. Normative References.................................. 15 88 14.2. Informative References................................ 15 89 15. Acknowledgments ........................................... 16 91 1. Introduction 93 The IETF TRILL (Transparent Interconnection of Lots of Links) 94 [RFC6325] protocol provides loop free and per hop based multipath 95 data forwarding with minimum configuration. TRILL uses IS-IS 96 [RFC6165] [RFC7176] as its control plane routing protocol and 97 defines a TRILL specific header for user data. 99 Customer Equipment (CE) devices can be multi-homed to a set of edge 100 RBridges forming an edge group where active-active service can be 101 provided. In that case, all of the uplinks from a CE are handled via 102 a Local Active-Active Link Protocol (LAALP [RFC7379]) such as Multi- 103 Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network 104 Interconnect (DRNI) [802.1AX]. An active-active flow-based load 105 sharing mechanism can achieve better load balancing and high 106 reliability. A CE device can be a layer 3 end system by itself or a 107 bridge switch through which layer 3 end systems access to TRILL 108 campus. 110 In active-active access, the pseudo-nickname solution in [RFC7781] 111 can be used to avoid MAC flip-flop on remote RBridges. The basic 112 idea is to use a virtual RBridge RBv with a single pseudo-nickname 113 to represent an edge group. Any member RBridge of that edge group 114 uses this pseudo-nickname rather than its own nickname as the 115 ingress nickname when it injects TRILL data frames to TRILL campus. 116 The use of the nickname solves the address flip-flop issue by 117 setting the MAC address learnt by a remote RBridge to the pseudo- 118 nickname. However, it introduces another issue of incorrect packet 119 dropping as follows: When a pseudo-nickname is used by an edge 120 RBridge as the ingress nickname to forward BUM (Broadcast, Unknown 121 unicast and Mutlicast) traffic, any RBridges (RBn) sitting between 122 the ingress RBridge and the distribution tree root will treat the 123 traffic as if it was ingressed from the virtual RBridge RBv. If the 124 same distribution tree is used by different edge RBridges of the 125 same RBv, the traffic may arrive at some RBn from different ports. 126 Then the RPF (Reverse Path Forwarding) check required by TRILL 127 [RFC6325] fails, and the BUM traffic received on unexpected ports 128 will be dropped by RBn. 130 This document specifies 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 the 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, which 135 SHOULD be a distribution tree root, using unicast TRILL 136 encapsulation. When the centralized node receives the packets, it 137 decapsulates and forwards them to their destination RBridges using a 138 distribution tree 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 [RFC2119]. 145 The acronyms and terminology in [RFC6325] are used herein with the 146 following additions: 148 BUM - Broadcast, Unknown unicast, and Multicast 150 CE - As in [RFC7783], Customer Equipment device (end station or 151 bridge). The device can be either physical or virtual equipment. 153 Data Label - VLAN or FGL [RFC7172] 155 DF - Designated Forwarder [RFC7781] 157 FGL - Fine Grained Label [RFC7172]. 159 LAALP -Local Active-Active Link Protocol [RFC7379]. 161 MAC flip flop - A problem where the attachment point of a MAC 162 address appears to a remote switch to keep changing. See Section 3.3 163 of [RFC7370]. 165 MC-LAG - Multi-Chassis Link Aggregation. 167 RPF - Reverse Path Forwarding. 169 3. Centralized Replication Solution Overview 171 When an edge RBridge receives BUM traffic from a CE device, it uses 172 unicast TRILL encapsulation instead of multicast encapsulation to 173 send the packets to a centralized node. The centralized node MUST be 174 a distribution tree root. Distribution tree roots are normally 175 chosen to be high capacity core RBridges with many high bandwidth 176 adjacencies and this constraint makes its practical, as described 177 below, to support centralized replication with only software changes 178 to transit RBridges. 180 The TRILL header of the unicast TRILL encapsulation contains an 181 "ingress RBridge nickname" field and an "egress RBridge nickname" 182 field [RFC6325]. If the ingress RBridge receives the BUM packet from 183 a port that is in an active-active edge group using [RFC7781], it 184 sets the ingress RBridge nickname to be the pseudo-nickname rather 185 than its own nickname to avoid MAC flip-flop (see Section 3.3 of 186 [RFC7379]) on remote RBridges. The egress RBridge nickname is set to 187 a special nickname of the centralized node which is used to 188 differentiate the centralized replication purpose unicast TRILL 189 encapsulation from a normal unicast TRILL encapsulation. This 190 special nickname is called an R-nickname. 192 When the centralized RBridge receives a unicast TRILL encapsulated 193 packet with its R-nickname as egress nickname, it decapsulates the 194 packet. Then the centralized RBridge replicates and forwards the BUM 195 packet to the packet's destination RBridges using one of the 196 distribution trees established as per TRILL base protocol. It MUST 197 use a distribution tree whose tree root is the centralized RBridge 198 itself. (An RBridge may by the root of more than one tree.) When the 199 centralized RBridge forwards the BUM traffic, it simply sends it on 200 the distribution tree as if it was a locally ingressed frame except 201 that the ingress nickname remains the same as that in the packet it 202 received to ensure that the MAC address learning by all egress 203 RBridges is bound to the pseudo-nickname. 205 When the replicated packet is forwarded by each RBridge along the 206 distribution tree starting from the centralized node, an RPF check 207 is performed as per [RFC6325]. For any RBridge sitting between the 208 ingress RBridge and the centralized replication node, the incoming 209 port of such BUM packet should be the centralized node facing port 210 as the multicast traffic always comes from the centralized node in 211 this solution. However the RPF port as the result of distribution 212 tree calculation as specified in [RFC6325] will be the real ingress 213 RBridge facing port as it uses the edge group's virtual RBridge as 214 the ingress RBridge, so the RPF check will fail. 216 To solve this problem, some change in the RPF test is required. In 217 this case, the RPF calculation on each RBridge should use the 218 centralized node as the ingress RBridge for each tree for which that 219 node is the root instead of the real ingress virtual RBridge to 220 perform the calculation. As a result, RPF check will accept traffic 221 on the centralized node facing port of the RBridge for multi- 222 destination traffic. This prevents incorrect frame drops by the RPF 223 check. 225 The change in the actual RPF check on a received multi-destination 226 TRILL data packet is easy. The [RFC6325] RPF check is a check to see 227 if a triple of {ingress nickname, tree, receiving RBridge port} is 228 allowed. (The tree is indicted by the nickname of its root which is 229 stored in the TRILL Header "egress nickname" field.) When 230 determining the RFC check, if "ingress nickname" is a C-nickname, 231 then the check based on distribution from the tree root. If "ingress 232 nickname" is not a C-nickname, then the check is based on 233 distribution from the RBridge having the ingress nickname. 235 To differentiate the centralized replication unicast TRILL 236 encapsulation from normal unicast TRILL encapsulation, the R- 237 nickname is introduced for centralized replication. When the 238 centralized node receives unicast TRILL encapsulation traffic with 239 the egress nickname R-nickname, it decapsulates the packet and then 240 forwards the packet to the destination RBridges through a 241 distribution tree for which it is the root by re-encapsulation as 242 aforementioned. In TRILL, RBridges can hold multiple nicknames so 243 the centralized RBridge simply obtains another nickname to use as 244 the R-nickname. The centralized RBridge or RBridges should announce 245 their R-nickname to all TRILL campus through the TRILL LSP extension 246 specified in Section 11. 248 4. Frame duplication from remote RBridge 250 Frame duplication may occur when a remote host sends a multi- 251 destination frame to a local CE which has an active-active 252 connection to the TRILL campus. To avoid local CE receiving multiple 253 copies from a remote RBridge, the designated forwarder (DF) 254 mechanism is supported for egress direction multicast traffic. 256 The DF election mechanism [RFC7781] allows only one port of one 257 RBridge in an active-active group to forward multicast traffic from 258 the TRILL campus to the local access side for each VLAN. The basic 259 idea of DF is to elect one RBridge per VLAN from an edge group to be 260 responsible for egressing the BUM traffic. [RFC7781] describes the 261 DF election mechanism among member RBridges involving in an edge 262 group. 264 If the DF election mechanism is used for frame duplication 265 prevention, access ports on an RBridge are categorized as one of 266 three types: non-group, group DF port and group non-DF port. The 267 last two types can be called group ports. Each of the group ports is 268 associated with a pseudo-nickname. If consistent nickname allocation 269 to edge group RBridges is used, it is possible that same pseudo- 270 nickname is associated with more than one port on a single RBridge. 271 A typical scenario is that CE1 is connected to RB1 & RB2 by LAALP1 272 while CE2 is connected to RB1 & RB2 by LAALP2. In order to conserve 273 the number of pseudo-nicknames used, member ports for both LAALP1 274 and LAALP2 on RB1 & RB2 are all associated with the same pseudo- 275 nickname. 277 5. Local forwarding behavior on ingress RBridge 279 When an ingress RBridge (RB1) receives BUM traffic from a local 280 active-active connected CE (CE1) device, the traffic will be 281 injected into the TRILL campus with TRILL encapsulation, and it will 282 be replicated and forwarded to all destination RBridges through 283 central replication, including the ingress RBridge itself, along a 284 TRILL distribution tree. To avoid the traffic looping back to the 285 original sender CE, an ingress nickname of the CE group's pseudo- 286 nickname is used for traffic filtering. 288 However, if there are two CEs, say CE1 and CE2, connecting to the 289 ingress RB1 and each associated with the same pseudo-nickname, RB1 290 needs to locally replicate and forward to CE2, because another copy 291 of the BUM traffic between CE1 and CE2 through TRILL campus will be 292 blocked by the traffic filtering. 294 If CE1 and CE2 are not associated with the same pseudo-nickname, the 295 copy of the BUM traffic between CE1 and CE2 through TRILL campus 296 won't be blocked by the traffic filtering. To avoid duplicated 297 traffic on receiver CE, there cannot be local replicated BUM traffic 298 between these two CEs on ingress RB1. 300 In summary, to ensure correct BUM traffic forwarding behavior for 301 each CE, the local replication behavior on the ingress RBridge is as 302 follows: 304 1. Replicate to the active-active group ports associated with the 305 same pseudo-nickname as that associated with the incoming port. 307 2. Do not replicate to active-active group ports associated with 308 other pseudo-nicknames. 310 3. Do not replicate to non-edge-group ports. 312 The above local forwarding behavior on the ingress RBridge of RB1 313 can be called centralized replication local forwarding behavior A. 315 If ingress RBridge RB1 itself is the centralized replication node, 316 BUM traffic injected by RB1 into the TRILL campus won't loop back to 317 RB1. In this case, the local forwarding behavior is called 318 centralized replication local forwarding behavior B. Behavior B on 319 RB1 is as follows: 321 1. Local replication to the ports associated with the same 322 pseudo-nickname as that associated with the incoming port. 324 2. Local replication to the group DF port associated with 325 different pseudo-nicknames. Do not replicate to group non-DF port 326 associated with different pseudo-nicknames. 328 3. Local replication to non-edge-group ports. 330 6. Loop prevention among RBridges in a edge group 332 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 333 packet through a DF port to an ingress RBridge, that RBridge will 334 forward that packet to all or a subset of the other RBridges that 335 only have non-DF ports for that active-active group. Because BUM 336 traffic forwarding to non-DF ports isn't allowed, in this case the 337 frame won't loop back to the CE. 339 If a CE sends a BUM packet through a non-DF port to an ingress 340 RBridge, say RB1, then RB1 will forward that packet to other 341 RBridges that have a DF port for that active-active group. In this 342 case the frame will loop back to the CE and the traffic split- 343 horizon filtering mechanism is used to avoid looping back among 344 RBridges in the edge group. 346 This split-horizon mechanism relies on the ingress nickname field in 347 the TRILL header to check if a packet's egress port belongs to a 348 same active-active group as the packet's incoming port to the TRILL 349 campus. 351 When the ingress RBridge receives BUM traffic from an active-active 352 connected CE device, the traffic will be sent through the TRILL 353 campus with TRILL encapsulation to a centralized RBridge. There it 354 will be replicated and forwarded to its destination RBridges, which 355 include ingress RBridge itself, through a TRILL distribution tree. 356 If the same pseudo-nickname is used for two active-active access CEs 357 as ingress nickname, an egress RBridge can use that nickname to 358 filter traffic forwarding to all local CEs. In this case, the 359 traffic between these two CEs goes through the local RBridge and 360 another copy of the traffic from the TRILL campus is filtered. If 361 different ingress nicknames are used for two connecting CE devices, 362 the access ports connecting to these two CEs should be isolated from 363 each other. The BUM traffic between these two CEs should go through 364 the TRILL campus, otherwise the destination CE connected to same 365 RBridge with the sender CE will receive two copies of the traffic. 367 7. Centralized replication forwarding process 369 +-----------+ 370 | (RB5) | 371 +-----------+ 372 | 373 +-----------+ 374 | (RB4) | 375 +-----------+ 377 | | | 378 -------- | -------- 379 | | | 380 +------+ +------+ +------+ 381 |(RB1) | |(RB2) | | (RB3)| 382 +------+ +------+ +------+ 383 * | * | * | ^ 384 * | * | * | ^ 385 * ----------*-------------*-- ^ 386 ***************************** | ^ 387 LAALP1 * LAALP2 | ^ 388 +------+ +------+ +------+ 389 | CE1 | | CE2 | | CE3 | 390 +------+ +------+ +------+ 391 Figure 1 TRILL Active-active access 393 Assuming the centralized replication solution is used in the example 394 network of above figure 1, RB5 is the distribution tree root and 395 centralized replication node, CE1 and CE2 are active-active accessed 396 to RB1, RB2, and RB3 through LAALP1 and LAALP2 respectively, CE3 is 397 single homed to RB3. The RBridge's own nicknames of RB1 to RB5 are 398 nick1 to nick5 respectively. RB1, RB2, and RB3 use the same pseudo- 399 nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The 400 R-nickname on the centralized replication node of RB5 is S-nick. 402 The BUM traffic forwarding process from CE1 to CE2 and CE3 is as 403 follows: 405 1. CE1 sends BUM traffic to RB3. 407 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 408 also sends the traffic to RB5 using unicast TRILL encapsulation. In 409 the TRILL Header, the ingress nickname is set as P-nick and the 410 egress nickname is set as S-nick. 412 3. RB5 decapsulates the unicast TRILL Data packet. Then it uses a 413 distribution tree for which it is the root to forward the packet as 414 a multi-destination TRILL Data packet. The egress nickname in the 415 multi-destination TRILL Header is the nick5 and the ingress nickname 416 is still P-nick. If RB3 had sent the unicast to some nickname that 417 was not an R-nickname, the packet will not be re-encapsulate. If it 418 is sent to an R-nickname that is not a tree root, it will either be 419 not forwarded at all or, if it is re-encapsulated and forwarded, 420 will be subject to incorrect pruning and will not be delivered to 421 all of its intended recipients. 423 4. RB4 receives multicast TRILL traffic from RB5. Traffic 424 incoming port is the up port facing the distribution tree root, 425 RB4's RPF check will be correct based on the changed RPF port 426 calculation algorithm in this document. After the RPF check is 427 performed, it forwards the traffic to all other egress RBridges (RB1, 428 RB2, and RB3). 430 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 431 the multi-destination TRILL Data packet. Because the ingress 432 nickname of P-nick is equivalent to the nickname of local LAALPs 433 connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 434 and CE2 to avoid duplicated frame. RB3 only forwards the packet to 435 CE3. 437 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 438 forwarding process is similar to the process on RB3, i.e., because 439 the ingress nickname of P-nick is equivalent to the nickname of the 440 local LAALPs connecting CE1 and CE2, they also don't forward the 441 traffic to local CE1 and CE2. 443 8. BUM traffic load balancing among multiple centralized nodes 445 To support unicast TRILL encapsulation BUM traffic load balancing, 446 multiple centralized replication nodes can be deployed and the 447 traffic can be spread over these nodes based on data label (VLAN or FGL). 449 Furthermore, if it was desirable for a centralized node to be sent 450 more of this BUM traffic, it could hold two or more R-nicknames. The 451 share of BUM traffic it would receive would be proportional to the 452 number of R-nicknames it held. 454 Assuming there are k different R-nicknames held by centralized nodes 455 in a TRILL campus. The VLAN-based (or FGL-based [RFC7172]) load 456 balancing algorithm used by ingress active-active access RBridge is 457 as follows: 459 1. All R-nicknames are ordered and numbered from 0 to k-1 in 460 ascending order treating the nicknames as unsigned 16-bit integers. 462 2. For data label ID m, choose the R-nickname whose number equals 463 (m mod k) as egress nickname for BUM traffic unicast TRILL 464 encapsulation. 466 For examples, there are 3 R-Nicknames (RN). The RNs will be ordered 467 RN0 to RN2. Assuming there are 5 VLANs from VLAN ID 1 to ID 5 468 spreading among edge RBridges, the traffic in VLAN 1 will go to RN1, 469 VLAN 2 will go to RN2, and so on. 471 When an ingress RBridge participating in active-active connection 472 receives BUM traffic from local CE, the RBridge decides which R- 473 nickname to send the traffic to based on the VLAN-based load 474 spreading algorithm, thus data-label-based load balancing for the BUM 475 traffic can be achieved using multiple centralized nodes/ multiple 476 R-nicknames. 478 9. Co-existing with the CMT solution 480 +------+ +------+ 481 |(RB6) | |(RB7) | 482 +------+ +------+ 483 ------------------|-----------|---------------------- 484 | | | | | 485 +------+ +------+ +------+ +------+ +------+ 486 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 487 +------+ +------+ +------+ +------+ +------+ 488 | | | | | 489 ------------ ------------------------- 490 | | 491 +------+ +------+ 492 | CE1 | | CE2 | 493 +------+ +------+ 494 Figure 2 CMT and centralized replication co-existing scenario 496 Both the centralized replication solution and the CMT [RFC7783] 497 solution rely on using pseudo-nicknames to avoid MAC flip-flop on 498 remote RBridges. These two solutions can co-exist in a single TRILL 499 campus. Each solution can be selected by each active-active edge 500 group of RBridges independently. 502 As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active- 503 active access, RB3, RB4, and RB5 use the centralized replication for 504 CE2's active-active access. 506 For the centralized replication solution, edge group RBridges MUST 507 announce the local pseudo-nickname using Nickname Flags APPsub-TLV 508 with C-flag set. A nickname with the C-flag set is called a "C- 509 nickname". A transit RBridge will perform the centralized 510 replication specific RPF check algorithm if it receives TRILL Data 511 packets with a C-nickname as ingress nickname. 513 An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag 514 on the pseudo-nickname it is using. This is already mandatory 515 behavior because any RBridge originating a Nickname Flags APPsub-TLV 516 is required by [RFC7780] to set any flag bit it does not know about 517 to zero. If a edge RBridge using CMT [RFC7783] nevertheless set the 518 C-bit for an edge group pseudo-nickname, it is very likely that BUM 519 traffic encapsulated with that nickname as ingress would be 520 incorrectly pruned early in its distribution and would thus reach 521 few (possibly none) of its intended targets. To avoid confusion, a 522 pseudo-nickname MUST NOT be shared between a centralized replication 523 edge group and a CMT-based edge group. 525 10. Network Upgrade Analysis 527 Centralized nodes will typically need software and hardware upgrades 528 to support centralized replication, which stitches together the TRILL 529 unicast traffic decapsulation process and the process of normal 530 TRILL multicast traffic forwarding along distribution tree. 532 Active-active connection edge RBridges will typically need software 533 and hardware upgrade to support unicast TRILL encapsulation for BUM 534 traffic; the process is similar to other head-end replication 535 processes. 537 Transit nodes typically need only a software upgrade to support the 538 changed RPF port calculation algorithm. 540 11. TRILL protocol extensions 542 Two new flags, "R" and "C", are specified in the Nickname Flags 543 APPsub-TLV [RFC7780]. A nickname with the "R" flag set is called an 544 R-nickname and a nickname with the the "C" flag set is called a C- 545 nickname. The R-nickname is a specialized nickname attached to a 546 centralized node to differentiate unicast TRILL encapsulated BUM 547 traffic from normal unicast TRILL traffic. The C-nickname flag is 548 set on the psudo-nickname for each edge group that uses the 549 centralized replication. A C-nickname is a is a specialized pseudo- 550 nickname for which transit RBridges perform a different RPF check 551 algorithm for TRILL data packets with the C-nickname in the ingress 552 nickname field. 554 When active-active edge RBridges use centralized replication to 555 forward BUM traffic, the R-nickname is used as the egress nickname 556 and the C-nickname is used as ingress nickname in the TRILL header 557 for the unicast TRILL encapsulation of BUM traffic. 559 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV 561 If this APPsub-TLV is being advertised by an RBridge that does not 562 have the nickname appearing in the Nickname Flags APPsub-TLV, the R 563 and C flag bits in the APPsub-TLV MUST be treated as if they were 564 zero. If an RBridge that is not a distribution tree root advertises 565 an R-nickname, that nickname MUST NOT be treated as an R-nickname 566 but rather as an ordinary nickname, that is, the R-nickname flag is 567 ignored for all purposes if the nickname is held by an RBridge that 568 is not a tree root. 570 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 571 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 572 | Nickname | 573 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 574 |IN|SE|R | C| RESV | 575 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 576 NICKFLAG RECORD 578 o R = If R flag is one, it indicates that the advertising 579 TRILL switch holding Nickname is a centralized replication node, and 580 Nickname is used as egress nickname for edge group RBridges to 581 inject BUM traffic into the TRILL campus when the edge group 582 RBridges use this centralized replication solution for active-active 583 access. If flag is zero, that nickname will not be used for that 584 purpose. 586 o C = If C flag is one, it indicates that the TRILL traffic 587 with this nickname as an ingress nickname that requires the special 588 RPF check algorithm specified in Section 3. If flag is zero, that 589 nickname will not be used for that purpose. 591 It is possible, due to errors or due to transient inconsistent LSPs 592 when the link state database is converging after a configuration 593 change or the like for there to be inconsistent Nickname Flags 594 APPsub-TLVs for the same nickname. In this case it is RECOMMENDED 595 that the nickname be treated as the R / C flag was set if any 596 Nickname Flags APPsub-TLV for that nickname has the R / C flag set. 598 12. Security Considerations 600 This draft does not introduce any extra security risks. A rogue 601 RBridge that is a tree root can attract traffic by advertising an R- 602 nickname. However, this does not represent a substantial increase in 603 risk as RBridges could cause problems in a number of other ways by 604 advertising low cost adjacencies or making themselves the highest 605 priority tree root or the like. In general, the protection against 606 an untrusted device acting as an RBridge and wrecking havoc is to 607 use IS-IS authentication [RFC5310] and configure and administer the 608 TRILL campus so that only trusted RBridges have the authentication 609 key. 611 For general TRILL Security Considerations, see [RFC6325]. For 612 Security Considerations related to pseudo-nickname active-active, 613 see [RFC7781]. 615 13. IANA Considerations 617 IANA is requested to assign two bits in the Nickname Flags APPsubTLV 618 flags for the R and C bits discussed in Section 11.1 [Bits 3 and 4 619 suggested] and update the "NickFlags" Bits registry on the TRILL 620 Parameters page as follows: 622 Bit Mnemonic Description Reference 623 --- -------- -------------------- ----------- 624 3 R Replication Nickname [This document] 625 4 C Special RFC Check [This document] 627 14. References 629 14.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 633 1997, . 635 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, 636 R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 637 5310, DOI 10.17487/RFC5310, February 2009, . 640 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 641 Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, 642 . 644 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 645 Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", 646 RFC 6325, DOI 10.17487/RFC6325, July 2011, . 649 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 650 and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): 651 Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, 652 . 654 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 655 D., and A. Banerjee, "Transparent Interconnection of Lots of Links 656 (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, 657 . 659 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 660 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of 661 Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, 662 DOI 10.17487/RFC7780, February 2016, . 665 14.2. Informative References 667 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and 668 Y. Li, "Transparent Interconnection of Lots of Links (TRILL): 669 Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 670 10.17487/RFC7781, February 2016, . 673 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 674 "Problem Statement and Goals for Active-Active Connection at the 675 Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, 676 DOI 10.17487/RFC7379, October 2014, . 679 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, 680 "Coordinated Multicast Trees (CMT) for Transparent Interconnection 681 of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 682 2016, . 684 15. Acknowledgments 686 The authors wish to acknowledge the important contributions of 687 Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia. 689 Authors' Addresses 691 Weiguo Hao 692 Huawei Technologies 693 101 Software Avenue, 694 Nanjing 210012 695 China 696 Email: haoweiguo@huawei.com 698 Yizhou Li 699 Huawei Technologies 700 101 Software Avenue, 701 Nanjing 210012 702 China 703 Email: liyizhou@huawei.com 705 Muhammad Durrani 706 Cisco 707 Phone: +1-408-527-6921 708 Email: mdurrani@cisco.com 710 Sujay Gupta 711 IP Infusion 712 RMZ Centennial 713 Mahadevapura Post 714 Bangalore - 560048 715 India 716 Email: sujay.gupta@ipinfusion.com 718 Andrew Qu 719 MediaTec 720 Email: laodulaodu@gmail.com