idnits 2.17.1 draft-ietf-trill-smart-endnodes-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 27, 2018) is 2250 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL WG Radia Perlman 3 Internet-Draft Dell EMC 4 Intended status: Standards Track Fangwei Hu 5 Expires: August 31, 2018 ZTE Corporation 6 Donald Eastlake 7 Ting Liao 8 Huawei Technologies 9 Feb 27, 2018 11 TRILL Smart Endnodes 12 draft-ietf-trill-smart-endnodes-09.txt 14 Abstract 16 This draft addresses the problem of the size and freshness of the 17 endnode learning table in edge RBridges, by allowing endnodes to 18 volunteer for endnode learning and encapsulation/decapsulation. Such 19 an endnode is known as a "Smart Endnode". Only the attached edge 20 RBridge can distinguish a "Smart Endnode" from a "normal endnode". 21 The smart endnode uses the nickname of the attached edge RBridge, so 22 this solution does not consume extra nicknames. The solution also 23 enables Fine Grained Label aware endnodes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 31, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 7 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. Conventions used in this document 114 2.1. Terminology 116 Edge RBridge: An RBridge providing endnode service on at least one of 117 its ports. It is also called an edge TRILL Switch. 119 Data Label: VLAN or FGL. 121 DRB: Designated RBridge [RFC6325]. 123 ESADI: End Station Address Distribution Information [RFC7357]. 125 FGL: Fine Grained Label [RFC7172]. 127 IS-IS: Intermediate System to Intermediate System [IS-IS]. 129 RBridge: Routing Bridge, an alternative name for a TRILL switch. 131 Smart Endnode: An endnode that has the capability specified in this 132 document including learning and maintaining (MAC, Data Label, 133 Nickname) entries and encapsulating/decapsulating TRILL frame. 135 Transit RBridge: An RBridge exclusively forwards encapsulated frames. 136 It is also named as transit RBridge. 138 TRILL: Transparent Interconnection of Lots of Links 139 [RFC6325][RFC7780]. 141 TRILL ES-IS: TRILL End System to Intermediate System, is a variation 142 of TRILL IS-IS designed to operate on a TRILL link among and between 143 one or more TRILL switches and end stations on that link[RFC8171]. 145 TRILL Switch: a device that implements the TRILL protocol; an 146 alternative term for an RBridge. 148 2.2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Solution Overview 158 The Smart Endnode solution defined in this document addresses the 159 problem of the size and freshness of the endnode learning table in 160 edge RBridges. An endnode E, attached to an edge RBridge R, tells R 161 that E would like to be a "Smart Endnode", which means that E will 162 encapsulate and decapsulate the TRILL frame, using R's nickname. 163 Because E uses R's nickname, this solution does not consume extra 164 nicknames. 166 Take the figure 1 as the example Smart Endnode scenario: RB1, RB2 and 167 RB3 are the RBridges in the TRILL domain, and SE1 and SE2 are the 168 smart endnodes which can encapsulate and decapsulate the TRILL 169 packets. RB1 is the edge RB and it is been attached by SE1 and SE2. 170 RB1 assigns its nickname being used to SE1 and SE2. 172 Each Smart Endnode, SE1 and SE2, uses RB1's nickname when 173 encapsulating, and maintains an endnode table of (MAC, label, TRILL 174 egress switch nickname) for remote endnodes that it (SE1 or SE2) is 175 corresponding with. RB1 does not decapsulate packets destined for 176 SE1 or SE2, and does not learn (MAC, label, TRILL egress switch 177 nickname) for endnodes corresponding with SE1 or SE2, but RB1 does 178 decapsulate, and does learn (MAC, label, TRILL egress switch 179 nickname) for any endnodes attached to RB1 that have not declared 180 themselves to be Smart Endnodes. 182 Just as an RBridge learns and times out (MAC, label, TRILL egress 183 switch nickname), Smart Endnodes SE1 and SE2 also learn and time out 184 endnode entries. However, SE1 and SE2 might also determine, through 185 ICMP messages or other techniques that an endnode entry is not 186 successfully reaching the destination endnode, and can be deleted, 187 even if the entry has not timed out. 189 If SE1 wishes to correspond with destination MAC D, and no endnode 190 entry exists, SE1 will encapsulate the packet as an unknown 191 destination, or consulting a directory [RFC7067] (just as an RBridge 192 would do if there was no endnode entry). 194 +----------+ 195 |SE1(Smart | 196 |Endnode1) | \ +------------------------------+ 197 +----------+ \ / \ 198 \ /+------+ +------+ +-----+ \ +----------+ 199 /-+-| RB 1 |---| RB2 |----| RB3 |-----+--| Endnode1 | 200 / | +------+ +------+ +-----+ | +----------+ 201 +----------+ / \ / 202 |SE2(Smart | \ / 203 | Endnode2)| +------------------------------+ 204 +----------+ 205 Figure 1 Smart Endnode Scenario 207 The mechanism in this draft is that the Smart Endnode SE1 issues a 208 Smart-Hello, indicating SE1's desire to act as a Smart Endnode, 209 together with the set of MAC addresses and Data Labels that SE1 owns. 210 The Smart-Hello is used to announce the Smart Endnode capability and 211 parameters (such as MAC address, Data Label etc.). The Smart-Hello 212 is a type of TRILL ES-IS ,which is specified in section 5 of 213 [RFC8171]. The detailed content for a smart endnode's Smart-Hello is 214 defined in section 4. 216 If RB1 supports having a Smart Endnode neighbor it also sends Smart- 217 Hellos. The smart endnode learns from RB1's Smart-Hellos what RB1's 218 nickname is and which trees RB1 can use when RB1 ingresses multi- 219 destination frames. Although Smart Endnode SE1 transmits Smart- 220 Hellos, it does not transmit or receive LSPs or E-L1FS FS-LSPs 221 [RFC7780]. 223 Since a Smart Endnode can encapsulate TRILL Data packets, it can 224 cause the Inner.Lable to be a Fine Grained Label [RFC7172], thus this 225 method supports FGL aware endnodes. When and how a smart endnode 226 decides to use the FGL instead of VLANs to encapsulate the TRILL Data 227 packet is out of scope in this document. 229 4. Smart-Hello Mechanism between Smart Endnode and RBridge 231 The subsections below describe Smart-Hello messages. 233 4.1. Smart-Hello Encapsulation 235 Although a Smart Endnode is not an RBridge, does not send LSPs or 236 maintain a copy of the link state database, and does not perform 237 routing calculations, it is required to have a "Hello" mechanism (1) 238 to announce to edge RBridges that it is a Smart Endnode and (2) to 239 tell them what MAC addresses it is handling in what Data Labels. 240 Similarly, an edge RBridge that supports Smart Endnodes needs a 241 message (1) to announce that support, (2) to inform Smart Endnodes 242 what nickname to use for ingress and what nickname(s) can be used as 243 egress nickname in a multi-destination TRILL Data packet, and (3) the 244 list of smart end nodes it knows about on that link. 246 The messages sent by Smart Endnodes and by edge RBridges that support 247 Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type 248 of TRILL ES-IS, which is specified in [RFC8171]. 250 The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes 251 and for Smart-Hellos sent by Edge RBridges, consists of TRILL IS-IS 252 TLVs as described in the following two sub-sections. The non- 253 extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 254 8-bit size and type field. Both types of Smart-Hellos MUST include a 255 Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV: 257 +-+-+-+-+-+-+-+-+- 258 |Smart-Parameters| (1 byte) 259 +-+-+-+-+-+-+-+-+- 260 | Length | (1 byte) 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Holding Time | (2 bytes) 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Flags | (2 bytes) 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2 Smart Parameters APPsub-TLV 269 Type: APPsub-TLV type Smart-Parameters, value is TBD1. 271 Length: 4. 273 Holding Time: A time in seconds as an unsigned integer. It has 274 the same meaning as the Holding Time field in IS-IS Hellos [IS-IS] 275 . A Smart Endnode and an Edge RBridge supporting Smart Endndoes 276 MUST send a Smart-Hello at least three times during their Holding 277 Time. If no Smart-Hellos is received from a Smart Endnode or Edge 278 RBridge within the most recent Holding Time it sent, it is assumed 279 that it is no longer available. 281 Flags: At this time all of the Flags are reserved and MUST be send 282 as zero and ignored on receipt. 284 If more than one Smart Parameters APPsub-TLV appears in a Smart- 285 Hello, the first one is used and any following ones are ignored. If 286 no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart- 287 Hello is ignored. 289 4.2. Edge RBridge's Smart-Hello 291 The edge RBridge's Smart-Hello contains the following information in 292 addition to the Smart-Parameters APPsub-TLV: 294 o RBridge's nickname. The nickname sub-TLV, specified in section 295 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS 296 router capability) in a Smart-Hello frame. If more than one 297 nickname appears in the Smart-Hello, the first one is used and the 298 following ones are ignored. 300 o Trees that RB1 can use when ingressing multi-destination frames. 301 The Tree Identifiers Sub-TLV, specified in section 2.3.4 in 302 [RFC7176], is reused here. 304 o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in 305 section 2.5 in [RFC7176], is reused for this purpose. 307 o An Autentication TLV MAY also be included. 309 4.3. Smart Endnode's Smart-Hello 311 A new APPsub-TLV (Smart-MAC TLV) is defined for use by Smart Endnodes 312 as defined below. In addition, there will be a Smart-Parameters 313 APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode 314 Smart-Hello. 316 If there are several VLANs/FGL Data Labels for that Smart Endnode, 317 the Smart-MAC APPsub-TLV is included several times in Smart Endnode's 318 Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV. 320 +-+-+-+-+-+-+-+-+ 321 |Type=Smart-MAC | (1 byte) 322 +-+-+-+-+-+-+-+-+ 323 | Length | (1 byte) 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | F |RSV | VLAN/FGL Data Label | (2 bytes or 4 bytes) 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | MAC (1) (6 bytes) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | ................. | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | MAC (N) (6 bytes) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 3 Smart-MAC APPsub-TLV 336 o Type: TRILL APPsub-TLV Type Smart-MAC, value is TBD2. 338 o Length: Total number of bytes contained in the value field. 340 o F: 1 bit. If it sets to 1, which indicates that the endnode 341 supports FGL data label, otherwise, the VLAN/FGL Data Labels 342 [RFC7172] and that this Smart-MAC APPsub-TLV has an FGL in the 343 following VLAN/FGL field. Otherwise, the VLAN/FGL Data Label 344 field is a VLAN ID. 346 o RSV: 2 bits or 6 bits, is reserved for the future use. If VLAN/ 347 FGL Data Label indicates the VLAN ID(F flag sets to 0), the RESV 348 field is 2 bits long. Otherwise it is 6 bits. 350 o VLAN/FGL Data Label: This carries a 12-bits VLAN identifier or 351 24-bits FGL Data Label that is valid for all subsequent MAC 352 addresses in this APPsub-TLV, or the value zero if no VLAN/FGL 353 data label is specified. 355 o MAC(i): This is a 48-bit MAC address reachable in the Data Label 356 given from the Smart Endnode that is announcing this APPsub-TLV. 358 5. Data Packet Processing 360 The subsections below specify Smart Endnode data packet processing. 361 All TRILL Data packets sent to or from Smart Endnodes are sent in the 362 Designated VLAN [RFC6325] of the local link but do not necessarily 363 have to be VLAN tagged. 365 5.1. Data Packet Processing for Smart Endnode 367 A Smart Endnode does not issue or receive LSPs or E-L1FS FS-LSPs or 368 calculate topology. It does the following: 370 o Smart Endnode maintains an endnode table of (the MAC address of 371 remote endnode, Data Label, the nickname of the edge RBridge's 372 attached) entries of end nodes with which the Smart Endnode is 373 communicating. Entries in this table are populated the same way 374 that an edge RBridge populates the entries in its table: 376 * learning from (source MAC address ingress nickname) on packets 377 it decapsulates. 379 * by querying a directory [RFC7067]. 381 * by having some entries configured. 383 o When Smart Endnode SE1 wishes to send unicast frame to remote node 384 D, if (MAC address of remote endnode D, Data Label, nickname) 385 entry is in SE1's endnode table, SE1 encapsulates the ingress 386 nickname as the nicknamae of the RBridge(RB1), egress nickname as 387 indicated in D's table entry. If D is unknown, SE1 either queries 388 a directory or encapsulates the packet as a multi-destination 389 frame, using one of the trees that RB1 has specified in RB1's 390 Smart-Hello. The mechanism for querying a directory is given in 391 [RFC8171]. 393 o When SE1 wishes to send a a multi-destination (multicast, unknown 394 unicast, or broadcast) to the TRILL campus, SE1 encapsulates the 395 packet using one of the trees that RB1 has specified. 397 If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, 398 the destination MAC of the outer Ethernet is All-RBridges multicast 399 address. 401 The Smart Endnode SE1 need not send Smart-Hellos as frequently as 402 normal RBridges. These Smart-Hellos could be periodically unicast to 403 the Appointed Forwarder RB1. In case RB1 crashes and restarts, or 404 the DRB changes and SE1 receives the Smart-Hello without mentioning 405 SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed 406 Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in 407 its Smart-Hellos as a Smart Endnode neighbor. 409 5.2. Data Packet Processing for Edge RBridge 411 The attached edge RBridge processes and forwards TRILL Data packets 412 based on the endnode property rather than for encapsulation and 413 forwarding the native frames the same way as the traditional 414 RBridges. There are several situations for the edge RBridges as 415 follows: 417 o If receiving an encapsulated unicast TRILL Data packet from a port 418 with a Smart Endnode, with RB1's nickname as ingress, the edge 419 RBridge RB1 forwards the frame to the specified egress nickname, 420 as with any encapsulated frame. However, RB1 MAY filter the 421 encapsulation frame based on the inner source MAC and Data Label 422 as specified for the Smart Endnode. If the MAC (or Data Label) 423 are not among the expected entries of the Smart Endnode, the frame 424 would be dropped by the edge RBridge. 426 o If receiving a unicast TRILL Data packet with RB1's nickname as 427 egress from the TRILL campus, and the destination MAC address in 428 the enclosed packet is listed as "smart endnode", RB1 leaves the 429 packet encapsulated when forwarding to the smart endnode, and both 430 the outer and inner Ethernet destination MAC is the destination 431 smart endnode's MAC address, and the outer Ethernet source MAC 432 address is the RB1's port MAC address. The edge RBridge still 433 decreases the Hop count value by 1, for there is one hop between 434 the RB1 and Smart Endnode. 436 o If receiving an multi-destination TRILL Data packet from a port 437 with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation 438 to the TRILL campus based on the distribution tree indicated by 439 the egress nickname. If the egress nickname does not correspond 440 to a distribution tree, the packet is discarded. If there are any 441 normal endnodes (i.e, non-Smart Endnodes) attached to the edge 442 RBridge RB1, RB1 decapsulates the frame and sends the native frame 443 to these ports possibly pruned based on multicast listeners, in 444 addition to forwarding the multi-destination TRILL frame to the 445 rest of the campus. 447 o If RB1 receives a native multi-destination data frame, which is 448 sent by a non-smart endnode, from a port, including hybrid 449 endnodes (smart endnodes and non-smart endnodes), RB1 will 450 encapsulate it as multi-destination TRILL Data packet , and send 451 the encapsulated multi-destination TRILL Data Packet out that same 452 port to the smart endnodes attached to the port, and also send the 453 encapsulated multi-destination TRILL Data Packet to the TRILL 454 campus through other ports . 456 o If RB1 receives a multi-destination TRILL Data packet from a 457 remote RBridge, and the exit port includes hybrid endnodes(Smart 458 Endnodes and non-Smart Endnodes), it sends two copies of multicast 459 frames out the port, one as native and the other as TRILL 460 encapsulated frame. When Smart Endnode receives multi-destination 461 TRILL Data packet, it learns the remote (MAC address, Data Label, 462 Nickname) entry, A Smart Endnodes ignores native data frames. A 463 normal (non-smart) endnode receives the native frame and learns 464 the remote MAC address and ignores the TRILL data packet. This 465 transit solution may bring some complexity for the edge RBridge 466 and waste network bandwidth resource, so avoiding the hybrid 467 endnodes scenario by attaching the Smart Endnodes and non-Smart 468 Endnodes to different ports is RECOMMENDED. 470 6. Multi-homing Scenario 472 Multi-homing is a common scenario for the Smart Endnode. The Smart 473 Endnode is on a link attached to the TRILL domain in two places: to 474 edge RBridge RB1 and RB2. Take the figure below as example. The 475 Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 476 separately. Both RB1 and RB2 could announce their nicknames to SE1. 478 . ..................... 479 . +------+ . 480 . | RB1 | . 481 . /+------+ . 482 +----------+ ./ +-----+ . +----------+ 483 |SE1(Smart |/. | RB3 |......| Smart | 484 | Endnode1)| .\ +-----+ . | Endnode2 | 485 +----------+ . \ . +----------+ 486 . +-----+ . 487 . | RB2 | TRILL . 488 . +-----+ Domain . 489 ....................... 491 Figure 4 Multi-homing Scenario 493 Smart Endnode SE1 can choose either RB1 or RB2's nickname, when 494 encapsulating and forwarding a TRILL data packet. If the active- 495 active load balance is considered for the multi-homing scenario, the 496 Smart Endnode SE1 could use both RB1 and RB2's nickname to 497 encapsulate and forward TRILL Data packet. SE1 uses RB1's nickname 498 when forwarding through RB1, and RB2's nickname when forwarding 499 through RB2. this will cause MAC flip-flopping(see [RFC7379]) of the 500 endnode table entry in the remote RBridges (or Smart Endnodes). The 501 solution for the MAC flip-flopping issue is to set a multi- homing 502 bit in the RSV field of the TRILL data packet. When remote RBridge 503 RB3 or Smart Endnodes receives a data packet with the multi-homed bit 504 set, the endnode entries (SE1's MAC address, label, RB1's nickname) 505 and (SE1's MAC address, label, RB2's nickname) will coexist as 506 endnode entries in the remote RBridge. Another solution is to use 507 the ESADI protocol to distribute multiple attachments of a MAC 508 address of a multi-homing group,The ESADI is deployed among the edge 509 RBridges (See section 5.3 of [RFC7357]). 511 7. Security Considerations 513 Smart-Hellos can be secured by using Authentication TLVs based on 514 [RFC5310]. 516 For general TRILL Security Considerations, see [RFC6325]. 518 For TRILL ES-IS Security Considerations, see [RFC8171]. 520 8. IANA Considerations 522 IANA is requested to allocate APPsub-TLV type numbers for the Smart- 523 MAC and Smart-Parameters APPsub-TLVs from the range below 256 and 524 update the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 525 Identifier 1" registry as follows. 527 +-----------+-------------------+------------------+ 528 | Protocol | Description | Reference | 529 +-----------+-------------------+------------------+ 530 | TBD1 | Smart-Parameters | [this document] | 531 | TBD2 | Smart-MAC | [this document] | 532 +-----------+-------------------+------------------+ 534 Table 1 536 9. Acknowledgements 538 The contributions of the following persons are gratefully 539 acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya 540 Krupakaran, and Andrew Qu. 542 10. References 544 10.1. Informative References 546 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 547 Gashinsky, "Directory Assistance Problem and High-Level 548 Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 549 2013, . 551 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 552 "Problem Statement and Goals for Active-Active Connection 553 at the Transparent Interconnection of Lots of Links 554 (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 555 2014, . 557 10.2. Normative References 559 [IS-IS] ISO/IEC 10589:2002, Second Edition,, "Intermediate System 560 to Intermediate System Intra-Domain Routing Exchange 561 Protocol for use in Conjunction with the Protocol for 562 Providing the Connectionless-mode Network Service (ISO 563 8473)", 2002. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, 567 DOI 10.17487/RFC2119, March 1997, 568 . 570 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 571 and M. Fanto, "IS-IS Generic Cryptographic 572 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 573 2009, . 575 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 576 Ghanwani, "Routing Bridges (RBridges): Base Protocol 577 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 578 . 580 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 581 D. Dutt, "Transparent Interconnection of Lots of Links 582 (TRILL): Fine-Grained Labeling", RFC 7172, 583 DOI 10.17487/RFC7172, May 2014, 584 . 586 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 587 D., and A. Banerjee, "Transparent Interconnection of Lots 588 of Links (TRILL) Use of IS-IS", RFC 7176, 589 DOI 10.17487/RFC7176, May 2014, 590 . 592 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 593 Stokes, "Transparent Interconnection of Lots of Links 594 (TRILL): End Station Address Distribution Information 595 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 596 September 2014, . 598 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 599 Ghanwani, A., and S. Gupta, "Transparent Interconnection 600 of Lots of Links (TRILL): Clarifications, Corrections, and 601 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 602 . 604 [RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, 605 "Transparent Interconnection of Lots of Links (TRILL): 606 Edge Directory Assistance Mechanisms", RFC 8171, 607 DOI 10.17487/RFC8171, June 2017, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 Authors' Addresses 616 Radia Perlman 617 Dell EMC 618 176 South Street 619 Hopkinton, MA 01748 620 USA 622 Phone: +1-206-291-367 623 Email: radiaperlman@gmail.com 625 Fangwei Hu 626 ZTE Corporation 627 No.889 Bibo Rd 628 Shanghai 201203 629 China 631 Phone: +86 21 68896273 632 Email: hu.fangwei@zte.com.cn 634 Donald Eastlake 635 Huawei Technologies 636 155 Beaver Street 637 Milford, MA 01757 638 USA 640 Phone: +1-508-634-2066 641 Email: d3e3e3@gmail.com 643 Ting Liao 644 Huawei Technologies 645 Nanjing, Jiangsu 210012 646 China 648 Email: liaoting1@huawei.com