idnits 2.17.1 draft-ietf-trill-centralized-replication-13.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 2 instances of too long lines in the document, the longest one being 3 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 44 has weird spacing: '... months and ...' == Line 105 has weird spacing: '...chanism can a...' == Line 476 has weird spacing: '...e whose index...' (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 25, 2018) is 2283 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 Updates: 6325 M. Durrani 5 Equinix 6 S. Gupta 7 IP Infusion 8 A. Qu 9 MediaTec 10 Expires: July 2018 January 25, 2018 12 Centralized Replication for Active-Active BUM Traffic 13 draft-ietf-trill-centralized-replication-13.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. This document updates RFC 6325. 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) 2018 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 MUST 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. This 140 document updates [RFC6325]; under [RFC6325] multi-destination 141 traffic is ingressed to a multi-destination TRILL Data packet 142 but under this document, when using the centralized replication 143 feature, multi-destination traffic is initially ingressed to a 144 unicast TRILL Data packet. 146 2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 14 151 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 152 as shown here. 154 The acronyms and terminology in [RFC6325] are used herein with the 155 following additions: 157 BUM - Broadcast, Unknown unicast, and Multicast 159 CE - As in [RFC7783], Customer Equipment device (end station or 160 bridge). The device can be either physical or virtual equipment. 162 Data Label - VLAN or FGL [RFC7172] 164 DF - Designated Forwarder [RFC7781] 166 FGL - Fine Grained Label [RFC7172]. 168 LAALP - Local Active-Active Link Protocol [RFC7379]. 170 MAC flip flop - A problem where the attachment point of a MAC 171 address appears to a remote switch to keep changing. See Section 3.3 172 of [RFC7379]. 174 MC-LAG - Multi-Chassis Link Aggregation. 176 RPF - Reverse Path Forwarding. 178 3. Centralized replication solution overview 180 When an edge RBridge receives BUM traffic from a CE device, it uses 181 unicast TRILL encapsulation instead of multicast encapsulation to 182 send the packets to a centralized node. The centralized node MUST be 183 a distribution tree root. Distribution tree roots are normally 184 chosen to be high capacity core RBridges with many high bandwidth 185 adjacencies and this constraint makes its practical, as described 186 below, to support centralized replication with only software changes 187 to transit RBridges. 189 The TRILL header of the unicast TRILL encapsulation contains an 190 "ingress RBridge nickname" field and an "egress RBridge nickname" 191 field [RFC6325]. If the ingress RBridge receives the BUM packet from 192 a port that is in an active-active edge group using [RFC7781], it 193 sets the ingress RBridge nickname to be the pseudo-nickname rather 194 than its own nickname to avoid MAC flip-flop (see Section 3.3 of 195 [RFC7379]) on remote RBridges. The egress RBridge nickname is set 196 to a special nickname of the centralized node which is used to 197 differentiate the centralized replication purpose unicast TRILL 198 encapsulation from a normal unicast TRILL encapsulation. This 199 special nickname is called an R-nickname. 201 When the centralized RBridge receives a unicast TRILL encapsulated 202 packet with its R-nickname as egress nickname, it decapsulates the 203 packet. Then the centralized RBridge replicates and forwards the 204 BUM packet to the packet's destination RBridges using one of the 205 distribution trees established as per TRILL base protocol. It MUST 206 use a distribution tree whose tree root is the centralized RBridge 207 itself. (An RBridge may by the root of more than one tree.) When the 208 centralized RBridge forwards the BUM traffic, it simply sends it on 209 the distribution tree as if it was a locally ingressed frame except 210 that the ingress nickname remains the same as that in the packet it 211 received to ensure that the MAC address learning by all egress 212 RBridges is bound to the pseudo-nickname. 214 When the replicated packet is forwarded by each RBridge along the 215 distribution tree starting from the centralized node, an RPF check 216 is performed as per [RFC6325]. For any RBridge sitting between the 217 ingress RBridge and the centralized replication node, the incoming 218 port of such BUM packet should be the centralized node facing port 219 as the multicast traffic always comes from the centralized node in 220 this solution. However the RPF port as the result of distribution 221 tree calculation as specified in [RFC6325] will be the real ingress 222 RBridge facing port as it uses the edge group's virtual RBridge as 223 the ingress RBridge, so the RPF check will fail. 225 To solve this problem, some change in the RPF test is required. In 226 this case, the RPF calculation on each RBridge should use the 227 centralized node as the ingress RBridge for each tree for which that 228 node is the root instead of the real ingress virtual RBridge to 229 perform the calculation. As a result, RPF check will accept traffic 230 on the centralized node facing port of the RBridge for multi- 231 destination traffic. This prevents incorrect frame drops by the RPF 232 check. 234 The change in the actual RPF check on a received multi-destination 235 TRILL data packet is easy. The [RFC6325] RPF check is a check to see 236 if a triple of {ingress nickname, tree, receiving RBridge port} is 237 allowed. (The tree is indicated by the nickname of its root which is 238 stored in the TRILL Header "egress nickname" field.) When 239 determining the RFC check, if "ingress nickname" is using centralized 240 replication (indicated by a C-nickname, see Section 9), then the check 241 is based on distribution from the tree root. If "ingress nickname" 242 is not using centralized replication, then the check is based on 243 distribution from the RBridge having the ingress nickname. 245 To differentiate the centralized replication unicast TRILL 246 encapsulation from normal unicast TRILL encapsulation, the R- 247 nickname is introduced for centralized replication. When the 248 centralized node receives unicast TRILL encapsulation traffic with 249 the egress nickname R-nickname, it decapsulates the packet and then 250 forwards the packet to the destination RBridges through a 251 distribution tree for which it is the root by re-encapsulation as 252 aforementioned. In TRILL, RBridges can hold multiple nicknames so 253 the centralized RBridge simply obtains another nickname to use as 254 the R-nickname. The centralized RBridge or RBridges should announce 255 their R-nickname to all TRILL campus through the TRILL LSP extension 256 specified in Section 11. 258 4. Frame duplication from remote RBridge 260 Frame duplication may occur when a remote host sends a multi- 261 destination frame to a local CE which has an active-active 262 connection to the TRILL campus. To avoid local CE receiving multiple 263 copies from a remote RBridge, the designated forwarder (DF) 264 mechanism is supported for egress direction multicast traffic. 266 The DF election mechanism [RFC7781] allows only one port of one 267 RBridge in an active-active group to forward multicast traffic from 268 the TRILL campus to the local access side for each VLAN. The basic 269 idea of DF is to elect one RBridge per VLAN from an edge group to be 270 responsible for egressing the BUM traffic. [RFC7781] describes the 271 DF election mechanism among member RBridges involving in an edge 272 group. 274 If the DF election mechanism is used for frame duplication 275 prevention, access ports on an RBridge are categorized as one of 276 three types: non-group, group DF port and group non-DF port. The 277 last two types can be called group ports. Each of the group ports 278 is associated with a pseudo-nickname. If consistent nickname 279 allocation to edge group RBridges is used, it is possible that same 280 pseudo-nickname is associated with more than one port on a single 281 RBridge. A typical scenario is that CE1 is connected to RB1 & RB2 282 by LAALP1 while CE2 is connected to RB1 & RB2 by LAALP2. 283 In order to conserve the number of pseudo-nicknames used, member 284 ports for both LAALP1 and LAALP2 on RB1 & RB2 are all associated 285 with the same pseudo-nickname. 287 5. Local forwarding behavior on ingress RBridge 289 When an ingress RBridge (RB1) receives BUM traffic from a local 290 active-active connected CE (CE1) device, the traffic will be 291 injected into the TRILL campus with TRILL encapsulation, and it will 292 be replicated and forwarded to all destination RBridges through 293 central replication, including the ingress RBridge itself, along a 294 TRILL distribution tree. To avoid the traffic looping back to the 295 original sender CE, an ingress nickname of the CE group's pseudo- 296 nickname is used for traffic filtering. 298 However, if there are two CEs, say CE1 and CE2, connecting to the 299 ingress RB1 and each associated with the same pseudo-nickname, RB1 300 needs to locally replicate and forward to CE2, because another copy 301 of the BUM traffic between CE1 and CE2 through TRILL campus will be 302 blocked by the traffic filtering. 304 If CE1 and CE2 are not associated with the same pseudo-nickname, the 305 copy of the BUM traffic between CE1 and CE2 through TRILL campus 306 won't be blocked by the traffic filtering. To avoid duplicated 307 traffic on receiver CE, there cannot be local replicated BUM traffic 308 between these two CEs on ingress RB1. 310 In summary, to ensure correct BUM traffic forwarding behavior for 311 each CE, the local replication behavior on the ingress RBridge is as 312 follows: 314 1. Replicate to the active-active group ports associated with the 315 same pseudo-nickname as that associated with the incoming port. 317 2. Do not replicate to active-active group ports associated with 318 other pseudo-nicknames. 320 3. Do not replicate to non-edge-group ports. 322 The above local forwarding behavior on the ingress RBridge of RB1 323 can be called centralized replication local forwarding behavior A. 325 If ingress RBridge RB1 itself is the centralized replication node, 326 BUM traffic injected by RB1 into the TRILL campus won't loop back to 327 RB1. In this case, the local forwarding behavior is called 328 centralized replication local forwarding behavior B. Behavior B on 329 RB1 is as follows: 331 1. Local replication to the ports associated with the same 332 pseudo-nickname as that associated with the incoming port. 334 2. Local replication to the group DF port associated with 335 different pseudo-nicknames. Do not replicate to group non-DF port 336 associated with different pseudo-nicknames. 338 3. Local replication to non-edge-group ports. 340 6. Loop prevention among RBridges in an edge group 342 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 343 packet through a DF port to an ingress RBridge, that RBridge will 344 forward that packet to all or a subset of the other RBridges that 345 only have non-DF ports for that active-active group. Because BUM 346 traffic forwarding to non-DF ports isn't allowed, in this case the 347 frame won't loop back to the CE. 349 If a CE sends a BUM packet through a non-DF port to an ingress 350 RBridge, say RB1, then RB1 will forward that packet to other 351 RBridges that have a DF port for that active-active group. In this 352 case the frame will loop back to the CE and the traffic split- 353 horizon filtering mechanism is used to avoid looping back among 354 RBridges in the edge group. 356 This split-horizon mechanism relies on the ingress nickname field in 357 the TRILL header to check if a packet's egress port belongs to a 358 same active-active group as the packet's incoming port to the TRILL 359 campus. 361 When the ingress RBridge receives BUM traffic from an active-active 362 connected CE device, the traffic will be sent through the TRILL 363 campus with TRILL encapsulation to a centralized RBridge. There it 364 will be replicated and forwarded to its destination RBridges, which 365 include ingress RBridge itself, through a TRILL distribution tree. 366 If the same pseudo-nickname is used for two active-active access CEs 367 as ingress nickname, an egress RBridge can use that nickname to 368 filter traffic forwarding to all local CEs. In this case, the 369 traffic between these two CEs goes through the local RBridge and 370 another copy of the traffic from the TRILL campus is filtered. If 371 different ingress nicknames are used for two connecting CE devices, 372 the access ports connecting to these two CEs should be isolated from 373 each other. The BUM traffic between these two CEs should go through 374 the TRILL campus, otherwise the destination CE connected to same 375 RBridge with the sender CE will receive two copies of the traffic. 377 7. Centralized replication forwarding process 379 +-----------+ 380 | (RB5) | 381 +-----------+ 382 | 383 +-----------+ 384 | (RB4) | 385 +-----------+ 387 | | | 388 -------- | -------- 389 | | | 390 +------+ +------+ +------+ 391 |(RB1) | |(RB2) | | (RB3)| 392 +------+ +------+ +------+ 393 * | * | * | ^ 394 * | * | * | ^ 395 * ----------*-------------*-- ^ 396 ***************************** | ^ 397 * | ^ 398 LAALP1 * LAALP2 | ^ 399 +------+ +------+ +------+ 400 | CE1 | | CE2 | | CE3 | 401 +------+ +------+ +------+ 402 Note: The asterisk line, hyphen & vertical bar line, and circumflex 403 line in this figure indicate the connection of the various CEs to 404 the various RBs. 406 Figure 1 TRILL Active-active access 408 Assuming the centralized replication solution is used in the example 409 network of above figure 1, RB5 is the distribution tree root and 410 centralized replication node, CE1 and CE2 are active-active accessed 411 to RB1, RB2, and RB3 through LAALP1 and LAALP2 respectively, CE3 is 412 single homed to RB3. The RBridge's own nicknames of RB1 to RB5 are 413 nick1 to nick5 respectively. RB1, RB2, and RB3 use the same pseudo- 414 nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The 415 R-nickname on the centralized replication node of RB5 is S-nick. 417 The BUM traffic forwarding process from CE1 to CE2 and CE3 is as 418 follows: 420 1. CE1 sends BUM traffic to RB3. 422 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 423 also sends the traffic to RB5 using unicast TRILL encapsulation. In 424 the TRILL Header, the ingress nickname is set as P-nick and the 425 egress nickname is set as S-nick. 427 3. RB5 decapsulates the unicast TRILL Data packet. Then it uses a 428 distribution tree for which it is the root to forward the packet as 429 a multi-destination TRILL Data packet. The egress nickname in the 430 multi-destination TRILL Header is the nick5 and the ingress nickname 431 is still P-nick. If RB3 had sent the unicast to some nickname that 432 was not an R-nickname, the packet will not be re-encapsulate. If it 433 is sent to an R-nickname that is not a tree root, it will either be 434 not forwarded at all or, if it is re-encapsulated and forwarded, 435 will be subject to incorrect pruning and will not be delivered to 436 all of its intended recipients. 438 4. RB4 receives multicast TRILL traffic from RB5. Traffic 439 incoming port is the up port facing the distribution tree root, 440 RB4's RPF check will be correct based on the changed RPF port 441 calculation algorithm in this document. After the RPF check is 442 performed, it forwards the traffic to all other egress RBridges (RB1, 443 RB2, and RB3). 445 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 446 the multi-destination TRILL Data packet. Because the ingress 447 nickname of P-nick is equivalent to the nickname of local LAALPs 448 connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 449 and CE2 to avoid duplicated frame. RB3 only forwards the packet to 450 CE3. 452 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 453 forwarding process is similar to the process on RB3, i.e., because 454 the ingress nickname of P-nick is equivalent to the nickname of the 455 local LAALPs connecting CE1 and CE2, they also don't forward the 456 traffic to local CE1 and CE2. 458 8. BUM traffic load balancing among multiple centralized nodes 460 To support unicast TRILL encapsulation BUM traffic load balancing, 461 multiple centralized replication nodes can be deployed and the 462 traffic can be spread over these nodes based on data label (VLAN or 463 FGL). Furthermore, if it was desirable for a centralized node to be 464 sent more of this BUM traffic, it could hold two or more R-nicknames. 465 The share of BUM traffic it would receive would be proportional to 466 the number of R-nicknames it held. 468 Assuming there are k different R-nicknames held by centralized nodes 469 in a TRILL campus. The VLAN-based (or FGL-based [RFC7172]) load 470 balancing algorithm used by ingress active-active access RBridge is 471 as follows: 473 1. All R-nicknames are ordered and numbered from 0 to k-1 in 474 ascending order treating the nicknames as unsigned 16-bit integers. 476 2. For data label ID m, choose the R-nickname whose index is 477 given by (m mod k) as egress nickname for BUM traffic unicast TRILL 478 encapsulation. 480 For examples, there are 3 R-Nicknames (RN). The RNs will be ordered 481 RN0 to RN2. Assuming there are 5 VLANs from VLAN ID 1 to ID 5 482 spreading among edge RBridges, the traffic in VLAN 1 will go to RN1, 483 VLAN 2 will go to RN2, and so on. 485 When an ingress RBridge participating in active-active connection 486 receives BUM traffic from local CE, the RBridge decides which R- 487 nickname to send the traffic to based on the VLAN-based load 488 spreading algorithm, thus data-label-based load balancing for the 489 BUM traffic can be achieved using multiple centralized 490 nodes/multiple R-nicknames. 492 9. Co-existing with the CMT (RFC 7783) solution 494 +------+ +------+ 495 |(RB6) | |(RB7) | 496 +------+ +------+ 497 ------------------|-----------|---------------------- 498 | | | | | 499 +------+ +------+ +------+ +------+ +------+ 500 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 501 +------+ +------+ +------+ +------+ +------+ 502 | | | | | 503 ------------ ------------------------- 504 | | 505 +------+ +------+ 506 | CE1 | | CE2 | 507 +------+ +------+ 508 Figure 2 CMT and centralized replication co-existing scenario 510 Both the centralized replication solution and the Coordinated 511 Multicast Trees (CMT) [RFC7783] solution rely on using 512 pseudo-nicknames to avoid MAC flip-flop on remote RBridges. 513 These two solutions can co-exist in a single TRILL campus. 514 Each solution can be selected by each active-active edge 515 group of RBridges independently. 517 As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active- 518 active access, RB3, RB4, and RB5 use the centralized replication for 519 CE2's active-active access. 521 For the centralized replication solution, edge group RBridges MUST 522 announce the local pseudo-nickname using Nickname Flags APPsub-TLV 523 with C-flag set. A nickname with the C-flag set is called a "C- 524 nickname". A transit RBridge will perform the centralized 525 replication specific RPF check algorithm if it receives TRILL Data 526 packets with a C-nickname as ingress nickname. 528 An edge group using CMT [RFC7783] MUST NOT set the C-nickname flag 529 on the pseudo-nickname it is using. This is already mandatory 530 behavior because any RBridge originating a Nickname Flags APPsub-TLV 531 is required by [RFC7780] to set any flag bit it does not know about 532 to zero. If a edge RBridge using CMT [RFC7783] nevertheless set the 533 C-bit for an edge group pseudo-nickname, it is very likely that BUM 534 traffic encapsulated with that nickname as ingress would be 535 incorrectly pruned early in its distribution and would thus reach 536 few (possibly none) of its intended targets. To avoid confusion, a 537 pseudo-nickname MUST NOT be shared between a centralized replication 538 edge group and a CMT-based edge group. 540 10. Network upgrade analysis 542 Centralized nodes will typically need software and hardware upgrades 543 to support centralized replication, which stitches together the 544 TRILL unicast traffic decapsulation process and the process of 545 normal TRILL multicast traffic forwarding along distribution tree. 547 Active-active connection edge RBridges will typically need software 548 and hardware upgrade to support unicast TRILL encapsulation for BUM 549 traffic; the process is similar to other head-end replication 550 processes. 552 Transit nodes typically need only a software upgrade to support the 553 changed RPF port calculation algorithm. 555 11. TRILL protocol extensions 557 Two new flags, "R" and "C", are specified in the Nickname Flags 558 APPsub-TLV [RFC7780]. A nickname with the "R" flag set is called an 559 R-nickname and a nickname with the the "C" flag set is called a C- 560 nickname. The R-nickname is a specialized nickname attached to a 561 centralized node to differentiate unicast TRILL encapsulated BUM 562 traffic from normal unicast TRILL traffic. The C-nickname flag is 563 set on the pseudo-nickname for each edge group that uses the 564 centralized replication. A C-nickname is a specialized pseudo- 565 nickname for which transit RBridges perform a different RPF check 566 algorithm for TRILL data packets with the C-nickname in the ingress 567 nickname field. 569 When active-active edge RBridges use centralized replication to 570 forward BUM traffic, the R-nickname is used as the egress nickname 571 and the C-nickname is used as ingress nickname in the TRILL header 572 for the unicast TRILL encapsulation of BUM traffic. 574 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV 576 If this APPsub-TLV is being advertised by an RBridge that does not 577 have the nickname appearing in the Nickname Flags APPsub-TLV, the R 578 and C flag bits in the APPsub-TLV MUST be treated as if they were 579 zero. If an RBridge that is not a distribution tree root advertises 580 an R-nickname, that nickname MUST NOT be treated as an R-nickname 581 but rather as an ordinary nickname, that is, the R-nickname flag is 582 ignored for all purposes if the nickname is held by an RBridge that 583 is not a tree root. 585 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 586 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 587 | Nickname | 588 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 589 |IN|SE|R | C| RESV | 590 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 591 NICKFLAG RECORD 593 o R = If R flag is one, it indicates that the advertising 594 TRILL switch holding Nickname is a centralized replication node, and 595 Nickname is used as egress nickname for edge group RBridges to 596 inject BUM traffic into the TRILL campus when the edge group 597 RBridges use this centralized replication solution for active-active 598 access. If flag is zero, that nickname will not be used for that 599 purpose. 601 o C = If C flag is one, it indicates that the TRILL traffic 602 with this nickname as an ingress nickname that requires the special 603 RPF check algorithm specified in Section 3. If flag is zero, that 604 nickname will not be used for that purpose. 606 It is possible, due to errors or due to transient inconsistent LSPs 607 when the link state database is converging after a configuration 608 change or the like for there to be inconsistent Nickname Flags 609 APPsub-TLVs for the same nickname. In this case it is RECOMMENDED 610 that the nickname be treated as if the R / C flag was set if any 611 Nickname Flags APPsub-TLV for that nickname has the R / C flag set. 613 12. Security Considerations 615 This draft does not introduce any extra security risks. A rogue 616 RBridge that is a tree root can attract traffic by advertising an R- 617 nickname. However, this does not represent a substantial increase in 618 risk as RBridges could cause problems in a number of other ways by 619 advertising low cost adjacencies or making themselves the highest 620 priority tree root or the like. In general, the protection against 621 an untrusted device acting as an RBridge and wrecking havoc is to 622 use IS-IS authentication [RFC5310] and configure and administer the 623 TRILL campus so that only trusted RBridges have the authentication 624 key. 626 For general TRILL Security Considerations, see [RFC6325]. For 627 Security Considerations related to pseudo-nickname active-active, 628 see [RFC7781]. 630 13. IANA Considerations 632 IANA is requested to assign two bits in the Nickname Flags APPsubTLV 633 flags for the R and C bits discussed in Section 11.1 [Bits 3 and 4 634 suggested] and update the "NickFlags" Bits registry on the TRILL 635 Parameters page as follows: 637 Bit Mnemonic Description Reference 638 --- -------- -------------------- ----------- 639 3 R Replication Nickname [This document] 640 4 C Special RFC Check [This document] 642 14. References 644 14.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 648 1997, . 650 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, 651 R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 652 5310, DOI 10.17487/RFC5310, February 2009, . 655 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 656 Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, 657 . 659 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 660 Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", 661 RFC 6325, DOI 10.17487/RFC6325, July 2011, . 664 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 665 and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): 666 Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, 667 . 669 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 670 D., and A. Banerjee, "Transparent Interconnection of Lots of Links 671 (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, 672 . 674 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 675 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of 676 Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, 677 DOI 10.17487/RFC7780, February 2016, . 680 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in 681 RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 682 May 2017, . 684 14.2. Informative References 686 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and 687 Y. Li, "Transparent Interconnection of Lots of Links (TRILL): 688 Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 689 10.17487/RFC7781, February 2016, . 692 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 693 "Problem Statement and Goals for Active-Active Connection at the 694 Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, 695 DOI 10.17487/RFC7379, October 2014, . 698 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, 699 "Coordinated Multicast Trees (CMT) for Transparent Interconnection 700 of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 701 2016, . 703 15. Acknowledgments 705 The authors wish to acknowledge the important contributions of 706 Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia, Francis Dupont. 708 Authors' Addresses 710 Weiguo Hao 711 Huawei Technologies 712 101 Software Avenue, 713 Nanjing 210012 714 PR China 715 Email: haoweiguo@huawei.com 717 Yizhou Li 718 Huawei Technologies 719 101 Software Avenue, 720 Nanjing 210012 721 PR China 722 Email: liyizhou@huawei.com 724 Muhammad Durrani 725 Equinix 726 Email: mdurrani@equinix.com 728 Sujay Gupta 729 IP Infusion 730 RMZ Centennial 731 Mahadevapura Post 732 Bangalore - 560048 733 India 734 Email: sujay.gupta@ipinfusion.com 736 Andrew Qu 737 MediaTec 738 Email: laodulaodu@gmail.com