idnits 2.17.1 draft-ietf-trill-centralized-replication-08.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 ...' -- The document date (December 30, 2016) is 2674 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 (~~), 2 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 Inc. 6 S. Gupta 7 IP Infusion 8 A. Qu 9 MediaTec 10 Expires: June 2017 December 30, 2016 12 Centralized Replication for Active-Active BUM Traffic 13 draft-ietf-trill-centralized-replication-08.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) 2016 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................. 6 76 6. Loop prevention among RBridges in a edge group............... 7 77 7. Centralized replication forwarding process................... 8 78 8. BUM traffic loadbalancing among multiple centralized nodes...10 79 9. Co-existing with the CMT solution........................... 11 80 10. Network Upgrade Analysis................................... 12 81 11. TRILL protocol extension................................... 12 82 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV......12 84 12. Security Considerations.................................... 13 85 13. IANA Considerations........................................ 13 86 14. References ................................................ 14 87 14.1. Normative References.................................. 14 88 14.2. Informative References................................ 14 89 15. Acknowledgments ........................................... 15 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 In active-active, Customer Equipment (CE) devices typically are 100 multi-homed to edge RBridges which form an edge group. All of the 101 uplinks from CE are handled via a Local Active-Active Link Protocol 102 (LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or 103 Distributed Resilient Network Interconnect (DRNI) [802.1AX]. An 104 active-active flow-based load sharing mechanism is normally 105 implemented to achieve better load balancing and high reliability. A 106 CE device can be a layer 3 end system by itself or a bridge switch 107 through which layer 3 end systems access to TRILL campus. 109 In active-active access, the pseudo-nickname solution in [RFC7781] 110 can be used to avoid MAC flip-flop on remote RBridges. The basic 111 idea is to use a virtual RBridge RBv with a single pseudo-nickname 112 to represent an edge group. Any member RBridge of that edge group 113 uses this pseudo-nickname rather than its own nickname as the 114 ingress nickname when it injects TRILL data frames to TRILL campus. 115 The use of the nickname solves the address flip-flop issue by 116 setting the MAC address learnt by a remote RBridge to the pseudo- 117 nickname. However, it introduces another issue of incorrect packet 118 dropping as follows: When a pseudo-nickname is used by an edge 119 RBridge as the ingress nickname to forward BUM (Broadcast, Unknown 120 unicast and Mutlicast) traffic, any RBridges (RBn) sitting between 121 the ingress RBridge and the distribution tree root will treat the 122 traffic as if it was ingressed from the virtual RBridge RBv. If the 123 same distribution tree is used by different edge RBridges of the 124 same RBv, the traffic may arrive at some RBn from different ports. 125 Then the RPF check fails, and the BUM traffic received on unexpected 126 ports will be dropped by RBn. 128 This document specifies a centralized replication solution for 129 broadcast, unknown unicast and multicast (BUM) traffic forwarding to 130 resolve the issue of incorrect packet drop caused by RPF check 131 failure in the virtual RBridge case. The basic idea is that all 132 ingress RBridges send BUM traffic to a centralized node, which 133 SHOULD be a distribution tree root, using unicast TRILL 134 encapsulation. When the centralized node receives the packets, it 135 decapsulates and forwards them to their destination RBridges using a 136 distribution tree established as per the TRILL base protocol. 138 2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC-2119 [RFC2119]. 143 The acronyms and terminology in [RFC6325] are used herein with the 144 following additions: 146 BUM - Broadcast, Unknown unicast and Multicast 148 CE - As in [RFC7783], Customer Equipment device (end station or 149 bridge). The device can be either physical or virtual equipment. 151 DF - Designated Forwarder [RFC7781] 153 FGL - Fine Grained Label [RFC7172]. 155 LAALP -Local Active-Active Link Protocol [RFC7379]. 157 MC-LAG - Multi-Chassis Link Aggregation. 159 RPF - Reverse Path Forwarding. 161 3. Centralized Replication Solution Overview 163 When an edge RBridge receives BUM traffic from a CE device, it uses 164 unicast TRILL encapsulation instead of multicast encapsulation to 165 send the packets to a centralized node. The centralized node SHOULD 166 be a distribution tree root because such roots are normally chosen 167 to be high capacity core RBridges with many high bandwidth 168 adjacencies. 170 The TRILL header of the unicast TRILL encapsulation contains an 171 "ingress RBridge nickname" field and an "egress RBridge nickname" 172 field. If the ingress RBridge receives the BUM packet from a port 173 that is in an active-active edge group using [RFC7781], it sets the 174 ingress RBridge nickname to be the pseudo-nickname rather than its 175 own nickname to avoid MAC flip-flop on remote RBridges. The egress 176 RBridge nickname is set to a special nickname of the centralized 177 node which is used to differentiate the centralized replication 178 purpose unicast TRILL encapsulation from a normal unicast TRILL 179 encapsulation. This special nickname is called an R-nickname. 181 When the centralized RBridge receives a unicast TRILL encapsulated 182 packet with its R-nickname as egress nickname, it decapsulates the 183 packet. Then the centralized RBridge replicates and forwards the BUM 184 packet to the packet's destination RBridges using one of the 185 distribution trees established as per TRILL base protocol. It SHOULD 186 use a distribution tree whose tree root is the centralized RBridge 187 itself. When the centralized RBridge forwards the BUM traffic, it 188 simply sends it on the distribution tree as if it was a locally 189 ingressed frame except that the ingress nickname remains the same as 190 that in the packet it received to ensure that the MAC address 191 learning by all egress RBridges is bound to the pseudo-nickname. 193 When the replicated packet is forwarded by each RBridge along the 194 distribution tree starting from the centralized node, the RPF check 195 is performed as per [RFC6325]. For any RBridge sitting between the 196 ingress RBridge and the centralized replication node, the incoming 197 port of such BUM packet should be the centralized node facing port 198 as the multicast traffic always comes from the centralized node in 199 this solution. However the RPF port as the result of distribution 200 tree calculation as per [RFC6325] will be the real ingress RBridge 201 facing port as it uses virtual RBridge as the ingress RBridge, so 202 the RPF check will fail. To solve this problem, some change in the 203 RPF calculation algorithm is required. In this case, the RPF 204 calculation on each RBridge should use the centralized node as the 205 ingress RBridge instead of the real ingress virtual RBridge to 206 perform the calculation. As a result, RPF check will accept traffic 207 on the centralized node facing port of the RBridge for multi- 208 destination traffic. This prevents incorrect frame drops by the RPF 209 check. 211 To differentiate the centralized replication unicast TRILL 212 encapsulation from normal unicast TRILL encapsulation, the R- 213 nickname is introduced for centralized replication. When the 214 centralized node receives unicast TRILL encapsulation traffic with 215 the egress nickname R-nickname, it decapsulates the packet and then 216 forwards the packet to the destination RBridges through a 217 distribution tree by re-encapsulation as aforementioned. In TRILL, 218 RBridges can hold multiple nicknames so the centralized RBridge 219 simply obtains another nickname to use as the R-nickname. The 220 centralized RBridge or RBridges should announce their R-nickname to 221 all TRILL campus through the TRILL LSP extension specified in 222 Section 11. 224 4. Frame duplication from remote RBridge 226 Frame duplication may occur when a remote host sends a multi- 227 destination frame to a local CE which has an active-active 228 connection to the TRILL campus. To avoid local CE receiving multiple 229 copies from a remote RBridge, the designated forwarder (DF) 230 mechanism is supported for egress direction multicast traffic. 232 The DF election mechanism [RFC7781] allows only one port of one 233 RBridge in an active-active group to forward multicast traffic from 234 the TRILL campus to the local access side for each VLAN. The basic 235 idea of DF is to elect one RBridge per VLAN from an edge group to be 236 responsible for egressing the BUM traffic. [RFC7781] describes the 237 DF election mechanism among member RBridges involving in an edge 238 group. 240 If the DF election mechanism is used for frame duplication 241 prevention, access ports on an RBridge are categorized as one of 242 three types: non-group, group DF port and group non-DF port. The 243 last two types can be called group ports. Each of the group ports is 244 associated with a pseudo-nickname. If consistent nickname allocation 245 to edge group RBridges is used, it is possible that same pseudo- 246 nickname is associated with more than one port on a single RBridge. 247 A typical scenario is that CE1 is connected to RB1 & RB2 by LAALP1 248 while CE2 is connected to RB1 & RB2 by LAALP2. In order to conserve 249 the number of pseudo-nicknames used, member ports for both LAALP1 250 and LAALP2 on RB1 & RB2 are all associated with the same pseudo- 251 nickname. 253 5. Local forwarding behavior on ingress RBridge 255 When an ingress RBridge (RB1) receives BUM traffic from a local 256 active-active connected CE (CE1) device, the traffic will be 257 injected into the TRILL campus with TRILL encapsulation, and it will 258 be replicated and forwarded to all destination RBridges through 259 central replication, including the ingress RBridge itself, along a 260 TRILL distribution tree. To avoid the traffic looping back to the 261 original sender CE, an ingress nickname of the CE group's pseudo- 262 nickname is used for traffic filtering. 264 However, if there are two CEs, say CE1 and CE2, connecting to the 265 ingress RB1 and each associated with the same pseudo-nickname, RB1 266 needs to locally replicate and forward to CE2, because another copy 267 of the BUM traffic between CE1 and CE2 through TRILL campus will be 268 blocked by the traffic filtering. 270 If CE1 and CE2 are not associated with the same pseudo-nickname, the 271 copy of the BUM traffic between CE1 and CE2 through TRILL campus 272 won't be blocked by the traffic filtering. To avoid duplicated 273 traffic on receiver CE, there cannot be local replicated BUM traffic 274 between these two CEs on ingress RB1. 276 In summary, to ensure correct BUM traffic forwarding behavior for 277 each CE, the local replication behavior on the ingress RBridge is as 278 follows: 280 1. Replicate to the active-active group ports associated with the 281 same pseudo-nickname as that associated with the incoming port. 283 2. Do not replicate to active-active group ports associated with 284 other pseudo-nicknames. 286 3. Do not replicate to non-edge-group ports. 288 The above local forwarding behavior on the ingress RBridge of RB1 289 can be called centralized replication local forwarding behavior A. 291 If ingress RBridge RB1 itself is the centralized replication node, 292 BUM traffic injected by RB1 into the TRILL campus won't loop back to 293 RB1. In this case, the local forwarding behavior is called 294 centralized replication local forwarding behavior B. Behavior B on 295 RB1 is as follows: 297 1. Local replication to the ports associated with the same 298 pseudo-nickname as that associated with the incoming port. 300 2. Local replication to the group DF port associated with 301 different pseudo-nicknames. Do not replicate to group non-DF port 302 associated with different pseudo-nicknames. 304 3. Local replication to non-edge-group ports. 306 6. Loop prevention among RBridges in a edge group 308 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 309 packet through a DF port to an ingress RBridge, that RBridge will 310 forward that packet to all or a subset of the other RBridges that 311 only have non-DF ports for that active-active group. Because BUM 312 traffic forwarding to non-DF ports isn't allowed, in this case the 313 frame won't loop back to the CE. 315 If a CE sends a BUM packet through a non-DF port to an ingress 316 RBridge, say RB1, then RB1 will forward that packet to other 317 RBridges that have a DF port for that active-active group. In this 318 case the frame will loop back to the CE and the traffic split- 319 horizon filtering mechanism is used to avoid looping back among 320 RBridges in the edge group. 322 This split-horizon mechanism relies on the ingress nickname field in 323 the TRILL header to check if a packet's egress port belongs to a 324 same active-active group as the packet's incoming port to the TRILL 325 campus. 327 When the ingress RBridge receives BUM traffic from an active-active 328 connected CE device, the traffic will be sent through the TRILL 329 campus with TRILL encapsulation to a centralized RBridge. There it 330 will be replicated and forwarded to its destination RBridges, which 331 include ingress RBridge itself, through a TRILL distribution tree. 332 If the same pseudo-nickname is used for two active-active access CEs 333 as ingress nickname, an egress RBridge can use that nickname to 334 filter traffic forwarding to all local CEs. In this case, the 335 traffic between these two CEs goes through the local RBridge and 336 another copy of the traffic from the TRILL campus is filtered. If 337 different ingress nicknames are used for two connecting CE devices, 338 the access ports connecting to these two CEs should be isolated from 339 each other. The BUM traffic between these two CEs should go through 340 the TRILL campus, otherwise the destination CE connected to same 341 RBridge with the sender CE will receive two copies of the traffic. 343 7. Centralized replication forwarding process 344 +-----------+ 345 | (RB5) | 346 +-----------+ 347 | 348 +-----------+ 349 | (RB4) | 350 +-----------+ 352 | | | 353 -------- | -------- 354 | | | 355 +------+ +------+ +------+ 356 |(RB1) | |(RB2) | | (RB3)| 357 +------+ +------+ +------+ 358 * | * | * | ^ 359 * | * | * | ^ 360 * ----------*-------------*-- ^ 361 ***************************** | ^ 362 LAALP1 * LAALP2 | ^ 363 +------+ +------+ +------+ 364 | CE1 | | CE2 | | CE3 | 365 +------+ +------+ +------+ 366 Figure 1 TRILL Active-active access 368 Assuming the centralized replication solution is used in the example 369 network of above figure 1, RB5 is the distribution tree root and 370 centralized replication node, CE1 and CE2 are active-active accessed 371 to RB1, RB2, and RB3 through LAALP1 and LAALP2 respectively, CE3 is 372 single homed to RB3. The RBridge's own nicknames of RB1 to RB5 are 373 nick1 to nick5 respectively. RB1, RB2, and RB3 use the same pseudo- 374 nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The 375 R-nickname on the centralized replication node of RB5 is S-nick. 377 The BUM traffic forwarding process from CE1 to CE2 and CE3 is as 378 follows: 380 1. CE1 sends BUM traffic to RB3. 382 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 383 also sends the traffic to RB5 using unicast TRILL encapsulation. In 384 the TRILL Header, the ingress nickname is set as P-nick and the 385 egress nickname is set as S-nick. 387 3. RB5 decapsulates the unicast TRILL Data packet. Then it uses a 388 distribution tree to forward the packet as a multi-destination TRILL 389 Data packet. The egress nickname in the multi-destination TRILL 390 Header is the nick5 and the ingress nickname is still P-nick. 392 4. RB4 receives multicast TRILL traffic from RB5. Traffic 393 incoming port is the up port facing the distribution tree root, 394 RB4's RPF check will be correct based on the changed RPF port 395 calculation algorithm in this document. After the RPF check is 396 performed, it forwards the traffic to all other egress RBridges (RB1, 397 RB2, and RB3). 399 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 400 the multi-destination TRILL Data packet. Because the ingress 401 nickname of P-nick is equivalent to the nickname of local LAALPs 402 connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 403 and CE2 to avoid duplicated frame. RB3 only forwards the packet to 404 CE3. 406 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 407 forwarding process is similar to the process on RB3, i.e., because 408 the ingress nickname of P-nick is equivalent to the nickname of the 409 local LAALPs connecting CE1 and CE2, they also don't forward the 410 traffic to local CE1 and CE2. 412 8. BUM traffic load balancing among multiple centralized nodes 414 To support unicast TRILL encapsulation BUM traffic load balancing, 415 multiple centralized replication nodes can be deployed and the 416 traffic can be spread over these nodes based on VLAN or FGL. 417 Furthermore, if it was desirable for a centralized node to be sent 418 more of this BUM traffic, it could hold two or more R-nicknames. The 419 share of BUM traffic it would receive would be proportional to the 420 number of R-nicknames it held. 422 Assuming there are k different R-nicknames held by centralized nodes 423 in a TRILL campus. The VLAN-based (or FGL-based [RFC7172]) load 424 balancing algorithm used by ingress active-active access RBridge is 425 as follows: 427 1. All R-nicknames are ordered and numbered from 0 to k-1 in 428 ascending order treating the nicknames as unsigned 16-bit integers. 430 2. For VLAN or FGL ID m, choose the R-nickname whose number 431 equals (m mod k) as egress nickname for BUM traffic unicast TRILL 432 encapsulation. 434 For examples, there are 3 R-Nicknames (RN). The RNs will be ordered 435 RN0 to RN2. Assuming there are 5 VLANs from VLAN ID 1 to ID 5 436 spreading among edge RBridges, the traffic in VLAN 1 will go to RN1, 437 VLAN 2 will go to RN2, and so on. 439 When an ingress RBridge participating in active-active connection 440 receives BUM traffic from local CE, the RBridge decides which R- 441 nickname to send the traffic to based on the VLAN-based load 442 spreading algorithm, thus VLAN/FGL-based load balancing for the BUM 443 traffic can be achieved using multiple centralized nodes/ multiple 444 R-nicknames. 446 9. Co-existing with the CMT solution 448 +------+ +------+ 449 |(RB6) | |(RB7) | 450 +------+ +------+ 451 ------------------|-----------|---------------------- 452 | | | | | 453 +------+ +------+ +------+ +------+ +------+ 454 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 455 +------+ +------+ +------+ +------+ +------+ 456 | | | | | 457 ------------ ------------------------- 458 | | 459 +------+ +------+ 460 | CE1 | | CE2 | 461 +------+ +------+ 462 Figure 2 CMT and centralized replication co-existing scenario 464 Both the centralized replication solution and the CMT [RFC7783] 465 solution rely on using pseudo-nicknames to avoid MAC flip-flop on 466 remote RBridges. These two solutions can co-exist in a single TRILL 467 campus. Each solution can be selected by each active-active edge 468 group of RBridges independently. 470 As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active- 471 active access, RB3, RB4, and RB5 use the centralized replication for 472 CE2's active-active access. 474 For the centralized replication solution, edge group RBridges MUST 475 announce the local pseudo-nickname using Nickname Flags APPsub-TLV 476 with C-flag set. A nickname with the C-flag set is called a "C- 477 nickname". A transit RBridge will perform the centralized 478 replication specific RPF check algorithm if it receives TRILL Data 479 packets with a C-nickname as ingress nickname. 481 In this case, an edge group using CMT [RFC7783] MUST NOT set the C- 482 nickname flag on the pseudo-nickname it is using. To avoid confusion, 483 a pseudo-nickname MUST NOT be shared between a centralized 484 replication edge group and a CMT-based edge group. 486 10. Network Upgrade Analysis 488 Centralized nodes will typically need software and hardware upgrades 489 to support centralized replication, which stitches together the TRILL 490 unicast traffic decapsulation process and the process of normal 491 TRILL multicast traffic forwarding along distribution tree. 493 Active-active connection edge RBridges will typically need software 494 and hardware upgrade to support unicast TRILL encapsulation for BUM 495 traffic; the process is similar to other head-end replication 496 processes. 498 Transit nodes typically need a software upgrade to support the 499 changed RPF port calculation algorithm. 501 11. TRILL protocol extensions 503 Two new flags, "R" and "C", are specified in the Nickname Flags 504 APPsub-TLV [RFC7780]. A nickname with the "R" flag set is called an 505 R-nickname and a nickname with the the "C" flag set is called a C- 506 nickname. The R-nickname is a specialized nickname attached to a 507 centralized node to differentiate unicast TRILL encapsulated BUM 508 traffic from normal unicast TRILL traffic. The C-nickname flag is 509 set on the psudo-nickname for each edge group. A C-nickname is a 510 specialized pseudo-nickname for which transit RBridges perform a 511 different RPF check algorithm for TRILL data packets with the C- 512 nickname in the ingress nickname field. 514 When active-active edge RBridges use centralized replication to 515 nickname and the C-nickname is used as ingress nickname in the TRILL 516 header for the unicast TRILL encapsulation of BUM traffic. 518 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV 520 If this APPsub-TLV is being advertised by an RBridge that does not 521 have the nickname appearing in the Nickname Flags APPsub-TLV, the R 522 and C flag bits in the APPsub-TLV MUST be treated as if they were 523 zero. 525 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 526 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 527 | Nickname | 528 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 529 |IN|SE|R | C| RESV | 530 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 531 NICKFLAG RECORD 533 o R = If R flag is one, it indicates that the advertising 534 TRILL switch holding Nickname is a centralized replication node, and 535 Nickname is used as egress nickname for edge group RBridges to 536 inject BUM traffic into the TRILL campus when the edge group 537 RBridges use centralized replication solution for active-active 538 access. If flag is zero, that nickname will not be used for that 539 purpose. 541 o C = If C flag is one, it indicates that the TRILL traffic 542 with this nickname as an ingress nickname that requires the special 543 RPF check algorithm specified in Section 3. If flag is zero, that 544 nickname will not be used for that purpose. 546 It is possible, due to errors or due to transient inconsistent LSPs 547 when the link state database is converging after a configuration 548 change or the like for there to be inconsistent Nickname Flags 549 APPsub-TLVs for the same nickname. In this case it is RECOMMENDED 550 that the nickname be treated as an R-nickname / C-nickname if any 551 Nickname Flags APPsub-TLV for that nickname has the R / C flag set. 553 12. Security Considerations 555 This draft does not introduce any extra security risks. For general 556 TRILL Security Considerations, see [RFC6325]. For Security 557 Considerations related to pseudo-nickname active-active, see 558 [RFC7781]. 560 13. IANA Considerations 562 IANA is requested to assign two bits in the Nickname Flags APPsubTLV 563 flags for the R and C bits discussed in Section 11.1 [Bits 3 and 4 564 suggested] and update the "NickFlags" Bits registry on the TRILL 565 Parameters page as follows: 567 Bit Mnemonic Description Reference 568 --- -------- -------------------- ----------- 569 3 R Replication Nickname [This document] 570 4 C Special RFC Check [This document] 572 14. References 574 14.1. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 578 1997, . 580 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 581 Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, 582 . 584 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 585 Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", 586 RFC 6325, DOI 10.17487/RFC6325, July 2011, . 589 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 590 and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): 591 Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, 592 . 594 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 595 D., and A. Banerjee, "Transparent Interconnection of Lots of Links 596 (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, 597 . 599 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 600 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of 601 Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, 602 DOI 10.17487/RFC7780, February 2016, . 605 14.2. Informative References 607 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and 608 Y. Li, "Transparent Interconnection of Lots of Links (TRILL): 609 Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 610 10.17487/RFC7781, February 2016, . 613 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 614 "Problem Statement and Goals for Active-Active Connection at the 615 Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, 616 DOI 10.17487/RFC7379, October 2014, . 619 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, 620 "Coordinated Multicast Trees (CMT) for Transparent Interconnection 621 of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 622 2016, . 624 15. Acknowledgments 626 The authors wish to acknowledge the important contributions of 627 Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia. 629 Authors' Addresses 631 Weiguo Hao 632 Huawei Technologies 633 101 Software Avenue, 634 Nanjing 210012 635 China 636 Email: haoweiguo@huawei.com 638 Yizhou Li 639 Huawei Technologies 640 101 Software Avenue, 641 Nanjing 210012 642 China 643 Email: liyizhou@huawei.com 645 Muhammad Durrani 646 Equinix Inc. 648 Email: mdurrani@equinix.com 650 Sujay Gupta 651 IP Infusion 652 RMZ Centennial 653 Mahadevapura Post 654 Bangalore - 560048 655 India 656 Email: sujay.gupta@ipinfusion.com 658 Andrew Qu 659 MediaTec 660 Email: laodulaodu@gmail.com