idnits 2.17.1 draft-ietf-trill-centralized-replication-07.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 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 45 has weird spacing: '... months and ...' -- The document date (December 20, 2016) is 2681 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 Cisco 6 S. Gupta 7 IP Infusion 8 A. Qu 9 MediaTec 10 T. Han 11 Huawei Technologies 12 Expires: May 2017 December 20, 2016 14 Centralized Replication for Active-Active BUM Traffic 15 draft-ietf-trill-centralized-replication-07.txt 17 Abstract 19 In TRILL active-active access, an RPF check failure issue may occur 20 when using the pseudo-nickname mechanism specified in RFC 7781. This 21 draft describes a solution to resolve this RPF check failure issue 22 through centralized replication. All ingress RBridges send BUM 23 (Broadcast, Unknown unicast and Mutlicast) traffic to a centralized 24 node with unicast TRILL encapsulation. When the centralized node 25 receives the BUM traffic, it decapsulates the packets and forwards 26 them to their destination RBridges using a distribution tree 27 established as per TRILL base protocol RFC 6325. To avoid RPF check 28 failure on a RBridge sitting between the ingress RBridge and the 29 centralized replication node, some change in the RPF calculation 30 algorithm is required. RPF checks on each RBridge should be calculated 31 as if the centralized node was the ingress RBridge, instead of being 32 calculated using the actual ingress RBridge. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with 37 the provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other 46 documents at any time. It is inappropriate to use Internet-Drafts 47 as reference material or to cite them other than as "work in 48 progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. Code Components extracted from this 67 document must include Simplified BSD License text as described in 68 Section 4.e of the Trust Legal Provisions and are provided without 69 warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction ................................................ 3 74 2. Conventions used in this document............................ 4 75 3. Centralized Replication Solution Overview.................... 4 76 4. Frame duplication from remote RBridge........................ 6 77 5. Local forwarding behavior on ingress RBridge................. 6 78 6. Loop prevention among RBridges in a edge group............... 7 79 7. Centralized replication forwarding process................... 8 80 8. BUM traffic loadbalancing among multiple centralized nodes...10 81 9. Co-existing with the CMT solution ...........................11 82 10. Network Upgrade Analysis................................... 12 83 11. TRILL protocol extension................................... 12 84 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV......13 85 12. Security Considerations.................................... 13 86 13. IANA Considerations........................................ 14 87 14. References ................................................ 14 88 14.1. Normative References.................................. 14 89 14.2. Informative References................................ 15 90 15. Acknowledgments ........................................... 15 92 1. Introduction 94 The IETF TRILL (Transparent Interconnection of Lots of Links) 95 [RFC6325] protocol provides loop free and per hop based multipath 96 data forwarding with minimum configuration. TRILL uses IS-IS 97 [RFC6165] [RFC7176] as its control plane routing protocol and 98 defines a TRILL specific header for user data. 100 In active-active, Customer Equipment (CE) devices typically are 101 multi-homed to edge RBridges which form an edge group. All of the 102 uplinks from CE are handled via a Local Active-Active Link Protocol 103 (LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or 104 Distributed Resilient Network Interconnect (DRNI) [802.1AX]. An 105 active-active flow-based load sharing mechanism is normally 106 implemented to achieve better load balancing and high reliability. A 107 CE device can be a layer 3 end system by itself or a bridge switch 108 through which layer 3 end systems access to TRILL campus. 110 In active-active access, the pseudo-nickname solution in [RFC7781] 111 can be used to avoid MAC flip-flop on remote RBridges. The basic 112 idea is to use a virtual RBridge RBv with a single pseudo-nickname 113 to represent an edge group. Any member RBridge of that edge group 114 uses this pseudo-nickname rather than its own nickname as the 115 ingress nickname when it injects TRILL data frames to TRILL campus. 116 The use of the nickname solves the address flip-flop issue by 117 setting the MAC address learnt by a remote RBridge to the pseudo- 118 nickname. However, it introduces another issue of incorrect packet 119 dropping as follows: When a pseudo-nickname is used by an edge 120 RBridge as the ingress nickname to forward BUM (Broadcast, Unknown 121 unicast and Mutlicast) traffic, any RBridges (RBn) sitting between 122 the ingress RBridge and the distribution tree root will treat the 123 traffic as if it was ingressed from the virtual RBridge RBv. If the 124 same distribution tree is used by different edge RBridges of the 125 same RBv, the traffic may arrive at some RBn from different ports. 126 Then the RPF check fails, and the BUM traffic received on unexpected 127 ports will be dropped by RBn. 129 This document specifies a centralized replication solution for 130 broadcast, unknown unicast and multicast (BUM) traffic forwarding to 131 resolve the issue of incorrect packet drop caused by RPF check 132 failure in the virtual RBridge case. The basic idea is that all 133 ingress RBridges send BUM traffic to a centralized node, which 134 SHOULD be a distribution tree root, using unicast TRILL 135 encapsulation. When the centralized node receives the packets, it 136 decapsulates and forwards them to their destination RBridges using a 137 distribution tree established as per the TRILL base protocol. 139 2. Conventions used in this document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC-2119 [RFC2119]. 144 The acronyms and terminology in [RFC6325] are used herein with the 145 following additions: 147 BUM - Broadcast, Unknown unicast and Multicast 149 CE - As in [RFC7783], Customer Equipment device (end station or 150 bridge). The device can be either physical or virtual equipment. 152 DF - Designated Forwarder [RFC7781] 154 FGL - Fine Grained Label [RFC7172]. 156 LAALP -Local Active-Active Link Protocol [RFC7379]. 158 MC-LAG - Multi-Chassis Link Aggregation. 160 RPF - Reverse Path Forwarding. 162 3. Centralized Replication Solution Overview 164 When an edge RBridge receives BUM traffic from a CE device, it uses 165 unicast TRILL encapsulation instead of multicast encapsulation to 166 send the packets to a centralized node. The centralized node SHOULD 167 be a distribution tree root because such roots are normally chosen 168 to be high capacity core RBridges with many high bandwidth 169 adjacencies. 171 The TRILL header of the unicast TRILL encapsulation contains an 172 "ingress RBridge nickname" field and an "egress RBridge nickname" 173 field. If the ingress RBridge receives the BUM packet from a port 174 that is in an active-active edge group using [RFC7781], it sets the 175 ingress RBridge nickname to be the pseudo-nickname rather than its 176 own nickname to avoid MAC flip-flop on remote RBridges. The egress 177 RBridge nickname is set to a special nickname of the centralized 178 node which is used to differentiate the centralized replication 179 purpose unicast TRILL encapsulation from a normal unicast TRILL 180 encapsulation. This special nickname is called an R-nickname. 182 When the centralized RBridge receives a unicast TRILL encapsulated 183 packet with its R-nickname as egress nickname, it decapsulates the 184 packet. Then the centralized RBridge replicates and forwards the BUM 185 packet to the packet's destination RBridges using one of the 186 distribution trees established as per TRILL base protocol. It SHOULD 187 use a distribution tree whose tree root is the centralized RBridge 188 itself. When the centralized RBridge forwards the BUM traffic, it 189 simply sends it on the distribution tree as if it was a locally 190 ingressed frame except that the ingress nickname remains the same as 191 that in the packet it received to ensure that the MAC address 192 learning by all egress RBridges is bound to the pseudo-nickname. 194 When the replicated packet is forwarded by each RBridge along the 195 distribution tree starting from the centralized node, the RPF check 196 is performed as per [RFC6325]. For any RBridge sitting between the 197 ingress RBridge and the centralized replication node, the incoming 198 port of such BUM packet should be the centralized node facing port 199 as the multicast traffic always comes from the centralized node in 200 this solution. However the RPF port as the result of distribution 201 tree calculation as per [RFC6325] will be the real ingress RBridge 202 facing port as it uses virtual RBridge as the ingress RBridge, so 203 the RPF check will fail. To solve this problem, some change in the 204 RPF calculation algorithm is required. In this case, the RPF 205 calculation on each RBridge should use the centralized node as the 206 ingress RBridge instead of the real ingress virtual RBridge to 207 perform the calculation. As a result, RPF check will accept traffic 208 on the centralized node facing port of the RBridge for multi- 209 destination traffic. This prevents incorrect frame drops by the RPF 210 check. 212 To differentiate the centralized replication unicast TRILL 213 encapsulation from normal unicast TRILL encapsulation, the R- 214 nickname is introduced for centralized replication. When the 215 centralized node receives unicast TRILL encapsulation traffic with 216 the egress nickname R-nickname, it decapsulates the packet and then 217 forwards the packet to the destination RBridges through a 218 distribution tree by re-encapsulation as aforementioned. In TRILL, 219 RBridges can hold multiple nicknames so the centralized RBridge 220 simply obtains another nickname to use as the R-nickname. The 221 centralized RBridge or RBridges should announce their R-nickname to 222 all TRILL campus through the TRILL LSP extension specified in 223 Section 11. 225 4. Frame duplication from remote RBridge 227 Frame duplication may occur when a remote host sends a multi- 228 destination frame to a local CE which has an active-active 229 connection to the TRILL campus. To avoid local CE receiving multiple 230 copies from a remote RBridge, the designated forwarder (DF) 231 mechanism is supported for egress direction multicast traffic. 233 The DF election mechanism [RFC7781] allows only one port of one 234 RBridge in an active-active group to forward multicast traffic from 235 the TRILL campus to the local access side for each VLAN. The basic 236 idea of DF is to elect one RBridge per VLAN from an edge group to be 237 responsible for egressing the BUM traffic. [RFC7781] describes the 238 DF election mechanism among member RBridges involving in an edge 239 group. 241 If the DF election mechanism is used for frame duplication 242 prevention, access ports on an RBridge are categorized as one of 243 three types: non-group, group DF port and group non-DF port. The 244 last two types can be called group ports. Each of the group ports is 245 associated with a pseudo-nickname. If consistent nickname allocation 246 to edge group RBridges is used, it is possible that same pseudo- 247 nickname is associated with more than one port on a single RBridge. 248 A typical scenario is that CE1 is connected to RB1 & RB2 by LAALP1 249 while CE2 is connected to RB1 & RB2 by LAALP2. In order to conserve 250 the number of pseudo-nicknames used, member ports for both LAALP1 251 and LAALP2 on RB1 & RB2 are all associated with the same pseudo- 252 nickname. 254 5. Local forwarding behavior on ingress RBridge 256 When an ingress RBridge (RB1) receives BUM traffic from a local 257 active-active connected CE (CE1) device, the traffic will be 258 injected into the TRILL campus with TRILL encapsulation, and it will 259 be replicated and forwarded to all destination RBridges through 260 central replication, including the ingress RBridge itself, along a 261 TRILL distribution tree. To avoid the traffic looping back to the 262 original sender CE, an ingress nickname of the CE group's pseudo- 263 nickname is used for traffic filtering. 265 However, if there are two CEs, say CE1 and CE2, connecting to the 266 ingress RB1 and each associated with the same pseudo-nickname, RB1 267 needs to locally replicate and forward to CE2, because another copy 268 of the BUM traffic between CE1 and CE2 through TRILL campus will be 269 blocked by the traffic filtering. 271 If CE1 and CE2 are not associated with the same pseudo-nickname, the 272 copy of the BUM traffic between CE1 and CE2 through TRILL campus 273 won't be blocked by the traffic filtering. To avoid duplicated 274 traffic on receiver CE, there cannot be local replicated BUM traffic 275 between these two CEs on ingress RB1. 277 In summary, to ensure correct BUM traffic forwarding behavior for 278 each CE, the local replication behavior on the ingress RBridge is as 279 follows: 281 1. Replicate to the active-active group ports associated with the 282 same pseudo-nickname as that associated with the incoming port. 284 2. Do not replicate to active-active group ports associated with 285 other pseudo-nicknames. 287 3. Do not replicate to non-edge-group ports. 289 The above local forwarding behavior on the ingress RBridge of RB1 290 can be called centralized replication local forwarding behavior A. 292 If ingress RBridge RB1 itself is the centralized replication node, 293 BUM traffic injected by RB1 into the TRILL campus won't loop back to 294 RB1. In this case, the local forwarding behavior is called 295 centralized replication local forwarding behavior B. Behavior B on 296 RB1 is as follows: 298 1. Local replication to the ports associated with the same 299 pseudo-nickname as that associated with the incoming port. 301 2. Local replication to the group DF port associated with 302 different pseudo-nicknames. Do not replicate to group non-DF port 303 associated with different pseudo-nicknames. 305 3. Local replication to non-edge-group ports. 307 6. Loop prevention among RBridges in a edge group 309 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 310 packet through a DF port to an ingress RBridge, that RBridge will 311 forward that packet to all or a subset of the other RBridges that 312 only have non-DF ports for that active-active group. Because BUM 313 traffic forwarding to non-DF ports isn't allowed, in this case the 314 frame won't loop back to the CE. 316 If a CE sends a BUM packet through a non-DF port to an ingress 317 RBridge, say RB1, then RB1 will forward that packet to other 318 RBridges that have a DF port for that active-active group. In this 319 case the frame will loop back to the CE and the traffic split- 320 horizon filtering mechanism is used to avoid looping back among 321 RBridges in the edge group. 323 This split-horizon mechanism relies on the ingress nickname field in 324 the TRILL header to check if a packet's egress port belongs to a 325 same active-active group as the packet's incoming port to the TRILL 326 campus. 328 When the ingress RBridge receives BUM traffic from an active-active 329 connected CE device, the traffic will be sent through the TRILL 330 campus with TRILL encapsulation to a centralized RBridge. There it 331 will be replicated and forwarded to its destination RBridges, which 332 include ingress RBridge itself, through a TRILL distribution tree. 333 If the same pseudo-nickname is used for two active-active access CEs 334 as ingress nickname, an egress RBridge can use that nickname to 335 filter traffic forwarding to all local CEs. In this case, the 336 traffic between these two CEs goes through the local RBridge and 337 another copy of the traffic from the TRILL campus is filtered. If 338 different ingress nicknames are used for two connecting CE devices, 339 the access ports connecting to these two CEs should be isolated from 340 each other. The BUM traffic between these two CEs should go through 341 the TRILL campus, otherwise the destination CE connected to same 342 RBridge with the sender CE will receive two copies of the traffic. 344 7. Centralized replication forwarding process 345 +-----------+ 346 | (RB5) | 347 +-----------+ 348 | 349 +-----------+ 350 | (RB4) | 351 +-----------+ 353 | | | 354 -------- | -------- 355 | | | 356 +------+ +------+ +------+ 357 |(RB1) | |(RB2) | | (RB3)| 358 +------+ +------+ +------+ 359 * | * | * | ^ 360 * | * | * | ^ 361 * ----------*-------------*-- ^ 362 ***************************** | ^ 363 LAALP1 * LAALP2 | ^ 364 +------+ +------+ +------+ 365 | CE1 | | CE2 | | CE3 | 366 +------+ +------+ +------+ 367 Figure 1 TRILL Active-active access 369 Assuming the centralized replication solution is used in the example 370 network of above figure 1, RB5 is the distribution tree root and 371 centralized replication node, CE1 and CE2 are active-active accessed 372 to RB1, RB2, and RB3 through LAALP1 and LAALP2 respectively, CE3 is 373 single homed to RB3. The RBridge's own nicknames of RB1 to RB5 are 374 nick1 to nick5 respectively. RB1, RB2, and RB3 use the same pseudo- 375 nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The 376 R-nickname on the centralized replication node of RB5 is S-nick. 378 The BUM traffic forwarding process from CE1 to CE2 and CE3 is as 379 follows: 381 1. CE1 sends BUM traffic to RB3. 383 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 384 also sends the traffic to RB5 using unicast TRILL encapsulation. In 385 the TRILL Header, the ingress nickname is set as P-nick and the 386 egress nickname is set as S-nick. 388 3. RB5 decapsulates the unicast TRILL Data packet. Then it uses a 389 distribution tree to forward the packet as a multi-destination TRILL 390 Data packet. The egress nickname in the multi-destination TRILL 391 Header is the nick5 and the ingress nickname is still P-nick. 393 4. RB4 receives multicast TRILL traffic from RB5. Traffic 394 incoming port is the up port facing the distribution tree root, 395 RB4's RPF check will be correct based on the changed RPF port 396 calculation algorithm in this document. After the RPF check is 397 performed, it forwards the traffic to all other egress RBridges (RB1, 398 RB2, and RB3). 400 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 401 the multi-destination TRILL Data packet. Because the ingress 402 nickname of P-nick is equivalent to the nickname of local LAALPs 403 connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 404 and CE2 to avoid duplicated frame. RB3 only forwards the packet to 405 CE3. 407 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 408 forwarding process is similar to the process on RB3, i.e., because 409 the ingress nickname of P-nick is equivalent to the nickname of the 410 local LAALPs connecting CE1 and CE2, they also don't forward the 411 traffic to local CE1 and CE2. 413 8. BUM traffic load balancing among multiple centralized nodes 415 To support unicast TRILL encapsulation BUM traffic load balancing, 416 multiple centralized replication nodes can be deployed and the 417 traffic can be spread over these nodes based on VLAN or FGL. 418 Furthermore, if it was desirable for a centralized node to be sent 419 more of this BUM traffic, it could hold two or more R-nicknames. The 420 share of BUM traffic it would receive would be proportional to the 421 number of R-nicknames it held. 423 Assuming there are k different R-nicknames held by centralized nodes 424 in a TRILL campus. The VLAN-based (or FGL-based [RFC7172]) load 425 balancing algorithm used by ingress active-active access RBridge is 426 as follows: 428 1. All R-nicknames are ordered and numbered from 0 to k-1 in 429 ascending order treating the nicknames as unsigned 16-bit integers. 431 2. For VLAN or FGL ID m, choose the R-nickname whose number 432 equals (m mod k) as egress nickname for BUM traffic unicast TRILL 433 encapsulation. 435 For examples, there are 3 R-Nicknames (RN). The RNs will be ordered 436 RN0 to RN2. Assuming there are 5 VLANs from VLAN ID 1 to ID 5 437 spreading among edge RBridges, the traffic in VLAN 1 will go to RN1, 438 VLAN 2 will go to RN2, and so on. 440 When an ingress RBridge participating in active-active connection 441 receives BUM traffic from local CE, the RBridge decides which R- 442 nickname to send the traffic to based on the VLAN-based load 443 spreading algorithm, thus VLAN/FGL-based load balancing for the BUM 444 traffic can be achieved using multiple centralized nodes/ multiple 445 R-nicknames. 447 9. Co-existing with the CMT solution 449 +------+ +------+ 450 |(RB6) | |(RB7) | 451 +------+ +------+ 452 ------------------|-----------|---------------------- 453 | | | | | 454 +------+ +------+ +------+ +------+ +------+ 455 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 456 +------+ +------+ +------+ +------+ +------+ 457 | | | | | 458 ------------ ------------------------- 459 | | 460 +------+ +------+ 461 | CE1 | | CE2 | 462 +------+ +------+ 463 Figure 2 CMT and centralized replication co-existing scenario 465 Both the centralized replication solution and the CMT [RFC7783] 466 solution rely on using pseudo-nicknames to avoid MAC flip-flop on 467 remote RBridges. These two solutions can co-exist in a single TRILL 468 campus. Each solution can be selected by each active-active edge 469 group of RBridges independently. 471 As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active- 472 active access, RB3, RB4, and RB5 use the centralized replication for 473 CE2's active-active access. 475 For the centralized replication solution, edge group RBridges MUST 476 announce the local pseudo-nickname using Nickname Flags APPsub-TLV 477 with C-flag set. A nickname with the C-flag set is called a "C- 478 nickname". A transit RBridge will perform the centralized 479 replication specific RPF check algorithm if it receives TRILL Data 480 packets with a C-nickname as ingress nickname. 482 In this case, an edge group using CMT [RFC7783] MUST NOT set the C- 483 nickname flag on the pseudo-nickname it is using. To avoid confusion, 484 a pseudo-nickname MUST NOT be shared between a centralized 485 replication edge group and a CMT-based edge group. 487 10. Network Upgrade Analysis 489 Centralized nodes will typically need software and hardware upgrades 490 to support centralized replication, which stitches together the TRILL 491 unicast traffic decapsulation process and the process of normal 492 TRILL multicast traffic forwarding along distribution tree. 494 Active-active connection edge RBridges will typically need software 495 and hardware upgrade to support unicast TRILL encapsulation for BUM 496 traffic; the process is similar to other head-end replication 497 processes. 499 Transit nodes typically need a software upgrade to support the 500 changed RPF port calculation algorithm. 502 11. TRILL protocol extensions 504 Two new flags, "R" and "C", are specified in the Nickname Flags 505 APPsub-TLV [RFC7780]. A nickname with the "R" flag set is called an 506 R-nickname and a nickname with the the "C" flag set is called a C- 507 nickname. The R-nickname is a specialized nickname attached to a 508 centralized node to differentiate unicast TRILL encapsulated BUM 509 traffic from normal unicast TRILL traffic. The C-nickname flag is 510 set on the psudo-nickname for each edge group. A C-nickname is a 511 specialized pseudo-nickname for which transit RBridges perform a 512 different RPF check algorithm for TRILL data packets with the C- 513 nickname in the ingress nickname field. 515 When active-active edge RBridges use centralized replication to 516 nickname and the C-nickname is used as ingress nickname in the TRILL 517 header for the unicast TRILL encapsulation of BUM traffic. 519 11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV 521 If this APPsub-TLV is being advertised by an RBridge that does not 522 have the nickname appearing in the Nickname Flags APPsub-TLV, the R 523 and C flag bits in the APPsub-TLV MUST be treated as if they were 524 zero. 526 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 527 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 528 | Nickname | 529 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 530 |IN|SE|R | C| RESV | 531 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 532 NICKFLAG RECORD 534 o R = If R flag is one, it indicates that the advertising 535 TRILL switch holding Nickname is a centralized replication node, and 536 Nickname is used as egress nickname for edge group RBridges to 537 inject BUM traffic into the TRILL campus when the edge group 538 RBridges use centralized replication solution for active-active 539 access. If flag is zero, that nickname will not be used for that 540 purpose. 542 o C = If C flag is one, it indicates that the TRILL traffic 543 with this nickname as an ingress nickname that requires the special 544 RPF check algorithm specified in Section 3. If flag is zero, that 545 nickname will not be used for that purpose. 547 It is possible, due to errors or due to transient inconsistent LSPs 548 when the link state database is converging after a configuration 549 change or the like for there to be inconsistent Nickname Flags 550 APPsub-TLVs for the same nickname. In this case it is RECOMMENDED 551 that the nickname be treated as an R-nickname / C-nickname if any 552 Nickname Flags APPsub-TLV for that nickname has the R / C flag set. 554 12. Security Considerations 556 This draft does not introduce any extra security risks. For general 557 TRILL Security Considerations, see [RFC6325]. For Security 558 Considerations related to pseudo-nickname active-active, see 559 [RFC7781]. 561 13. IANA Considerations 563 IANA is requested to assign two bits in the Nickname Flags APPsubTLV 564 flags for the R and C bits discussed in Section 11.1 [Bits 3 and 4 565 suggested] and update the "NickFlags" Bits registry on the TRILL 566 Parameters page as follows: 568 Bit Mnemonic Description Reference 569 --- -------- -------------------- ----------- 570 3 R Replication Nickname [This document] 571 4 C Special RFC Check [This document] 573 14. References 575 14.1. Normative References 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, 579 . 581 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 582 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, . 585 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 586 Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 587 6325, DOI 10.17487/RFC6325, July 2011, . 590 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. 591 Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained 592 Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, . 595 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and 596 A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of 597 IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, . 600 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 601 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links 602 (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 603 10.17487/RFC7780, February 2016, . 605 14.2. Informative References 607 [RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, 608 "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for 609 Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, 610 . 612 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem 613 Statement and Goals for Active-Active Connection at the Transparent 614 Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 615 10.17487/RFC7379, October 2014, . 617 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated 618 Multicast Trees (CMT) for Transparent Interconnection of Lots of Links 619 (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, . 622 15. Acknowledgments 624 The authors wish to acknowledge the important contributions of 625 Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia. 627 Authors' Addresses 629 Weiguo Hao 630 Huawei Technologies 631 101 Software Avenue, 632 Nanjing 210012 633 China 634 Email: haoweiguo@huawei.com 636 Yizhou Li 637 Huawei Technologies 638 101 Software Avenue, 639 Nanjing 210012 640 China 641 Email: liyizhou@huawei.com 643 Muhammad Durrani 644 Cisco 645 Email: mdurrani@cisco.com 647 Sujay Gupta 648 IP Infusion 649 RMZ Centennial 650 Mahadevapura Post 651 Bangalore - 560048 652 India 653 Email: sujay.gupta@ipinfusion.com 655 Andrew Qu 656 MediaTec 657 Email: laodulaodu@gmail.com 659 Tao Han 660 Huawei Technologies 661 101 Software Avenue, 662 Nanjing 210012 663 China 664 Email: billow.han@huawei.com