idnits 2.17.1 draft-ietf-trill-smart-endnodes-06.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 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. RFC 2119 keyword, line 244: '...h types of Smart-Hellos MUST include a...' RFC 2119 keyword, line 266: '... MUST send a Smart-Hello at least...' RFC 2119 keyword, line 271: '...he Flags are reserved and MUST be send...' RFC 2119 keyword, line 297: '...utentication TLV MAY also be included....' RFC 2119 keyword, line 303: '...ub-TLV and there MAY be an Authenticat...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2017) is 2449 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) == Unused Reference: 'RFC7178' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC7783' is defined on line 595, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL WG Radia. Perlman 3 Internet-Draft EMC Corporation 4 Intended status: Standards Track Fangwei. Hu 5 Expires: February 3, 2018 ZTE Corporation 6 Donald. Eastlake 3rd 7 Huawei technology 8 Kesava. Krupakaran 9 Dell 10 Ting. Liao 11 August 2, 2017 13 TRILL Smart Endnodes 14 draft-ietf-trill-smart-endnodes-06.txt 16 Abstract 18 This draft addresses the problem of the size and freshness of the 19 endnode learning table in edge RBridges, by allowing endnodes to 20 volunteer for endnode learning and encapsulation/decapsulation. Such 21 an endnode is known as a "Smart Endnode". Only the attached edge 22 RBridge can distinguish a "Smart Endnode" from a "normal endnode". 23 The smart endnode uses the nickname of the attached edge RBridge, so 24 this solution does not consume extra nicknames. The solution also 25 enables Fine Grained Label aware endnodes. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 5 65 4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 5 66 4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 6 67 4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 7 68 5. Data Packet Processing . . . . . . . . . . . . . . . . . . . 8 69 5.1. Data Packet Processing for Smart Endnode . . . . . . . . 8 70 5.2. Data Packet Processing for Edge RBridge . . . . . . . . . 9 71 6. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 10.1. Informative References . . . . . . . . . . . . . . . . . 12 77 10.2. Normative References . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The IETF TRILL (Transparent Interconnection of Lots of Links) 83 protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame 84 forwarding without configuration, safe forwarding even during periods 85 of temporary loops, and support for multipathing of both unicast and 86 multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] 87 [RFC7176] link state routing and encapsulating traffic using a header 88 that includes a hop count. Devices that implement TRILL are called 89 "RBridges" (Routing Bridges) or "TRILL Switches". 91 An RBridge that attaches to endnodes is called an "edge RBridge" or 92 "edge TRILL Switch", whereas one that exclusively forwards 93 encapsulated frames is known as a "transit RBridge" or "transit TRILL 94 Switch". An edge RBridge traditionally is the one that encapsulates 95 a native Ethernet frame with a TRILL header, or that receives a 96 TRILL-encapsulated packet and decapsulates the TRILL header. To 97 encapsulate efficiently, the edge RBridge must keep an "endnode 98 table" consisting of (MAC, Data Label, TRILL egress switch nickname) 99 sets, for those remote MAC addresses in Data Labels currently 100 communicating with endnodes to which the edge RBridge is attached. 102 These table entries might be configured, received from ESADI 103 [RFC7357], looked up in a directory [RFC7067], or learned from 104 decapsulating received traffic. If the edge RBridge has attached 105 endnodes communicating with many remote endnodes, this table could 106 become very large. Also, if one of the MAC addresses and Data Labels 107 in the table has moved to a different remote TRILL switch, it might 108 be difficult for the edge RBridge to notice this quickly, and because 109 the edge RBridge is encapsulting to the incorrect egress RBridge, the 110 traffic will get lost. 112 2. Solution Overview 114 The Smart Endnode solution proposed in this document addresses the 115 problem of the size and freshness of the endnode learning table in 116 edge RBridges. An endnode E, attached to an edge RBridge R, tells R 117 that E would like to be a "Smart Endnode", which means that E will 118 encapsulate and decapsulate the TRILL frame, using R's nickname. 119 Because E uses R's nickname, this solution does not consume extra 120 nicknames. 122 Take the below figure as the example Smart Endnode scenario: RB1, RB2 123 and RB3 are the RBridges in the TRILL domain, and smart SE1 and SE2 124 are the smart ennodes which can encapsulate and decapsulate the TRILL 125 packets. RB1 is the edge RB and it is been attached by SE1 and SE2. 126 RB1 assigns its nickname to SE1 and SE2. 128 Each Smart Endnode, SE1 and SE2, uses RB1's nickname when 129 encapsulating, and maintains an endnode table of (MAC, label, TRILL 130 egress switch nickname) for remote endnodes that it (SE1 or SE2) is 131 corresponding with. RB1 does not decapsulate packets destined for 132 SE1 or SE2, and does not learn (MAC, label, TRILL egress switch 133 nickname) for endnodes corresponding with SE1 or SE2, but RB1 does 134 decapsulate, and does learn (MAC, label, TRILL egress switch 135 nickname) for any endnodes attached to RB1 that have not declared 136 themselves to be Smart Endnodes. 138 Just as an RBridge learns and times out (MAC, label, TRILL egress 139 switch nickname), Smart Endnodes SE1 and SE2 also learn and time out 140 endnode entries. However, SE1 and SE2 might also determine, through 141 ICMP messages or other techniques that an endnode entry is not 142 successfully reaching the destination endnode, and can be deleted, 143 even if the entry has not timed out. 145 If SE1 wishes to correspond with destination MAC D, and no endnode 146 entry exists, SE1 will encapsulate the packet as an unknown 147 destination, or consulting a directory [RFC7067] (just as an RBridge 148 would do if there was no endnode entry). 150 +----------+ 151 |SE1(Smart | 152 |Endnode1) | \ +------------------------------+ 153 +----------+ \ / \ 154 \ /+------+ +------+ +-----+ \ +----------+ 155 /-+-| RB 1 |---| RB2 |----| RB3 |-----+--| Endnode1 | 156 / | +------+ +------+ +-----+ | +----------+ 157 +----------+ / \ / 158 |SE2(Smart | \ / 159 | Endnode2)| +------------------------------+ 160 +----------+ 161 Figure 1 Smart Endnode Scenario 163 The mechanism in this draft is that the Smart Endnode SE1 issues a 164 Smart-Hello, indicating SE1's desire to act as a Smart Endnode, 165 together with the set of MAC addresses and Data Labels that SE1 owns. 166 The Smart-Hello is used to announce the Smart Endnode capbillity and 167 parameters (such as MAC address, Data Label etc.). The Smart-Hello 168 is a type of TRILL ES-IS ,which is specified in section 5 of 169 [RFC8171].The detailed content for a smart endnode's Smart-Hello is 170 defined in section 4. 172 If RB1 supports having a Smart Endnode neighbor it also sends Smart- 173 Hellos. The smart endnode learns from RB1's Smart-Hellos what RB1's 174 nickname is and which trees RB1 can use when RB1 ingresses multi- 175 destination frames. Although Smart Endnode SE1 transmits Smart- 176 Hellos, it does not transmit or receive LSPs or E-L1FS FS-LSPs 177 [RFC7780]. 179 Since a Smart Endnode can encapsulate TRILL Data packets, it can 180 cause the Inner.Lable to be a Fine Grained Label [RFC7172], thus this 181 method supports FGL aware endnodes.When and how a smart endnode 182 decides to use the FGL instead of VLANs to encapsulate the TRILL Data 183 packet is out of scope in this document. 185 3. Terminology 187 Edge RBridge: An RBridge providing endnode service on at least one of 188 its ports. It is also called an edge TRILL Switch. 190 Data Label: VLAN or FGL. 192 DRB: Designated RBridge [RFC6325]. 194 ESADI: End Station Address Distribution Information [RFC7357]. 196 FGL: Fine Grained Label [RFC7172]. 198 IS-IS: Intermediate System to Intermediate System [IS-IS]. 200 RBridge: Routing Bridge, an alternative name for a TRILL switch. 202 Smart Endnode: An endnode that has the capability specified in this 203 document including learning and maintaining (MAC, Data Label, 204 Nickname) entries and encapsulating/decapsulating TRILL frame. 206 Transit RBridge: An RBridge exclusively forwards encapsulated frames. 207 It is also named as transit RBridge. 209 TRILL: Transparent Interconnection of Lots of Links 210 [RFC6325][RFC7780]. 212 TRILL ES-IS: TRILL End System to Intermediate System, is a variation 213 of TRILL IS-IS designed to operate on a TRILL link among and between 214 one or more TRILL switches and end stations on that link[RFC8171]. 216 TRILL Switch: a device that implements the TRILL protocol; an 217 alternative term for an RBridge. 219 4. Smart-Hello Mechanism between Smart Endnode and RBridge 221 The subsections below describe Smart-Hello messages. 223 4.1. Smart-Hello Encapsulation 225 Although a Smart Endnode is not an RBridge, does not send LSPs or 226 maintain a copy of the link state database, and does not perform 227 routing calculations, it is required to have a "Hello" mechanism (1) 228 to announce to edge RBridges that it is a Smart Endnode and (2) to 229 tell them what MAC addresses it is handling in what Data Labels. 230 Similarly, an edge RBridge that supports Smart Endnodes needs a 231 message (1) to announce that support, (2) to inform Smart Endnodes 232 what nickname to use for ingress and what nickname(s) can be used as 233 egress nickname in a multi-destination TRILL Data packet, and (3) the 234 list of smart end nodes it knows about on that link. 236 The messages sent by Smart Endnodes and by edge RBridges that support 237 Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type 238 of TRILL ES-IS, which is specified in [RFC8171]. 240 The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes 241 and for Smart-Hellos sent by Edge RBridges, consists of TRILL IS-IS 242 TLVs as described in the following two sub-sections. The non- 243 extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 244 8-bit size and type field. Both types of Smart-Hellos MUST include a 245 Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV: 247 +-+-+-+-+-+-+-+-+- 248 |Smart-Parameters| (1 byte) 249 +-+-+-+-+-+-+-+-+- 250 | Length | (1 byte) 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Holding Time | (2 bytes) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Flags | (2 bytes) 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2 Smart Parameters APPsub-TLV 259 Type: APPsub-TLV type Smart-Parameters, value is TBD1. 261 Length: 4. 263 Holding Time: A time in seconds as an unsigned integer. It has 264 the same meaning as the Holding Time field in IS-IS Hellos [IS-IS] 265 . A Smart Endnode and an Edge RBridge supporting Smart Endndoes 266 MUST send a Smart-Hello at least three times during their Holding 267 Time. If no Smart-Hellos is received from a Smart Endnode or Edge 268 RBridge within the most recent Holding Time it sent, it is assumed 269 that it is no longer available. 271 Flags: At this time all of the Flags are reserved and MUST be send 272 as zero and ignored on receipt. 274 If more than one Smart Parameters APPsub-TLV appears in a Smart- 275 Hello, the first one is used and any following ones are ignored. If 276 no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart- 277 Hello is ignored. 279 4.2. Edge RBridge's Smart-Hello 281 The edge RBridge's Smart-Hello contains the following information in 282 addition to the Smart-Parameters APPsub-TLV: 284 o RBridge's nickname. The nickname sub-TLV, specified in section 285 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS 286 router capability) in a Smart-Hello frame. If more than one 287 nickname appears in the Smart-Hello, the first one is used and the 288 following ones are ignored. 290 o Trees that RB1 can use when ingressing multi-destination frames. 291 The Tree Identifiers Sub-TLV, specified in section 2.3.4 in 292 [RFC7176], is reused here. 294 o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in 295 section 2.5 in [RFC7176], is reused for this purpose. 297 o An Autentication TLV MAY also be included. 299 4.3. Smart Endnode's Smart-Hello 301 A new APPsub-TLV (Smart-MAC TLV) is defined for use by Smart Endnodes 302 as defined below. In addition, there will be a Smart-Parameters 303 APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode 304 Smart-Hello. 306 If there are several VLANs/FGL Data Labels for that Smart Endnode, 307 the Smart-MAC APPsub-TLV is included several times in Smart Endnode's 308 Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV. 310 +-+-+-+-+-+-+-+-+ 311 |Type=Smart-MAC | (1 byte) 312 +-+-+-+-+-+-+-+-+ 313 | Length | (1 byte) 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | F |RSV | VLAN/FGL Data Label | (2 bytes or 4 bytes) 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | MAC (1) (6 bytes) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | ................. | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | MAC (N) (6 bytes) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 3 Smart-MAC APPsub-TLV 326 o Type: TRILL APPsub-TLV Type Smart-MAC, value is TBD2. 328 o Length: Total number of bytes contained in the value field. 330 o F: one bit. If it sets to 1, which indicates that the endnode 331 supports FGL data label, otherwise, the VLAN/FGL Data Labels 332 [RFC7172] and that this Smart-MAC APPsub-TLV has an FGL in the 333 following VLAN/FGL field. Otherwise, the VLAN/FGL Data Label 334 field is a VLAN ID. 336 o RSV: 2 bits or 6 bits, is reserved for the future use. If VLAN/ 337 FGL Data Label indicates the VLAN ID(F flag sets to 0), the RESV 338 field is 2 bits long. Otherwise it is 6 bits. 340 o VLAN/FGL Data Label: This carries a 12-bits VLAN identifier or 341 24-bits FGL Data Label that is valid for all subsequent MAC 342 addresses in this APPsub-TLV, or the value zero if no VLAN/FGL 343 data label is specified. 345 o MAC(i): This is a 48-bit MAC address reachable in the Data Label 346 given from the Smart Endnode that is announcing this APPsub-TLV. 348 5. Data Packet Processing 350 The subsections below specify Smart Endnode data packet processing. 351 All TRILL Data packets sent to or from Smart Endnodes are sent in the 352 Designated VLAN [RFC6325] of the local link but do not necessarily 353 have to be VLAN tagged. 355 5.1. Data Packet Processing for Smart Endnode 357 A Smart Endnode does not issue or receive LSPs or E-L1FS FS-LSPs or 358 calculate topology. It does the following: 360 o Smart Endnode maintains an endnode table of (the MAC address of 361 remote endnode, Data Label, the nickname of the edge RBridge's 362 attached) entries of end nodes with which the Smart Endnode is 363 communicating. Entries in this table are populated the same way 364 that an edge RBridge populates the entries in its table: 366 * learning from (source MAC address ingress nickname) on packets 367 it decapsulates. 369 * by querying a directory [RFC7067]. 371 * by having some entries configured. 373 o When Smart Endnode SE1 wishes to send unicast frame to remote node 374 D, if (MAC address of remote endnode D, Data Label, nickname) 375 entry is in SE1's endnode table, SE1 encapsulates the ingress 376 nickname as the nicknamae of the RBridge(RB1), egress nickname as 377 indicated in D's table entry. If D is unknown, SE1 either queries 378 a directory or encapsulates the packet as a multi-destination 379 frame, using one of the trees that RB1 has specified in RB1's 380 Smart-Hello. The mechanism for querying a directory is given in 381 [RFC8171]. 383 o When SE1 wishes to send a a multi-destination (multicast, unknown 384 unicast, or broadcast) to the TRILL campus, SE1 encapsulates the 385 packet using one of the trees that RB1 has specified. 387 If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, 388 the destination MAC of the outer Ethernet is All-RBridges multicast 389 address. 391 The Smart Endnode SE1 need not send Smart-Hellos as frequently as 392 normal RBridges. These Smart-Hellos could be periodically unicast to 393 the Appointed Forwarder RB1 through native RBridge Channel messages. 394 In case RB1 crashes and restarts, or the DRB changes and SE1 receives 395 the Smart-Hello without mentioning SE1, SE1 SHOULD send a Smart-Hello 396 immediately. If RB1 is Appointed Forwarder for any of the VLANs that 397 SE1 claims, RB1 MUST list SE1 in its Smart-Hellos as a Smart Endnode 398 neighbor. 400 5.2. Data Packet Processing for Edge RBridge 402 The attached edge RBridge processes and forwards TRILL Data packets 403 based on the endnode property rather than for encapsulation and 404 forwarding the native frames the same way as the traditional 405 RBridges. There are several situations for the edge RBridges as 406 follows: 408 o If receiving an encapsulated unicast TRILL Data packet from a port 409 with a Smart Endnode, with RB1's nickname as ingress, the edge 410 RBridge RB1 forwards the frame to the specified egress nickname, 411 as with any encapsulated frame. However, RB1 MAY filter the 412 encapsulation frame based on the inner source MAC and Data Label 413 as specified for the Smart Endnode. If the MAC (or Data Label) 414 are not among the expected entries of the Smart Endnode, the frame 415 would be dropped by the edge RBridge. 417 o If receiving a unicast TRILL Data packet with RB1's nickname as 418 egress from the TRILL campus, and the destination MAC address in 419 the enclosed packet is listed as "smart endnode", RB1 leaves the 420 packet encapsulated when forwarding to the smart endnode, and both 421 the outer and inner Ethernet destination MAC is the destination 422 smart endnod's MAC address, and the outer Ethernet source MAC 423 address is the RB1's port MAC address. The edge RBridge still 424 decreases the Hop count value by 1, for there is one hop between 425 the RB1 and Smart Endnode. 427 o If receiving an multi-destination TRILL Data packet from a port 428 with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation 429 to the TRILL campus based on the distribution tree indicated by 430 the egress nickname. If the egress nickname does not correspond 431 to a distribution tree, the packet is discarded. If there are any 432 normal endnodes (i.e, non-Smart Endnodes) attached to the edge 433 RBridge RB1, RB1 decapsulates the frame and sends the native frame 434 to these ports possibly pruned based on multicast listeners, in 435 addition to forwarding the multi-destination TRILL frame to the 436 rest of the campus. 438 o If RB1 receives a native multi-destination data frame, which is 439 sent by a non-smart endnode, from a port, including hybrid 440 endnodes (smart endnodes and non-smart endnodes), RB1 will 441 encapsulate it as multi-destination TRILL Data packet , and send 442 the encapsulated multi-destination TRILL Data Packet out that same 443 port to the smart endnodes attached to the port, and also send the 444 encapsulated multi-destination TRILL Data Packet to the TRILL 445 campus through other ports . 447 o If RB1 receives a multi-destination TRILL Data packet from a 448 remote RBridge, and the exit port includes hybrid endnodes(Smart 449 Endnodes and non-Smart Endnodes), it sends two copies of multicast 450 frames out the port, one as native and the other as TRILL 451 encapsulated frame. When Smart Endnode receives multi-destination 452 TRILL Data packet, it learns the remote (MAC address, Data Label, 453 Nickname) entry, A Smart Endnodes ignores native data frames. A 454 normal (non-smart) endnode receives the native frame and learns 455 the remote MAC address and ignores the TRILL data packet. This 456 transit solution may bring some complexity for the edge RBridge 457 and waste network bandwidth resource, so avoiding the hybrid 458 endnodes scenario by attaching the Smart Endnodes and non-Smart 459 Endnodes to different ports is RECOMMENDED. 461 6. Multi-homing Scenario 463 Multi-homing is a common scenario for the Smart Endnode. The Smart 464 Endnode is on a link attached to the TRILL domain in two places: to 465 edge RBridge RB1 and RB2. Take the figure below as example. The 466 Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 467 separately. Both RB1 and RB2 could announce their nicknames to SE1. 469 . ..................... 470 . +------+ . 471 . | RB1 | . 472 . /+------+ . 473 +----------+ ./ +-----+ . +----------+ 474 |SE1(Smart |/. | RB3 |......| Smart | 475 | Endnode1)| .\ +-----+ . | Endnode2 | 476 +----------+ . \ . +----------+ 477 . +-----+ . 478 . | RB2 | TRILL . 479 . +-----+ Domain . 480 ....................... 482 Figure 4 Multi-homing Scenario 484 Smart Endnode SE1 can choose either RB1 or RB2's nickname, when 485 encapsulating and forwarding a TRILL data packet. If the active- 486 active load balance is considered for the multi-homing scenario, the 487 Smart Endnode SE1 could use both RB1 and RB2's nickname to 488 encapsulate and forward TRILL Data packet. SE1 uses RB1's nickname 489 when forwarding through RB1, and RB2's nickname when forwarding 490 through RB2. this will cause MAC flip-flopping(see [RFC7379]) of the 491 endnode table entry in the remote RBridges (or Smart Endnodes). The 492 solution for the MAC flip-flopping issue is to set a multi- homing 493 bit in the RSV field of the TRILL data packet. When remote RBridge 494 RB3 or Smart Endnodes receives a data packet with the multi-homed bit 495 set, the endnode entries (SE1's MAC address, label, RB1's nickname) 496 and (SE1's MAC address, label, RB2's nickname) will coexist as 497 endnode entries in the remote RBridge. Another solution is to use 498 the ESADI protocol to distribute multiple attachments of a MAC 499 address of a multi-homing group,The ESADI is deployed among the edge 500 RBridges (See section 5.3 of [RFC7357]). 502 7. Security Considerations 504 Smart-Hellos can be secured by using Authentication TLVs based on 505 [RFC5310]. 507 For general TRILL Security Considerations, see [RFC6325]. 509 For TRILL ES-IS Security Considerations, see [RFC8171]. 511 8. IANA Considerations 513 IANA is requested to allocate APPsub-TLV type numbers for the Smart- 514 MAC and Smart-Parameters APPsub-TLVs from the range below 256 and 515 update the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 516 Identifier 1" registry as follows. 518 +-----------+-------------------+------------------+ 519 | Protocol | Description | Reference | 520 +-----------+-------------------+------------------+ 521 | TBD1 | Smart-Parameters | [this document] | 522 | TBD2 | Smart-MAC | [this document] | 523 +-----------+-------------------+------------------+ 525 Table 1 527 9. Acknowledgements 529 The contributions of the following persons are gratefully 530 acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, and Andrew Qu. 532 10. References 534 10.1. Informative References 536 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 537 Gashinsky, "Directory Assistance Problem and High-Level 538 Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 539 2013, . 541 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 542 "Problem Statement and Goals for Active-Active Connection 543 at the Transparent Interconnection of Lots of Links 544 (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 545 2014, . 547 10.2. Normative References 549 [IS-IS] ISO/IEC 10589:2002, Second Edition,, "Intermediate System 550 to Intermediate System Intra-Domain Routing Exchange 551 Protocol for use in Conjunction with the Protocol for 552 Providing the Connectionless-mode Network Service (ISO 553 8473)", 2002. 555 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 556 and M. Fanto, "IS-IS Generic Cryptographic 557 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 558 2009, . 560 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 561 Ghanwani, "Routing Bridges (RBridges): Base Protocol 562 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 563 . 565 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 566 D. Dutt, "Transparent Interconnection of Lots of Links 567 (TRILL): Fine-Grained Labeling", RFC 7172, 568 DOI 10.17487/RFC7172, May 2014, 569 . 571 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 572 D., and A. Banerjee, "Transparent Interconnection of Lots 573 of Links (TRILL) Use of IS-IS", RFC 7176, 574 DOI 10.17487/RFC7176, May 2014, 575 . 577 [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 578 Ward, "Transparent Interconnection of Lots of Links 579 (TRILL): RBridge Channel Support", RFC 7178, 580 DOI 10.17487/RFC7178, May 2014, 581 . 583 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 584 Stokes, "Transparent Interconnection of Lots of Links 585 (TRILL): End Station Address Distribution Information 586 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 587 September 2014, . 589 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 590 Ghanwani, A., and S. Gupta, "Transparent Interconnection 591 of Lots of Links (TRILL): Clarifications, Corrections, and 592 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 593 . 595 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, 596 "Coordinated Multicast Trees (CMT) for Transparent 597 Interconnection of Lots of Links (TRILL)", RFC 7783, 598 DOI 10.17487/RFC7783, February 2016, 599 . 601 [RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, 602 "Transparent Interconnection of Lots of Links (TRILL): 603 Edge Directory Assistance Mechanisms", RFC 8171, 604 DOI 10.17487/RFC8171, June 2017, 605 . 607 Authors' Addresses 609 Radia Perlman 610 EMC Corporation 611 2010 156th Ave NE, suite #200 612 Bellevue, WA 98007 613 USA 615 Phone: +1-206-291-367 616 Email: radiaperlman@gmail.com 618 Fangwei Hu 619 ZTE Corporation 620 No.889 Bibo Rd 621 Shanghai 201203 622 China 624 Phone: +86 21 68896273 625 Email: hu.fangwei@zte.com.cn 627 Donald Eastlake,3rd 628 Huawei technology 629 155 Beaver Street 630 Milford, MA 01757 631 USA 633 Phone: +1-508-634-2066 634 Email: d3e3e3@gmail.com 636 Kesava Vijaya Krupakaran 637 Dell 638 Olympia Technology Park 639 Guindy Chennai 600 032 640 India 642 Phone: +91 44 4220 8496 643 Email: Kesava_Vijaya_Krupak@Dell.com 645 Ting Liao 646 Nanjing, Jiangsu 210012 647 China 649 Email: liaoting82@163.com