idnits 2.17.1 draft-ietf-trill-centralized-replication-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 44 has weird spacing: '... months and ...' == Line 105 has weird spacing: '...chanism can a...' == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 18, 2017) is 2322 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) No issues found here. Summary: 0 errors (**), 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 Equinix 6 S. Gupta 7 IP Infusion 8 A. Qu 9 MediaTec 10 Expires: June 2018 December 18, 2017 12 Centralized Replication for Active-Active BUM Traffic 13 draft-ietf-trill-centralized-replication-11.txt 15 Abstract 17 In TRILL active-active access, an RPF (Reverse Path Forwarding) check 18 failure issue may occur when using the pseudo-nickname mechanism 19 specified in RFC 7781. This draft describes a solution to resolve 20 this RPF check failure issue through centralized replication. All 21 ingress RBridges send BUM (Broadcast, Unknown unicast and Multicast) 22 traffic to a centralized node with unicast TRILL encapsulation. 23 When the centralized node receives the BUM traffic, it decapsulates 24 the packets and forwards them to their destination RBridges using 25 a distribution tree established as per TRILL base protocol RFC 6325. 26 To avoid RPF check failure on a RBridge sitting between the ingress 27 RBridge and the centralized replication node, some change in the 28 RPF calculation algorithm is required. RPF checks on each RBridge 29 MUST be calculated as if the centralized node was the ingress 30 RBridge, instead of being calculated using the actual ingress 31 RBridge. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with 36 the provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other 45 documents at any time. It is inappropriate to use Internet-Drafts 46 as reference material or to cite them other than as "work in 47 progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction ................................................3 73 2. Conventions used in this document............................4 74 3. Centralized replication solution overview....................5 75 4. Frame duplication from remote RBridge........................6 76 5. Local forwarding behavior on ingress RBridge.................7 77 6. Loop prevention among RBridges in an edge group..............8 78 7. Centralized replication forwarding process...................9 79 8. BUM traffic load balancing among multiple centralized nodes..11 80 9. Co-existing with the CMT solution........................... 12 81 10. Network upgrade analysis................................... 13 82 11. TRILL protocol extensions.................................. 13 83 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV......13 84 12. Security Considerations.................................... 14 85 13. IANA Considerations........................................ 15 86 14. References ................................................ 15 87 14.1. Normative References.................................. 15 88 14.2. Informative References................................ 16 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 Multicast) 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 128 [RFC6325] fails, and the BUM traffic received on unexpected ports 129 will be dropped by RBn. 131 This document specifies a centralized replication solution for 132 broadcast, unknown unicast and multicast (BUM) traffic forwarding to 133 resolve the issue of incorrect packet drop caused by the RPF check 134 failure in the virtual RBridge case. The basic idea is that all 135 ingress RBridges send BUM traffic to a centralized node, which 136 SHOULD be a distribution tree root, using unicast TRILL 137 encapsulation. When the centralized node receives the packets, it 138 decapsulates and forwards them to their destination RBridges using a 139 distribution tree established as per the TRILL base protocol. 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in BCP 14 [RFC2119] 146 [RFC8174] when, and only when, they appear in all capitals, 147 as shown here. 149 The acronyms and terminology in [RFC6325] are used herein with the 150 following additions: 152 BUM - Broadcast, Unknown unicast, and Multicast 154 CE - As in [RFC7783], Customer Equipment device (end station or 155 bridge). The device can be either physical or virtual equipment. 157 Data Label - VLAN or FGL [RFC7172] 159 DF - Designated Forwarder [RFC7781] 161 FGL - Fine Grained Label [RFC7172]. 163 LAALP - Local Active-Active Link Protocol [RFC7379]. 165 MAC flip flop - A problem where the attachment point of a MAC 166 address appears to a remote switch to keep changing. See Section 3.3 167 of [RFC7379]. 169 MC-LAG - Multi-Chassis Link Aggregation. 171 RPF - Reverse Path Forwarding. 173 3. Centralized replication solution overview 175 When an edge RBridge receives BUM traffic from a CE device, it uses 176 unicast TRILL encapsulation instead of multicast encapsulation to 177 send the packets to a centralized node. The centralized node MUST be 178 a distribution tree root. Distribution tree roots are normally 179 chosen to be high capacity core RBridges with many high bandwidth 180 adjacencies and this constraint makes its practical, as described 181 below, to support centralized replication with only software changes 182 to transit RBridges. 184 The TRILL header of the unicast TRILL encapsulation contains an 185 "ingress RBridge nickname" field and an "egress RBridge nickname" 186 field [RFC6325]. If the ingress RBridge receives the BUM packet from 187 a port that is in an active-active edge group using [RFC7781], it 188 sets the ingress RBridge nickname to be the pseudo-nickname rather 189 than its own nickname to avoid MAC flip-flop (see Section 3.3 of 190 [RFC7379]) on remote RBridges. The egress RBridge nickname is set 191 to a special nickname of the centralized node which is used to 192 differentiate the centralized replication purpose unicast TRILL 193 encapsulation from a normal unicast TRILL encapsulation. This 194 special nickname is called an R-nickname. 196 When the centralized RBridge receives a unicast TRILL encapsulated 197 packet with its R-nickname as egress nickname, it decapsulates the 198 packet. Then the centralized RBridge replicates and forwards the 199 BUM packet to the packet's destination RBridges using one of the 200 distribution trees established as per TRILL base protocol. It MUST 201 use a distribution tree whose tree root is the centralized RBridge 202 itself. (An RBridge may by the root of more than one tree.) When the 203 centralized RBridge forwards the BUM traffic, it simply sends it on 204 the distribution tree as if it was a locally ingressed frame except 205 that the ingress nickname remains the same as that in the packet it 206 received to ensure that the MAC address learning by all egress 207 RBridges is bound to the pseudo-nickname. 209 When the replicated packet is forwarded by each RBridge along the 210 distribution tree starting from the centralized node, an RPF check 211 is performed as per [RFC6325]. For any RBridge sitting between the 212 ingress RBridge and the centralized replication node, the incoming 213 port of such BUM packet should be the centralized node facing port 214 as the multicast traffic always comes from the centralized node in 215 this solution. However the RPF port as the result of distribution 216 tree calculation as specified in [RFC6325] will be the real ingress 217 RBridge facing port as it uses the edge group's virtual RBridge as 218 the ingress RBridge, so the RPF check will fail. 220 To solve this problem, some change in the RPF test is required. In 221 this case, the RPF calculation on each RBridge should use the 222 centralized node as the ingress RBridge for each tree for which that 223 node is the root instead of the real ingress virtual RBridge to 224 perform the calculation. As a result, RPF check will accept traffic 225 on the centralized node facing port of the RBridge for multi- 226 destination traffic. This prevents incorrect frame drops by the RPF 227 check. 229 The change in the actual RPF check on a received multi-destination 230 TRILL data packet is easy. The [RFC6325] RPF check is a check to see 231 if a triple of {ingress nickname, tree, receiving RBridge port} is 232 allowed. (The tree is indicted by the nickname of its root which is 233 stored in the TRILL Header "egress nickname" field.) When 234 determining the RFC check, if "ingress nickname" is a C-nickname, 235 then the check based on distribution from the tree root. If "ingress 236 nickname" is not a C-nickname, then the check is based on 237 distribution from the RBridge having the ingress nickname. 239 To differentiate the centralized replication unicast TRILL 240 encapsulation from normal unicast TRILL encapsulation, the R- 241 nickname is introduced for centralized replication. When the 242 centralized node receives unicast TRILL encapsulation traffic with 243 the egress nickname R-nickname, it decapsulates the packet and then 244 forwards the packet to the destination RBridges through a 245 distribution tree for which it is the root by re-encapsulation as 246 aforementioned. In TRILL, RBridges can hold multiple nicknames so 247 the centralized RBridge simply obtains another nickname to use as 248 the R-nickname. The centralized RBridge or RBridges should announce 249 their R-nickname to all TRILL campus through the TRILL LSP extension 250 specified in Section 11. 252 4. Frame duplication from remote RBridge 254 Frame duplication may occur when a remote host sends a multi- 255 destination frame to a local CE which has an active-active 256 connection to the TRILL campus. To avoid local CE receiving multiple 257 copies from a remote RBridge, the designated forwarder (DF) 258 mechanism is supported for egress direction multicast traffic. 260 The DF election mechanism [RFC7781] allows only one port of one 261 RBridge in an active-active group to forward multicast traffic from 262 the TRILL campus to the local access side for each VLAN. The basic 263 idea of DF is to elect one RBridge per VLAN from an edge group to be 264 responsible for egressing the BUM traffic. [RFC7781] describes the 265 DF election mechanism among member RBridges involving in an edge 266 group. 268 If the DF election mechanism is used for frame duplication 269 prevention, access ports on an RBridge are categorized as one of 270 three types: non-group, group DF port and group non-DF port. The 271 last two types can be called group ports. Each of the group ports 272 is associated with a pseudo-nickname. If consistent nickname 273 allocation to edge group RBridges is used, it is possible that same 274 pseudo-nickname is associated with more than one port on a single 275 RBridge. A typical scenario is that CE1 is connected to RB1 & RB2 276 by LAALP1 while CE2 is connected to RB1 & RB2 by LAALP2. 277 In order to conserve the number of pseudo-nicknames used, member 278 ports for both LAALP1 and LAALP2 on RB1 & RB2 are all associated 279 with the same pseudo-nickname. 281 5. Local forwarding behavior on ingress RBridge 283 When an ingress RBridge (RB1) receives BUM traffic from a local 284 active-active connected CE (CE1) device, the traffic will be 285 injected into the TRILL campus with TRILL encapsulation, and it will 286 be replicated and forwarded to all destination RBridges through 287 central replication, including the ingress RBridge itself, along a 288 TRILL distribution tree. To avoid the traffic looping back to the 289 original sender CE, an ingress nickname of the CE group's pseudo- 290 nickname is used for traffic filtering. 292 However, if there are two CEs, say CE1 and CE2, connecting to the 293 ingress RB1 and each associated with the same pseudo-nickname, RB1 294 needs to locally replicate and forward to CE2, because another copy 295 of the BUM traffic between CE1 and CE2 through TRILL campus will be 296 blocked by the traffic filtering. 298 If CE1 and CE2 are not associated with the same pseudo-nickname, the 299 copy of the BUM traffic between CE1 and CE2 through TRILL campus 300 won't be blocked by the traffic filtering. To avoid duplicated 301 traffic on receiver CE, there cannot be local replicated BUM traffic 302 between these two CEs on ingress RB1. 304 In summary, to ensure correct BUM traffic forwarding behavior for 305 each CE, the local replication behavior on the ingress RBridge is as 306 follows: 308 1. Replicate to the active-active group ports associated with the 309 same pseudo-nickname as that associated with the incoming port. 311 2. Do not replicate to active-active group ports associated with 312 other pseudo-nicknames. 314 3. Do not replicate to non-edge-group ports. 316 The above local forwarding behavior on the ingress RBridge of RB1 317 can be called centralized replication local forwarding behavior A. 319 If ingress RBridge RB1 itself is the centralized replication node, 320 BUM traffic injected by RB1 into the TRILL campus won't loop back to 321 RB1. In this case, the local forwarding behavior is called 322 centralized replication local forwarding behavior B. Behavior B on 323 RB1 is as follows: 325 1. Local replication to the ports associated with the same 326 pseudo-nickname as that associated with the incoming port. 328 2. Local replication to the group DF port associated with 329 different pseudo-nicknames. Do not replicate to group non-DF port 330 associated with different pseudo-nicknames. 332 3. Local replication to non-edge-group ports. 334 6. Loop prevention among RBridges in an edge group 336 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 337 packet through a DF port to an ingress RBridge, that RBridge will 338 forward that packet to all or a subset of the other RBridges that 339 only have non-DF ports for that active-active group. Because BUM 340 traffic forwarding to non-DF ports isn't allowed, in this case the 341 frame won't loop back to the CE. 343 If a CE sends a BUM packet through a non-DF port to an ingress 344 RBridge, say RB1, then RB1 will forward that packet to other 345 RBridges that have a DF port for that active-active group. In this 346 case the frame will loop back to the CE and the traffic split- 347 horizon filtering mechanism is used to avoid looping back among 348 RBridges in the edge group. 350 This split-horizon mechanism relies on the ingress nickname field in 351 the TRILL header to check if a packet's egress port belongs to a 352 same active-active group as the packet's incoming port to the TRILL 353 campus. 355 When the ingress RBridge receives BUM traffic from an active-active 356 connected CE device, the traffic will be sent through the TRILL 357 campus with TRILL encapsulation to a centralized RBridge. There it 358 will be replicated and forwarded to its destination RBridges, which 359 include ingress RBridge itself, through a TRILL distribution tree. 360 If the same pseudo-nickname is used for two active-active access CEs 361 as ingress nickname, an egress RBridge can use that nickname to 362 filter traffic forwarding to all local CEs. In this case, the 363 traffic between these two CEs goes through the local RBridge and 364 another copy of the traffic from the TRILL campus is filtered. If 365 different ingress nicknames are used for two connecting CE devices, 366 the access ports connecting to these two CEs should be isolated from 367 each other. The BUM traffic between these two CEs should go through 368 the TRILL campus, otherwise the destination CE connected to same 369 RBridge with the sender CE will receive two copies of the traffic. 371 7. Centralized replication forwarding process 373 +-----------+ 374 | (RB5) | 375 +-----------+ 376 | 377 +-----------+ 378 | (RB4) | 379 +-----------+ 381 | | | 382 -------- | -------- 383 | | | 384 +------+ +------+ +------+ 385 |(RB1) | |(RB2) | | (RB3)| 386 +------+ +------+ +------+ 387 * | * | * | ^ 388 * | * | * | ^ 389 * ----------*-------------*-- ^ 390 ***************************** | ^ 391 LAALP1 * LAALP2 | ^ 392 +------+ +------+ +------+ 393 | CE1 | | CE2 | | CE3 | 394 +------+ +------+ +------+ 395 Figure 1 TRILL Active-active access 397 Assuming the centralized replication solution is used in the example 398 network of above figure 1, RB5 is the distribution tree root and 399 centralized replication node, CE1 and CE2 are active-active accessed 400 to RB1, RB2, and RB3 through LAALP1 and LAALP2 respectively, CE3 is 401 single homed to RB3. The RBridge's own nicknames of RB1 to RB5 are 402 nick1 to nick5 respectively. RB1, RB2, and RB3 use the same pseudo- 403 nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The 404 R-nickname on the centralized replication node of RB5 is S-nick. 406 The BUM traffic forwarding process from CE1 to CE2 and CE3 is as 407 follows: 409 1. CE1 sends BUM traffic to RB3. 411 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 412 also sends the traffic to RB5 using unicast TRILL encapsulation. In 413 the TRILL Header, the ingress nickname is set as P-nick and the 414 egress nickname is set as S-nick. 416 3. RB5 decapsulates the unicast TRILL Data packet. Then it uses a 417 distribution tree for which it is the root to forward the packet as 418 a multi-destination TRILL Data packet. The egress nickname in the 419 multi-destination TRILL Header is the nick5 and the ingress nickname 420 is still P-nick. If RB3 had sent the unicast to some nickname that 421 was not an R-nickname, the packet will not be re-encapsulate. If it 422 is sent to an R-nickname that is not a tree root, it will either be 423 not forwarded at all or, if it is re-encapsulated and forwarded, 424 will be subject to incorrect pruning and will not be delivered to 425 all of its intended recipients. 427 4. RB4 receives multicast TRILL traffic from RB5. Traffic 428 incoming port is the up port facing the distribution tree root, 429 RB4's RPF check will be correct based on the changed RPF port 430 calculation algorithm in this document. After the RPF check is 431 performed, it forwards the traffic to all other egress RBridges (RB1, 432 RB2, and RB3). 434 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 435 the multi-destination TRILL Data packet. Because the ingress 436 nickname of P-nick is equivalent to the nickname of local LAALPs 437 connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 438 and CE2 to avoid duplicated frame. RB3 only forwards the packet to 439 CE3. 441 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 442 forwarding process is similar to the process on RB3, i.e., because 443 the ingress nickname of P-nick is equivalent to the nickname of the 444 local LAALPs connecting CE1 and CE2, they also don't forward the 445 traffic to local CE1 and CE2. 447 8. BUM traffic load balancing among multiple centralized nodes 449 To support unicast TRILL encapsulation BUM traffic load balancing, 450 multiple centralized replication nodes can be deployed and the 451 traffic can be spread over these nodes based on data label (VLAN or 452 FGL). Furthermore, if it was desirable for a centralized node to be 453 sent more of this BUM traffic, it could hold two or more R-nicknames. 454 The share of BUM traffic it would receive would be proportional to 455 the number of R-nicknames it held. 457 Assuming there are k different R-nicknames held by centralized nodes 458 in a TRILL campus. The VLAN-based (or FGL-based [RFC7172]) load 459 balancing algorithm used by ingress active-active access RBridge is 460 as follows: 462 1. All R-nicknames are ordered and numbered from 0 to k-1 in 463 ascending order treating the nicknames as unsigned 16-bit integers. 465 2. For data label ID m, choose the R-nickname whose number 466 equals (m mod k) as egress nickname for BUM traffic unicast TRILL 467 encapsulation. 469 For examples, there are 3 R-Nicknames (RN). The RNs will be ordered 470 RN0 to RN2. Assuming there are 5 VLANs from VLAN ID 1 to ID 5 471 spreading among edge RBridges, the traffic in VLAN 1 will go to RN1, 472 VLAN 2 will go to RN2, and so on. 474 When an ingress RBridge participating in active-active connection 475 receives BUM traffic from local CE, the RBridge decides which R- 476 nickname to send the traffic to based on the VLAN-based load 477 spreading algorithm, thus data-label-based load balancing for the 478 BUM traffic can be achieved using multiple centralized 479 nodes/multiple R-nicknames. 481 9. Co-existing with the CMT (RFC 7783) solution 483 +------+ +------+ 484 |(RB6) | |(RB7) | 485 +------+ +------+ 486 ------------------|-----------|---------------------- 487 | | | | | 488 +------+ +------+ +------+ +------+ +------+ 489 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 490 +------+ +------+ +------+ +------+ +------+ 491 | | | | | 492 ------------ ------------------------- 493 | | 494 +------+ +------+ 495 | CE1 | | CE2 | 496 +------+ +------+ 497 Figure 2 CMT and centralized replication co-existing scenario 499 Both the centralized replication solution and the Coordinated 500 Multicast Trees (CMT) [RFC7783] solution rely on using 501 pseudo-nicknames to avoid MAC flip-flop on remote RBridges. 502 These two solutions can co-exist in a single TRILL campus. 503 Each solution can be selected by each active-active edge 504 group of RBridges independently. 506 As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active- 507 active access, RB3, RB4, and RB5 use the centralized replication for 508 CE2's active-active access. 510 For the centralized replication solution, edge group RBridges MUST 511 announce the local pseudo-nickname using Nickname Flags APPsub-TLV 512 with C-flag set. A nickname with the C-flag set is called a "C- 513 nickname". A transit RBridge will perform the centralized 514 replication specific RPF check algorithm if it receives TRILL Data 515 packets with a C-nickname as ingress nickname. 517 An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag 518 on the pseudo-nickname it is using. This is already mandatory 519 behavior because any RBridge originating a Nickname Flags APPsub-TLV 520 is required by [RFC7780] to set any flag bit it does not know about 521 to zero. If a edge RBridge using CMT [RFC7783] nevertheless set the 522 C-bit for an edge group pseudo-nickname, it is very likely that BUM 523 traffic encapsulated with that nickname as ingress would be 524 incorrectly pruned early in its distribution and would thus reach 525 few (possibly none) of its intended targets. To avoid confusion, a 526 pseudo-nickname MUST NOT be shared between a centralized replication 527 edge group and a CMT-based edge group. 529 10. Network upgrade analysis 531 Centralized nodes will typically need software and hardware upgrades 532 to support centralized replication, which stitches together the 533 TRILL unicast traffic decapsulation process and the process of 534 normal TRILL multicast traffic forwarding along distribution tree. 536 Active-active connection edge RBridges will typically need software 537 and hardware upgrade to support unicast TRILL encapsulation for BUM 538 traffic; the process is similar to other head-end replication 539 processes. 541 Transit nodes typically need only a software upgrade to support the 542 changed RPF port calculation algorithm. 544 11. TRILL protocol extensions 546 Two new flags, "R" and "C", are specified in the Nickname Flags 547 APPsub-TLV [RFC7780]. A nickname with the "R" flag set is called an 548 R-nickname and a nickname with the the "C" flag set is called a C- 549 nickname. The R-nickname is a specialized nickname attached to a 550 centralized node to differentiate unicast TRILL encapsulated BUM 551 traffic from normal unicast TRILL traffic. The C-nickname flag is 552 set on the pseudo-nickname for each edge group that uses the 553 centralized replication. A C-nickname is a specialized pseudo- 554 nickname for which transit RBridges perform a different RPF check 555 algorithm for TRILL data packets with the C-nickname in the ingress 556 nickname field. 558 When active-active edge RBridges use centralized replication to 559 forward BUM traffic, the R-nickname is used as the egress nickname 560 and the C-nickname is used as ingress nickname in the TRILL header 561 for the unicast TRILL encapsulation of BUM traffic. 563 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV 565 If this APPsub-TLV is being advertised by an RBridge that does not 566 have the nickname appearing in the Nickname Flags APPsub-TLV, the R 567 and C flag bits in the APPsub-TLV MUST be treated as if they were 568 zero. If an RBridge that is not a distribution tree root advertises 569 an R-nickname, that nickname MUST NOT be treated as an R-nickname 570 but rather as an ordinary nickname, that is, the R-nickname flag is 571 ignored for all purposes if the nickname is held by an RBridge that 572 is not a tree root. 574 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 575 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 576 | Nickname | 577 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 578 |IN|SE|R | C| RESV | 579 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 580 NICKFLAG RECORD 582 o R = If R flag is one, it indicates that the advertising 583 TRILL switch holding Nickname is a centralized replication node, and 584 Nickname is used as egress nickname for edge group RBridges to 585 inject BUM traffic into the TRILL campus when the edge group 586 RBridges use this centralized replication solution for active-active 587 access. If flag is zero, that nickname will not be used for that 588 purpose. 590 o C = If C flag is one, it indicates that the TRILL traffic 591 with this nickname as an ingress nickname that requires the special 592 RPF check algorithm specified in Section 3. If flag is zero, that 593 nickname will not be used for that purpose. 595 It is possible, due to errors or due to transient inconsistent LSPs 596 when the link state database is converging after a configuration 597 change or the like for there to be inconsistent Nickname Flags 598 APPsub-TLVs for the same nickname. In this case it is RECOMMENDED 599 that the nickname be treated as if the R / C flag was set if any 600 Nickname Flags APPsub-TLV for that nickname has the R / C flag set. 602 12. Security Considerations 604 This draft does not introduce any extra security risks. A rogue 605 RBridge that is a tree root can attract traffic by advertising an R- 606 nickname. However, this does not represent a substantial increase in 607 risk as RBridges could cause problems in a number of other ways by 608 advertising low cost adjacencies or making themselves the highest 609 priority tree root or the like. In general, the protection against 610 an untrusted device acting as an RBridge and wrecking havoc is to 611 use IS-IS authentication [RFC5310] and configure and administer the 612 TRILL campus so that only trusted RBridges have the authentication 613 key. 615 For general TRILL Security Considerations, see [RFC6325]. For 616 Security Considerations related to pseudo-nickname active-active, 617 see [RFC7781]. 619 13. IANA Considerations 621 IANA is requested to assign two bits in the Nickname Flags APPsubTLV 622 flags for the R and C bits discussed in Section 11.1 [Bits 3 and 4 623 suggested] and update the "NickFlags" Bits registry on the TRILL 624 Parameters page as follows: 626 Bit Mnemonic Description Reference 627 --- -------- -------------------- ----------- 628 3 R Replication Nickname [This document] 629 4 C Special RFC Check [This document] 631 14. References 633 14.1. Normative References 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 637 1997, . 639 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, 640 R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 641 5310, DOI 10.17487/RFC5310, February 2009, . 644 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 645 Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, 646 . 648 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 649 Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", 650 RFC 6325, DOI 10.17487/RFC6325, July 2011, . 653 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 654 and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): 655 Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, 656 . 658 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 659 D., and A. Banerjee, "Transparent Interconnection of Lots of Links 660 (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, 661 . 663 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 664 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of 665 Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, 666 DOI 10.17487/RFC7780, February 2016, . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 670 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 14.2. Informative References 675 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and 676 Y. Li, "Transparent Interconnection of Lots of Links (TRILL): 677 Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 678 10.17487/RFC7781, February 2016, . 681 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 682 "Problem Statement and Goals for Active-Active Connection at the 683 Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, 684 DOI 10.17487/RFC7379, October 2014, . 687 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, 688 "Coordinated Multicast Trees (CMT) for Transparent Interconnection 689 of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 690 2016, . 692 15. Acknowledgments 694 The authors wish to acknowledge the important contributions of 695 Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia. 697 Authors' Addresses 699 Weiguo Hao 700 Huawei Technologies 701 101 Software Avenue, 702 Nanjing 210012 703 PR China 704 Email: haoweiguo@huawei.com 706 Yizhou Li 707 Huawei Technologies 708 101 Software Avenue, 709 Nanjing 210012 710 PR China 711 Email: liyizhou@huawei.com 713 Muhammad Durrani 714 Equinix 715 Email: mdurrani@equinix.com 717 Sujay Gupta 718 IP Infusion 719 RMZ Centennial 720 Mahadevapura Post 721 Bangalore - 560048 722 India 723 Email: sujay.gupta@ipinfusion.com 725 Andrew Qu 726 MediaTec 727 Email: laodulaodu@gmail.com