idnits 2.17.1 draft-hao-trill-centralized-replication-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TRILLPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 455: '... Nickname Sub-Tlv specified in [RFC6326] to TRILL network and MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2014) is 3528 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) -- Looks like a reference, but probably isn't: 'TRILLPN' on line 195 -- Looks like a reference, but probably isn't: 'RFC6325' on line 515 -- Looks like a reference, but probably isn't: 'RFC6165' on line 129 -- Looks like a reference, but probably isn't: 'RFC6326bis' on line 129 -- Looks like a reference, but probably isn't: 'RFC2119' on line 176 -- Looks like a reference, but probably isn't: 'CMT' on line 179 -- Looks like a reference, but probably isn't: 'RFC6326' on line 455 == Unused Reference: '1' is defined on line 526, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 529, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 538, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 542, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 546, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-trill-active-active-connection-prob-00 == Outdated reference: A later version (-11) exists of draft-ietf-trill-cmt-00 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Weiguo Hao 2 Yizhou Li 3 Tao Han 4 Internet Draft Huawei 5 S. Hares 6 Hickory Hill Consulting 7 Muhammad Durrani 8 Brocade 9 Sujay Gupta 10 IP Infusion 11 Intended status: Standard Track August 29, 2014 12 Expires: February 2015 14 Centralized Replication for BUM traffic in active-active edge 15 connection 16 draft-hao-trill-centralized-replication-02.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, and it may not be 26 published except as an Internet-Draft. 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, except to publish it 31 as an RFC and to translate it into languages other than English. 33 This document may contain material from IETF Documents or IETF 34 Contributions published or made publicly available before November 35 10, 2008. The person(s) controlling the copyright in some of this 36 material may not have granted the IETF Trust the right to allow 37 modifications of such material outside the IETF Standards Process. 38 Without obtaining an adequate license from the person(s) controlling 39 the copyright in such materials, this document may not be modified 40 outside the IETF Standards Process, and derivative works of it may 41 not be created outside the IETF Standards Process, except to format 42 it for publication as an RFC or to translate it into languages other 43 than English. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as Internet- 48 Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six 51 months and may be updated, replaced, or obsoleted by other documents 52 at any time. It is inappropriate to use Internet-Drafts as 53 reference material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html 61 This Internet-Draft will expire on November 29, 2014. 63 Copyright Notice 65 Copyright (c) 2014 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with 73 respect to this document. Code Components extracted from this 74 document must include Simplified BSD License text as described in 75 Section 4.e of the Trust Legal Provisions and are provided without 76 warranty as described in the Simplified BSD License. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (http://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with 83 respect to this document. 85 Abstract 87 In TRILL active-active access scenario, RPF check failure issue may 88 occur when pseudo-nickname mechanism in [TRILLPN] is used. This 89 draft describes a solution to the RPF check failure issue through 90 centralized replication for BUM (Broadcast, Unknown unicast, 91 Mutlicast) traffic. The solution has all ingress RBs send BUM 92 traffic to a centralized node via unicast TRILL encapsulation. When 93 the centralized node receives the BUM traffic, it decapsulates the 94 traffic and forwards the BUM traffic to all destination RBs using a 95 distribution tree established via the TRILL base protocol. To avoid 96 RPF check failure on a RBridge sitting between the ingress RBridge 97 and the centralized replication node, some change of RPF calculation 98 algorithm is required. RPF calculation on each RBridge should use 99 the centralized node as ingress RB instead of the real ingress 100 RBridge of RBv to perform the calculation. 102 Table of Contents 104 1. Introduction ................................................ 3 105 2. Conventions used in this document............................ 4 106 3. Centralized Replication Solution Overview.................... 5 107 4. Frame duplication from remote RB............................. 6 108 5. Local forwarding behavior on ingress RBridge................. 6 109 6. Loop prevention among RBridges in a edge group............... 7 110 7. Centralized replication forwarding process................... 9 111 8. BUM traffic loadbalancing among multiple centralized nodes...10 112 8.1. Vlan-based loadbalancing............................... 10 113 8.2. Flow-based loadbalancing............................... 11 114 9. Network Migration Analysis.................................. 11 115 10. TRILL protocol extension................................... 12 116 10.1. The Unicast BUM Nickname sub-TLV...................... 12 117 11. Security Considerations.................................... 12 118 12. IANA Considerations........................................ 12 119 13. References ................................................ 12 120 13.1. Normative References.................................. 12 121 13.2. Informative References................................ 13 122 14. Acknowledgments ........................................... 13 124 1. Introduction 126 The IETF TRILL (Transparent Interconnection of Lots of Links) 127 [RFC6325] protocol provides loop free and per hop based multipath 128 data forwarding with minimum configuration. TRILL uses IS-IS 129 [RFC6165] [RFC6326bis] as its control plane routing protocol and 130 defines a TRILL specific header for user data. 132 Classic Ethernet device (CE) devices typically are multi-homed to 133 multiple edge RBridges which form an edge group. All of the uplinks 134 of CE are bundled as a Multi-Chassis Link Aggregation (MC-LAG). An 135 active-active flow-based load sharing mechanism is normally 136 implemented to achieve better load balancing and high reliability. A 137 CE device can be a layer 3 end system by itself or a bridge switch 138 through which layer 3 end systems access to TRILL campus. 140 In active-active access scenario, pseudo-nickname solution in 141 [TRILLPN] can be used to avoid MAC flip-flop on remote RBs. The 142 basic idea is to use a virtual RBridge of RBv with a single pseudo- 143 nickname to represent an edge group that MC-LAG connects to. Any 144 member RBridge of that edge group should use this pseudo-nickname 145 rather than its own nickname as ingress nickname when it injects 146 TRILL data frames to TRILL campus. The use of the nickname solves 147 the address flip flop issue by making the MAC address learnt by the 148 remote RBridge bound to pseudo-nickname. However, it introduces 149 another issue, which is incorrect packet drop by RPF check failure. 150 Due to edge RBridges which use a pseudo-nickname other than own 151 nicknames as the ingress nickname (Eg. Nick-Y) when the RBbridge 152 forwards BUM traffic from local CE, the traffic will be treated by 153 an RBridge (RBn) sitting between the ingress RB and distribution 154 tree root as traffic whose ingress point is the virtual RBridge of 155 RBv. If same distribution tree is used by these different edge 156 RBridges, the traffic may arrive at RBn from different ports. Then 157 the RPF check fails, and some of the traffic receiving from 158 unexpected ports will be dropped by RBn. 160 This document proposes a centralized replication solution for 161 broadcast, unknown unicast, multicast(BUM) traffic to solve the 162 issue of incorrect packet drop by RPF check failure. The basic idea 163 is that all ingress RBs send BUM traffic to a centralized node which 164 is recommended to be a distribution tree root using unicast TRILL 165 encapsulation. When the centralized node receives that traffic, it 166 decapsulates it and then forwards the BUM traffic to all destination 167 RBs using a distribution tree established as per TRILL base protocol. 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC-2119 174 [RFC2119].The acronyms and terminology in [RFC6325] is used herein 175 with the following additions: 177 BUM - Broadcast, Unknown unicast, and Multicast 179 CE - As in [CMT], Classic Ethernet device (end station or bridge). 181 The device can be either physical or virtual equipment. 183 3. Centralized Replication Solution Overview 185 When an edge RB receives BUM traffic from a CE device, it acts as 186 ingress RB and uses unicast TRILL encapsulation instead of multicast 187 TRILL encapsulation to send the traffic to a centralized node. The 188 centralized node is recommended to be a distribution tree root. 190 The TRILL header of the unicast TRILL encapsulation contains an 191 "ingress RBridge nickname" field and an "egress RBridge nickname" 192 field. If ingress RB receives the traffic from the port which is in 193 a MC-LAG, it should set the ingress RBridge nickname to be the 194 pseudo-nickname to avoid MAC flip-flop on remote RBs as per 195 [TRILLPN]. Otherwise the ingress nickname should be set to ingress 196 RBridge's own nickname. The egress RBridge nickname is set to the 197 special nickname of the centralized node which is used to 198 differentiate the unicast TRILL encapsulation BUM traffic from 199 normal unicast TRILL traffic. 201 When the centralized node receives the unicast TRILL encapsulated 202 BUM traffic from ingress RB, the node decapsulates the packet. Then 203 the centralized node replicates and forwards the BUM traffic to all 204 destination RBs using one of the distribution trees established as 205 per TRILL base protocol, if the centralized node is the root of a 206 distribution tree, the recommended distribution tree is the tree 207 whose root is the centralized node itself. When the centralized node 208 forwards the BUM traffic, ingress nickname remains the same as that 209 in frame it received to ensure that the MAC address learnt by all 210 egress RBridges bound to pseudo-nickname. 212 When the replicatedtraffic is forwarded on each RBridge along the 213 distribution tree starting from the centralized node, RPF check will 214 be performed as per RFC6325. For any RBridge sitting between the 215 ingress RBridge and the centralized replication node, the traffic 216 incoming port should be the centralized node facing port as the 217 multicast traffic always comes from the centralized node in this 218 solution. However the RPF port as result of distribution tree 219 calculation as per RFC 6325 will be the real ingress RB facing port 220 as it uses virtual RBridge as ingress RB, so RPF check will fail. To 221 solve this problem, some change of RPF calculation algorithm is 222 required. RPF calculation on each RBridge should use the centralized 223 node as ingress RB instead of the real ingress virtual RBridge to 224 perform the calculation. As a result, RPF check will point to the 225 centralized node facing port on the RBridge for multi-destination 226 traffic. It prevents the incorrect frame discard by RPF check. 228 To differentiate the unicast TRILL encapsulation BUM traffic from 229 normal unicast TRILL traffic on a centralized node, besides the 230 centralized node's own nickname, a special nickname should be 231 introduced for centralized replication. Only when the centralized 232 node receives unicast TRILL encapsulation traffic with egress 233 nickname equivalent to the special nickname, the node does unicast 234 TRILL decapsulaton and then forwards the traffic to all destination 235 RBs through a distribution tree. The centralized nodes should 236 announce its special use nickname to all TRILL campus through TRILL 237 LSP extension. 239 4. Frame duplication from remote RB 241 Frame duplication may occur when a remote host sends multi- 242 destination frame to a local CE which has an active-active 243 connection to the TRILL campus. To avoid local CE receiving multiple 244 copies from a remote RBridge, the designated forwarder (DF) 245 mechanism should be supported for egress direction multicast traffic. 247 DF election mechanism allows only one port in one RB of MC-LAG to 248 forward multicast traffic from TRILL campus to local access side for 249 each VLAN. The basic idea of DF is to elect one RBridge per VLAN 250 from an edge group to be responsible for egressing the multicast 251 traffic. [draft-hao-trill-dup-avoidance-active-active-02] describes 252 the detail DF mechanism and TRILL protocol extension for DF election. 254 If DF-election mechanism is used for frame duplication prevention, 255 access ports on an RB are categorized as three types: non mc-lag, 256 mc-lag DF port and mc-lag non-DF port. The last two types can be 257 called mc-lag port. For each of the mc-lag port, there is a pseudo- 258 nickname associated. If consistent nickname allocation per edge 259 group RBridges is used, it is possible that same pseudo-nickname 260 associated to more than one port on a single RB. A typical scenario 261 is that CE1 is connected to RB1 & RB2 by mc-lag1 while CE2 is 262 connected to RB1 & RB2 by mc-lag 2. In order to save the number of 263 pseudo-nickname used, member ports for both mc-lag1 and mc-lag2 on 264 RB1 & RB2 are all associated to pseudo-nickname pn1. 266 5. Local forwarding behavior on ingress RBridge 268 When a ingress RBridge(RB1) receives BUM traffic from an active- 269 active accessing CE(CE1) device, the traffic will be injected to 270 TRILL campus through TRILL encapsulation, and it will be replicated 271 and forwarded to all destination RBs which include ingress RB itself 272 along a TRILL distribution tree. So the traffic will return to the 273 ingress RBridge. To avoid the traffic looping back to original 274 sender CE, ingress nickname can be used for traffic filtering. 276 If there are two local connecting CE(CE1 and CE2) devices on ingress 277 RB, the BUM traffic between these two CEs can't be forwarded locally 278 and through TRILL campus simultaneously, otherwise duplicated 279 traffic will be received by destination CE. Local forwarding 280 behavior on ingress RBridge should be carefully designed. 282 To avoid duplicated traffic on receiver CE, local replication 283 behavior on RB1 is as follows: 285 1. Local replication to the ports associated with the same pseudo- 286 nickname as that associated to the incoming port as per RFC6325. 288 2. Do not replicate to mc-lag port associated with different pseudo- 289 nickname. 291 3. Do not replicate to non mc-lag ports. 293 The above local forwarding behavior on the ingress RB of RB1 can be 294 called centralized local forwarding behavior A. 296 If ingress RB of RB1 itself is the centralized node, BUM traffic 297 injected to TRILL campus won't loop back to RB1. In this case, the 298 local forwarding behavior is called centralized local forwarding 299 behavior B. The local replication behavior on RB1 is as follows: 301 1. Local replication to non mc-lag ports as per RFC6325. 303 2. Local replication to the ports associated with the same pseudo- 304 nickname as that associated to the incoming port as per RFC6325. 306 3. Local replication to the mc-lag DF port associated with different 307 pseudo-nickname as per RFC6325. Do not replicate to mc-lag non-DF 308 port associated with different pseudo-nickname. 310 6. Loop prevention among RBridges in a edge group 312 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 313 packet through DF port to a ingress RB, it will forward that packet 314 to all or subset of the other RBs that only have non-DF ports for 315 that MC-LAG. Because BUM traffic forwarding to non-DF port isn't 316 allowed, in this case the frame won't loop back to the CE. 318 If a CE sends a BUM packet through non-DF port to a ingress RB, say 319 RB1, then RB1 will forward that packet to other RBridges that have 320 DF port for that MC-LAG. In this case the frame will loop back to 321 the CE and traffic split-horizon filtering mechanism should be used 322 to avoid looping back among RBridges in a edge group. 324 Split-horizon mechanism relies on ingress nickname to check if a 325 packet's egress port belongs to a same MC-LAG with the packet's 326 incoming port to TRILL campus. 328 When the ingress RBridge receives BUM traffic from an active-active 329 accessing CE device, the traffic will be injected to TRILL campus 330 through TRILL encapsulation, and it will be replicated and forwarded 331 to all destination RBs which include ingress RB itself through TRILL 332 distribution tree. If same pseudo-nickname is used for two active- 333 active access CEs as ingress nickname, egress RB can use the 334 nickname to filter traffic forwarding to all local CE. In this case, 335 the traffic between these two CEs goes through local RB and another 336 copy of the traffic from TRILL campus is filtered. If different 337 ingress nickname is used for two connecting CE devices, the access 338 ports connecting to these two CEs should be isolated with each other. 339 The BUM traffic between these two CEs should go through TRILL campus, 340 otherwise the destination CE connected to same RB with the sender CE 341 will receive two copies of the traffic. 343 Do note that the above sections on techniques to avoid frame 344 duplication, loop prevention is applicable assuming the Link 345 aggregation technology in use is unaware of the frame duplication 346 happening. For example using mechanisms like IEEE802.1AX, 347 Distributed Resilient Network Interconnect (DRNI) specs implements 348 mechanism similar to DF and also avoids some cases of frame 349 duplication & looping. 351 7. Centralized replication forwarding process 353 +-----------+ 354 | (RB5) | 355 +-----------+ 356 | 357 +-----------+ 358 | (RB4) | 359 +-----------+ 361 | | | 362 -------- | -------- 363 | | | 364 +------+ +------+ +------+ 365 |(RB1) | |(RB2) | | (RB3)| 366 +------+ +------+ +------+ 367 * | * | * | ^ 368 * | * | * | ^ 369 * -------------------------------^ 370 ***************************** | ^ 371 MC-LAG1 * MC-LAG2 | ^ 372 +------+ +------+ +------+ 373 | CE1 | | CE2 | | CE3 | 374 +------+ +------+ +------+ 375 Figure 1 TRILL Active-active access 377 Assuming the centralized replication solution is used in the network 378 of above figure 1, RB5 is the distribution tree root and centralized 379 replication node, CE1 and CE2 are active-active accessed to RB1,RB2 380 and RB3 through MC-LAG1 and MC-LAG2 respectively, CE3 is single 381 homed to RB3. The RBridge's own nickname of RB1 to RB5 are nick1 to 382 nick5 respectively. RB1,RB2 and RB3 use same pseudo-nickname for MC- 383 LAG1 and MC-LAG2, the pseudo-nickname is P-nick. The special use 384 nickname on the centralized replication node of RB5 is S-nick. 386 The BUM traffic forwarding process from CE1 to CE2,CE3 is as follows: 388 1. CE1 sends BUM traffic to RB3. 390 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 also 391 sends the traffic to RB5 through unicast TRILL encapsulation. 392 Ingress nickname is set as P-nick, egress nickname is set as S- 393 nick. 395 3. RB5 decapsulates the unicast TRILL packet. Then it uses the 396 distribution tree whose root is RB5 to forward the packet. The 397 egress nickname in the trill header is the nick5. Ingress 398 nickname is still P-nick. 400 4. RB4 receives multicast TRILL traffic from RB5. Traffic incoming 401 port is the up port facing to distribution tree root, RPF check 402 will be correct based on the changed RPF port calculation 403 algorithm in this document. After RPF check is performed, it 404 forwards the traffic to all other egress RBs(RB1,RB2 and RB3). 406 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 407 the multicast TRILL packet. Because ingress nickname of P-nick is 408 equivalent to the nickname of local MC-LAGs connecting CE1 and 409 CE2, it doesn't forward the traffic to CE1 and CE2 to avoid 410 duplicated frame. RB3 only forwards the packet to CE3. 412 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 413 forwarding process is similar to the process on RB3, i.e, because 414 ingress nickname of P-nick is equivalent to the nickname of local 415 MC-LAGs connecting CE1 and CE2, they also don't forward the 416 traffic to local CE1 and CE2. 418 8. BUM traffic loadbalancing among multiple centralized nodes 420 To support unicast TRILL encapsulation BUM traffic load balancing, 421 multiple centralized replication node can be deployed and the 422 traffic can be load balanced on these nodes in vlan-based or flow- 423 based mode. 425 8.1. Vlan-based loadbalancing 427 Assuming there are k centralized nodes in TRILL campus, VLAN- 428 based(or FGL-based, etc) loadbalancing algorithm used by ingress 429 active-active access RBridge is as follows: 431 1. All centralized nodes are ordered and numbered from 0 to k-1 433 in ascending order according to the 7-octet IS-IS ID. 435 2. For VLAN ID m, choose the centralized node whose number equals 436 (m mod k). 438 An example of the m mod K, is that for 3 centralized nodes (CN) and 439 5 VLANs is: VLAN 0 goes to CN0, VLAN1 goes to CN1, VLAN2 goes to CN2, 440 VLAN4 goes to CN0, and VLAN5 goes to CN1. 442 When a ingress RBridge participating active-active connection 443 receives BUM traffic from local CE, the RB decides to send the 444 traffic to which centralized node based on the VLAN-based 445 loadbalancing algorithm, vlan-based loadbalancing for the BUM 446 traffic can be achieved among multiple centralized nodes. 448 8.2. Flow-based loadbalancing 450 To support flow-based loadbalancing for BUM traffic between 451 different centralized node, anycast special use nickname mechanism 452 should be introduced, which means a same special use nickname is 453 attached to both physical centralized node at the same time. Each 454 centralized node announces the special use nickname through the 455 Nickname Sub-Tlv specified in [RFC6326] to TRILL network and MUST 456 ignore the nickname collision check as defined in basic TRILL 457 protocol. 459 The egress nickname of unicast TRILL encapsulation for BUM traffic 460 from ingress RB is the special use nickname. The unicast TRILL 461 encapsulation BUM traffic would go to any one of the physical 462 centralized nodes by the natural support of ECMP from TRILL protocol. 464 The physical centralized node will decapsulate the unicast TRILL 465 encapsulation and forwards it through any one of the distribution 466 trees established per RFC 6325 with the original source, and BUM 467 destination. Because ECMP of the unicast TRILL encapsulation BUM 468 traffic is supported among multiple centralized nodes, so it can 469 achieve better link bandwidth usage than VLAN-based(or FGL-based, 470 etc)loadbalancing. 472 9. Network Migration Analysis 474 Centralized nodes need software and hardware upgrade to support 475 centralized replication process, which stitches TRILL unicast 476 traffic decapsulation process and the process of normal TRILL 477 multicast traffic forwarding along distribution tree. 479 Active-active connection edge RBs need software and hardware upgrade 480 to support unicast TRILL encapsulation for BUM traffic, the process 481 is similar to normal head-end replication process. 483 Transit nodes need software upgrade to support RPF port calculation 484 algorithm change. 486 10. TRILL protocol extension 488 The Unicast BUM Nickname TLV is introduced to announce its special 489 use nickname for centralized replication by centralized node. It is 490 carried in an LSP PDU. Ingress RBs rely on the TLV to learn the 491 egress nickname of TRILL unicast encapsulation for BUM traffic. 493 10.1. The Unicast BUM Nickname sub-TLV 495 +-+-+-+-+-+-+-+-+ 496 | Type | (1 byte) 497 +-+-+-+-+-+-+-+-+ 498 | Length | (1 byte) 499 +-+-+-+-+-+-+-+-+-+-+-+--+ 500 | Uni BUM Nickname | (4 bytes) 501 +-+-+-+-+-+-+-+-+-+-+-+-+| 502 o Type: Router Capability sub-TLV type, TBD (Uni-BUM-VLANs). 504 o Length: indicates the length of Uni BUM Nickname field, it 505 is a fixed value of 4. 507 o Uni BUM Nickname: The nickname is exclusively used for 508 centralized replication solution purpose. Ingress RBs use the 509 nickname as egress nickname in trill header of unicast TRILL 510 encapsulation for BUM traffic. 512 11. Security Considerations 514 This draft does not introduce any extra security risks. For general 515 TRILL Security Considerations, see [RFC6325]. 517 12. IANA Considerations 519 This document requires no IANA Actions. RFC Editor: Please remove 520 this section before publication. 522 13. References 524 13.1. Normative References 526 [1] [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 527 Layer-2 Systems", RFC 6165, April 2011. 529 [2] [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol 530 Specification", RFC 6325, July 2011. 532 [3] [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., 533 and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis- 534 rfc6326bis, work in progress. 536 13.2. Informative References 538 [4] [TRILLPN] Zhai,H., et.al., "RBridge: Pseduonode nickname", 539 draft-hu-trill-pseudonode-nickname, Work in progress, November 540 2011. 542 [5] [TRILAA] Li,Y., et.al., " Problem Statement and Goals for 543 Active-Active TRILL Edge", draft-ietf-trill-active-active- 544 connection-prob-00, Work in progress, July 2013. 546 [6] [CMT] Senevirathne, T., Pathangi, J., and J. Hudson, 547 "Coordinated Multicast Trees (CMT)for TRILL", draft-ietf- 548 trill-cmt-00.txt Work in Progress, April 2012. 550 14. Acknowledgments 552 The authors wish to acknowledge the important contributions of 553 Hongjun Zhai, Xiaomin Wu, Liang Xia. 555 Authors' Addresses 557 Weiguo Hao 558 Huawei Technologies 559 101 Software Avenue, 560 Nanjing 210012 561 China 562 Phone: +86-25-56623144 563 Email: haoweiguo@huawei.com 565 Yizhou Li 566 Huawei Technologies 567 101 Software Avenue, 568 Nanjing 210012 569 China 570 Phone: +86-25-56625375 571 Email: liyizhou@huawei.com 573 Tao Han 574 Huawei Technologies 575 101 Software Avenue, 576 Nanjing 210012 577 China 578 Phone: +86-25-56623454 579 Email: billow.han@huawei.com 580 Susan Hares 581 Hickory Hill Consulting 582 7453 Hickory Hill 583 Saline, CA 48176 584 USA 585 Email: shares@ndzh.com 587 Muhammad Durrani 588 Brocade communications Systems, Inc 589 EMail: mdurrani@Brocade.com 591 Sujay Gupta 592 IP Infusion, 593 RMZ Centennial 594 Mahadevapura Post 595 Bangalore - 560048 596 India 597 EMail: sujay.gupta@ipinfusion.com