idnits 2.17.1 draft-ietf-trill-centralized-replication-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TRILLPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 46 has weird spacing: '... months and ...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (April 30, 2015) is 3278 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 164 -- Looks like a reference, but probably isn't: 'RFC6325' on line 503 -- Looks like a reference, but probably isn't: 'RFC6165' on line 98 -- Looks like a reference, but probably isn't: 'RFC6326bis' on line 98 -- Looks like a reference, but probably isn't: 'RFC2119' on line 145 -- Looks like a reference, but probably isn't: 'CMT' on line 148 -- Looks like a reference, but probably isn't: 'RFC7180bis' on line 465 == Unused Reference: '1' is defined on line 530, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 534, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 538, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 524, 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 ** Downref: Normative reference to an Informational draft: draft-ietf-trill-active-active-connection-prob (ref. '2') == Outdated reference: A later version (-11) exists of draft-ietf-trill-cmt-00 == Outdated reference: A later version (-07) exists of draft-ietf-trill-rfc7180bis-00 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group W. Hao 2 INTERNET-DRAFT Y. Li 3 Intended Status: Standard 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: October 2015 April 30, 2015 14 Centralized Replication for BUM traffic in active-active edge 15 connection 16 draft-ietf-trill-centralized-replication-02.txt 18 Abstract 20 In TRILL active-active access scenario, RPF check failure issue may 21 occur when pseudo-nickname mechanism in [TRILLPN] is used. This 22 draft describes a solution to the RPF check failure issue through 23 centralized replication for BUM (Broadcast, Unknown unicast, 24 Mutlicast) traffic. The solution has all ingress RBs send BUM 25 traffic to a centralized node via unicast TRILL encapsulation. When 26 the centralized node receives the BUM traffic, it decapsulates the 27 traffic and forwards the BUM traffic to all destination RBs using a 28 distribution tree established via the TRILL base protocol. To avoid 29 RPF check failure on a RBridge sitting between the ingress RBridge 30 and the centralized replication node, some change of RPF calculation 31 algorithm is required. RPF calculation on each RBridge should use 32 the centralized node as ingress RB instead of the real ingress 33 RBridge of RBv to perform the calculation. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with 38 the provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other 47 documents at any time. It is inappropriate to use Internet-Drafts 48 as reference material or to cite them other than as "work in 49 progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/1id-abstracts.html 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction ................................................ 3 75 2. Conventions used in this document............................ 4 76 3. Centralized Replication Solution Overview.................... 4 77 4. Frame duplication from remote RB............................. 5 78 5. Local forwarding behavior on ingress RBridge................. 6 79 6. Loop prevention among RBridges in a edge group............... 7 80 7. Centralized replication forwarding process................... 8 81 8. BUM traffic loadbalancing among multiple centralized nodes....9 82 9. Co-existing with CMT solution............................... 10 83 10. Network Migration Analysis................................. 11 84 11. TRILL protocol extension................................... 11 85 11.1. "R" and "C" Flag in Nickname Flags APPsub-TLV..........11 86 12. Security Considerations.................................... 12 87 13. IANA Considerations........................................ 12 88 14. References ................................................ 12 89 14.1. Normative References ..................................12 90 14.2. Informative References ................................12 91 15. Acknowledgments ........................................... 13 93 1. Introduction 95 The IETF TRILL (Transparent Interconnection of Lots of Links) 96 [RFC6325] protocol provides loop free and per hop based multipath 97 data forwarding with minimum configuration. TRILL uses IS-IS 98 [RFC6165] [RFC6326bis] as its control plane routing protocol and 99 defines a TRILL specific header for user data. 101 Classic Ethernet device (CE) devices typically are multi-homed to 102 multiple edge RBridges which form an edge group. All of the uplinks 103 of CE are bundled as a Multi-Chassis Link Aggregation (MC-LAG). 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 scenario, pseudo-nickname solution in 110 [TRILLPN] can be used to avoid MAC flip-flop on remote RBs. The 111 basic idea is to use a virtual RBridge of RBv with a single pseudo- 112 nickname to represent an edge group that MC-LAG connects to. Any 113 member RBridge of that edge group should use this pseudo-nickname 114 rather than its own nickname as ingress nickname when it injects 115 TRILL data frames to TRILL campus. The use of the nickname solves 116 the address flip flop issue by making the MAC address learnt by the 117 remote RBridge bound to pseudo-nickname. However, it introduces 118 another issue, which is incorrect packet drop by RPF check failure. 119 When a pseudo-nickname is used by an edge RBridge as the ingress 120 nickname to forward BUM traffic, any RBridges sitting between the 121 ingress RB and the distribution tree root will treat the traffic as 122 it is ingressed from the virtual RBridge RBv. If same distribution 123 tree is used by these different edge RBridges, the traffic may 124 arrive at RBn from different ports. Then the RPF check fails, and 125 some of the traffic receiving from unexpected ports will be dropped 126 by RBn. 128 This document proposes a centralized replication solution for 129 broadcast, unknown unicast, multicast(BUM) traffic forwarding to 130 solve the issue of incorrect packet drop by RPF check failure. The 131 basic idea is that all ingress RBs send BUM traffic to a centralized 132 node which is recommended to be a distribution tree root using 133 unicast TRILL encapsulation. When the centralized node receives that 134 traffic, it decapsulates it and then forwards the BUM traffic to all 135 destination RBs using a distribution tree established per TRILL base 136 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 143 [RFC2119].The acronyms and terminology in [RFC6325] is used herein 144 with the following additions: 146 BUM - Broadcast, Unknown unicast, and Multicast 148 CE - As in [CMT], Classic Ethernet device (end station or bridge). 150 The device can be either physical or virtual equipment. 152 3. Centralized Replication Solution Overview 154 When an edge RB receives BUM traffic from a CE device, it acts as 155 ingress RB and uses unicast TRILL encapsulation instead of multicast 156 TRILL encapsulation to send the traffic to a centralized node. The 157 centralized node is recommended to be a distribution tree root. 159 The TRILL header of the unicast TRILL encapsulation contains an 160 "ingress RBridge nickname" field and an "egress RBridge nickname" 161 field. If ingress RB receives the traffic from the port which is in 162 a MC-LAG, it should set the ingress RBridge nickname to be the 163 pseudo-nickname rather than its own nickname to avoid MAC flip-flop 164 on remote RBs as per [TRILLPN]. The egress RBridge nickname is set 165 to the special nickname of the centralized node which is used to 166 differentiate the unicast TRILL encapsulation BUM traffic from 167 normal unicast TRILL traffic. The special nickname is called R- 168 nickname. 170 When the centralized node receives the unicast TRILL encapsulated 171 BUM traffic from ingress RB, the node decapsulates the packet. Then 172 the centralized node replicates and forwards the BUM traffic to all 173 destination RBs using one of the distribution trees established per 174 TRILL base protocol, if the centralized node is the root of a 175 distribution tree, the recommended distribution tree is the tree 176 whose root is the centralized node itself. When the centralized node 177 forwards the BUM traffic, ingress nickname remains the same as that 178 in frame it received to ensure that the MAC address learnt by all 179 egress RBridges bound to pseudo-nickname. 181 When the replicated traffic is forwarded on each RBridge along the 182 distribution tree starting from the centralized node, RPF check will 183 be performed as per RFC6325. For any RBridge sitting between the 184 ingress RBridge and the centralized replication node, the traffic 185 incoming port should be the centralized node facing port as the 186 multicast traffic always comes from the centralized node in this 187 solution. However the RPF port as result of distribution tree 188 calculation as per RFC 6325 will be the real ingress RB facing port 189 as it uses virtual RBridge as ingress RB, so RPF check will fail. To 190 solve this problem, some change of RPF calculation algorithm is 191 required. RPF calculation on each RBridge should use the centralized 192 node as ingress RB instead of the real ingress virtual RBridge to 193 perform the calculation. As a result, RPF check will point to the 194 centralized node facing port on the RBridge for multi-destination 195 traffic. It prevents the incorrect frame discard by RPF check. 197 To differentiate the unicast TRILL encapsulation BUM traffic from 198 normal unicast TRILL traffic on a centralized node, besides the 199 centralized node's own nickname, R-nickname should be introduced for 200 centralized replication. Only when the centralized node receives 201 unicast TRILL encapsulation traffic with egress nickname equivalent 202 to the R-nickname, the node does unicast TRILL decapsulaton and then 203 forwards the traffic to all destination RBs through a distribution 204 tree. The centralized nodes should announce its R-nickname to all 205 TRILL campus through TRILL LSP extension. 207 4. Frame duplication from remote RB 209 Frame duplication may occur when a remote host sends multi- 210 destination frame to a local CE which has an active-active 211 connection to the TRILL campus. To avoid local CE receiving multiple 212 copies from a remote RBridge, the designated forwarder (DF) 213 mechanism should be supported for egress direction multicast traffic. 215 DF election mechanism allows only one port in one RB of MC-LAG to 216 forward multicast traffic from TRILL campus to local access side for 217 each VLAN. The basic idea of DF is to elect one RBridge per VLAN 218 from an edge group to be responsible for egressing the multicast 219 traffic. [draft-hao-trill-dup-avoidance-active-active-02] describes 220 the detail DF mechanism and TRILL protocol extension for DF election. 222 If DF-election mechanism is used for frame duplication prevention, 223 access ports on an RB are categorized as three types: non mc-lag, 224 mc-lag DF port and mc-lag non-DF port. The last two types can be 225 called mc-lag port. For each of the mc-lag port, there is a pseudo- 226 nickname associated. If consistent nickname allocation per edge 227 group RBridges is used, it is possible that same pseudo-nickname 228 associated to more than one port on a single RB. A typical scenario 229 is that CE1 is connected to RB1 & RB2 by mc-lag1 while CE2 is 230 connected to RB1 & RB2 by mc-lag 2. In order to conserve the number 231 of pseudo-nickname used, member ports for both mc-lag1 and mc-lag2 232 on RB1 & RB2 are all associated to pseudo-nickname pn1. 234 5. Local forwarding behavior on ingress RBridge 236 When a ingress RBridge(RB1) receives BUM traffic from an active- 237 active accessing CE(CE1) device, the traffic will be injected to 238 TRILL campus through TRILL encapsulation, and it will be replicated 239 and forwarded to all destination RBs which include ingress RB itself 240 along a TRILL distribution tree. So the traffic will return to the 241 ingress RBridge. To avoid the traffic looping back to original 242 sender CE, ingress nickname can be used for traffic filtering. 244 If there are two local connecting CE(CE1 and CE2) devices on ingress 245 RB, the BUM traffic between these two CEs can't be forwarded locally 246 and through TRILL campus simultaneously, otherwise duplicated 247 traffic will be received by destination CE. Local forwarding 248 behavior on ingress RBridge should be carefully designed. 250 To avoid duplicated traffic on receiver CE, local replication 251 behavior on RB1 is as follows: 253 1. Local replication to the ports associated with the same pseudo- 254 nickname as that associated to the incoming port. 256 2. Do not replicate to mc-lag port associated with different pseudo- 257 nickname. 259 3. Do not replicate to non mc-lag ports. 261 The above local forwarding behavior on the ingress RB of RB1 can be 262 called centralized local forwarding behavior A. 264 If ingress RB of RB1 itself is the centralized node, BUM traffic 265 injected to TRILL campus won't loop back to RB1. In this case, the 266 local forwarding behavior is called centralized local forwarding 267 behavior B. The local replication behavior on RB1 is as follows: 269 1. Local replication to the ports associated with the same pseudo- 270 nickname as that associated to the incoming port. 272 2. Local replication to the mc-lag DF port associated with different 273 pseudo-nickname. Do not replicate to mc-lag non-DF port associated 274 with different pseudo-nickname. 276 3. Local replication to non mc-lag ports. 278 6. Loop prevention among RBridges in a edge group 280 If a CE sends a broadcast, unknown unicast, or multicast (BUM) 281 packet through DF port to a ingress RB, it will forward that packet 282 to all or subset of the other RBs that only have non-DF ports for 283 that MC-LAG. Because BUM traffic forwarding to non-DF port isn't 284 allowed, in this case the frame won't loop back to the CE. 286 If a CE sends a BUM packet through non-DF port to a ingress RB, say 287 RB1, then RB1 will forward that packet to other RBridges that have 288 DF port for that MC-LAG. In this case the frame will loop back to 289 the CE and traffic split-horizon filtering mechanism should be used 290 to avoid looping back among RBridges in a edge group. 292 Split-horizon mechanism relies on ingress nickname to check if a 293 packet's egress port belongs to a same MC-LAG with the packet's 294 incoming port to TRILL campus. 296 When the ingress RBridge receives BUM traffic from an active-active 297 accessing CE device, the traffic will be injected to TRILL campus 298 through TRILL encapsulation, and it will be replicated and forwarded 299 to all destination RBs which include ingress RB itself through TRILL 300 distribution tree. If same pseudo-nickname is used for two active- 301 active access CEs as ingress nickname, egress RB can use the 302 nickname to filter traffic forwarding to all local CE. In this case, 303 the traffic between these two CEs goes through local RB and another 304 copy of the traffic from TRILL campus is filtered. If different 305 ingress nickname is used for two connecting CE devices, the access 306 ports connecting to these two CEs should be isolated with each other. 307 The BUM traffic between these two CEs should go through TRILL campus, 308 otherwise the destination CE connected to same RB with the sender CE 309 will receive two copies of the traffic. 311 Do note that the above sections on techniques to avoid frame 312 duplication, loop prevention is applicable assuming the Link 313 aggregation technology in use is unaware of the frame duplication 314 happening. For example using mechanisms like IEEE802.1AX, 315 Distributed Resilient Network Interconnect (DRNI) specs implements 316 mechanism similar to DF and also avoids some cases of frame 317 duplication & looping. 319 7. Centralized replication forwarding process 321 +-----------+ 322 | (RB5) | 323 +-----------+ 324 | 325 +-----------+ 326 | (RB4) | 327 +-----------+ 329 | | | 330 -------- | -------- 331 | | | 332 +------+ +------+ +------+ 333 |(RB1) | |(RB2) | | (RB3)| 334 +------+ +------+ +------+ 335 * | * | * | ^ 336 * | * | * | ^ 337 * ----------*-------------*-- ^ 338 ***************************** | ^ 339 MC-LAG1 * MC-LAG2 | ^ 340 +------+ +------+ +------+ 341 | CE1 | | CE2 | | CE3 | 342 +------+ +------+ +------+ 343 Figure 1 TRILL Active-active access 345 Assuming the centralized replication solution is used in the network 346 of above figure 1, RB5 is the distribution tree root and centralized 347 replication node, CE1 and CE2 are active-active accessed to RB1,RB2 348 and RB3 through MC-LAG1 and MC-LAG2 respectively, CE3 is single 349 homed to RB3. The RBridge's own nickname of RB1 to RB5 are nick1 to 350 nick5 respectively. RB1,RB2 and RB3 use same pseudo-nickname for MC- 351 LAG1 and MC-LAG2, the pseudo-nickname is P-nick. The R-nickname on 352 the centralized replication node of RB5 is S-nick. 354 The BUM traffic forwarding process from CE1 to CE2,CE3 is as follows: 356 1. CE1 sends BUM traffic to RB3. 358 2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 also 359 sends the traffic to RB5 through unicast TRILL encapsulation. 360 Ingress nickname is set as P-nick, egress nickname is set as S- 361 nick. 363 3. RB5 decapsulates the unicast TRILL packet. Then it uses the 364 distribution tree whose root is RB5 to forward the packet. The 365 egress nickname in the trill header is the nick5. Ingress 366 nickname is still P-nick. 368 4. RB4 receives multicast TRILL traffic from RB5. Traffic incoming 369 port is the up port facing to distribution tree root, RPF check 370 will be correct based on the changed RPF port calculation 371 algorithm in this document. After RPF check is performed, it 372 forwards the traffic to all other egress RBs(RB1,RB2 and RB3). 374 5. RB3 receives multicast TRILL traffic from RB4. It decapsulates 375 the multicast TRILL packet. Because ingress nickname of P-nick is 376 equivalent to the nickname of local MC-LAGs connecting CE1 and 377 CE2, it doesn't forward the traffic to CE1 and CE2 to avoid 378 duplicated frame. RB3 only forwards the packet to CE3. 380 6. RB1 and RB2 receive multicast TRILL traffic from RB4. The 381 forwarding process is similar to the process on RB3, i.e, because 382 ingress nickname of P-nick is equivalent to the nickname of local 383 MC-LAGs connecting CE1 and CE2, they also don't forward the 384 traffic to local CE1 and CE2. 386 8. BUM traffic loadbalancing among multiple centralized nodes 388 To support unicast TRILL encapsulation BUM traffic load balancing, 389 multiple centralized replication node can be deployed and the 390 traffic can be load balanced on these nodes in vlan-based. 392 Assuming there are k centralized nodes in TRILL campus, each 393 centralized node has different R-nickname, VLAN-based(or FGL-based) 394 loadbalancing algorithm used by ingress active-active access RBridge 395 is as follows: 397 1. All R-nicknames are ordered and numbered from 0 to k-1 in 398 ascending order. 400 2. For VLAN ID m, choose the R-nickname whose number equals (m 401 mod k) as egress nickname for BUM traffic unicast TRILL 402 encapsulation. 404 For examples, there are 3 centralized nodes (CN) which has one R- 405 nickname respectively, the CN nodes will be ordered based on the 406 ordering algorithm for each R-nickname from CN0 to CN2. Assuming 407 there are 5 VLANs from 1 to 5 spreading among edge RBridges, the 408 traffic in VLAN 1 will go to CN1, VLAN 2 will go to CN2, and so on. 410 When an ingress RBridge participating active-active connection 411 receives BUM traffic from local CE, the RB decides to send the 412 traffic to which centralized node based on the VLAN-based 413 loadbalancing algorithm, vlan-based loadbalancing for the BUM 414 traffic can be achieved among multiple centralized nodes. 416 9. Co-existing with CMT solution 418 +------+ +------+ 419 |(RB6) | |(RB7) | 420 +------+ +------+ 421 ------------------|-----------|---------------------- 422 | | | | | 423 +------+ +------+ +------+ +------+ +------+ 424 |(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) | 425 +------+ +------+ +------+ +------+ +------+ 426 | | | | | 427 ------------ ------------------------- 428 | | 429 +------+ +------+ 430 | CE1 | | CE2 | 431 +------+ +------+ 432 Figure 2 CMT and centralized replication co-existing scenario 434 Both the centralized replication solution and CMT solution rely on 435 pseudo-nickname concept to avoid MAC flip-flop on remote RBridges, 436 these two solutions can co-exist in single TRILL network. Each 437 solution can be selected by each edge group RBridges independently. 438 As illustrated in figure 2, RB1 and RB2 use CMT for CE1's active- 439 active access, RB3,RB4 and RB5 use the centralized replication for 440 CE2's active-active access. 442 For the centralized replication solution, edge group RBridges should 443 announce local pseudo-nickname using Nickname Flags APPsub-TLV with 444 C-flag, the nickname with C-flag is called "C-nickname". A transit 445 RBridge will perform the centralized replication specific RPF check 446 algorithm if it receives TRILL encapsulation traffic with C-nickname 447 as ingress nickname. 449 10. Network Migration Analysis 451 Centralized nodes need software and hardware upgrade to support 452 centralized replication process, which stitches TRILL unicast 453 traffic decapsulation process and the process of normal TRILL 454 multicast traffic forwarding along distribution tree. 456 Active-active connection edge RBs need software and hardware upgrade 457 to support unicast TRILL encapsulation for BUM traffic, the process 458 is similar to normal head-end replication process. 460 Transit nodes need software upgrade to support RPF port calculation 461 algorithm change. 463 11. TRILL protocol extension 465 Two Flags of "R" and "C" in Nickname Flags APPsub-TLV [RFC7180bis] 466 are introduced, the nickname with "R" flag is called R-nickname, the 467 nickname with "C" flag is called C-nickname. R-nickname is a 468 specialized nickname attached on a centralized node to differentiate 469 unicast TRILL encapsulation BUM traffic from normal unicast TRILL 470 traffic. C-nickname is set on each edge group RBridge, C-nickname is 471 a specialized pseudo-nickname for transit RBridges to perform 472 different RPF check algorithm. 474 When active-active edge RBridges use centralized replication to 475 forward BUM traffic, the R-nickname is used as the egress nickname 476 and the C-nickname is used as ingress nickname in TRILL header for 477 unicast TRILL encapsulation of BUM traffic. 479 11.1. "R" and "C" Flag in Nickname Flags APPsub-TLV 481 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 482 | Nickname | 483 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 484 |IN|SE|R | C| RESV | 485 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 486 NICKFLAG RECORD 488 o R. If R flag is one, it indicates that the advertising TRILL 489 switch is a centralized replication node, and the nickname is used 490 as egress nickname for edge group RBridges to inject traffic to 491 TRILL campus when the edge group RBridges use centralized 492 replication solution for active-active access. If flag is zero, that 493 nickname will not be used for that purpose. 495 o C. If C flag is one, it indicates that the TRILL traffic 496 with this nickname as ingress nickname requires special RPF check 497 algorithm. If flag is zero, that nickname will not be used for that 498 purpose. 500 12. Security Considerations 502 This draft does not introduce any extra security risks. For general 503 TRILL Security Considerations, see [RFC6325]. 505 13. IANA Considerations 507 This document requires no IANA Actions. RFC Editor: Please remove 508 this section before publication. 510 14. References 512 14.1. Normative References 514 [1] [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 515 Layer-2 Systems", RFC 6165, April 2011. 517 [2] [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol 518 Specification", RFC 6325, July 2011. 520 [3] [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., 521 and A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis- 522 rfc6326bis, work in progress. 524 [4] [RFC7180bis] Eastlake, D., Zhang, M., Perlman, R., Banerjee, A. 525 Ghanwani and Gupta.S, "TRILL: Clarifications, Corrections, and 526 Updates", draft-ietf-trill-rfc7180bis-00, work in progress. 528 14.2. Informative References 530 [1] [TRILLPN] Zhai,H., et.al., "RBridge: Pseduonode nickname", 531 draft-hu-trill-pseudonode-nickname, Work in progress, November 532 2011. 534 [2] [TRILAA] Li,Y., et.al., " Problem Statement and Goals for 535 Active-Active TRILL Edge", draft-ietf-trill-active-active- 536 connection-prob-00, Work in progress, July 2013. 538 [3] [CMT] Senevirathne, T., Pathangi, J., and J. Hudson, 539 "Coordinated Multicast Trees (CMT)for TRILL", draft-ietf- 540 trill-cmt-00.txt Work in Progress, April 2012. 542 15. Acknowledgments 544 The authors wish to acknowledge the important contributions of 545 Hongjun Zhai, Xiaomin Wu, Liang Xia. 547 Authors' Addresses 549 Weiguo Hao 550 Huawei Technologies 551 101 Software Avenue, 552 Nanjing 210012 553 China 554 Email: haoweiguo@huawei.com 556 Yizhou Li 557 Huawei Technologies 558 101 Software Avenue, 559 Nanjing 210012 560 China 561 Email: liyizhou@huawei.com 563 Muhammad Durrani 564 Cisco 565 Email: mdurrani@cisco.com 567 Sujay Gupta 568 IP Infusion 569 RMZ Centennial 570 Mahadevapura Post 571 Bangalore - 560048 572 India 573 Email: sujay.gupta@ipinfusion.com 575 Andrew Qu 576 MediaTec 577 Email: laodulaodu@gmail.com 579 Tao Han 580 Huawei Technologies 581 101 Software Avenue, 582 Nanjing 210012 583 China 584 Email: billow.han@huawei.com