idnits 2.17.1 draft-ietf-trill-smart-endnodes-11.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 (Mar 11, 2018) is 2238 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: September 12, 2018 ZTE Corporation 6 Donald Eastlake 7 Ting Liao 8 Huawei Technologies 9 Mar 11, 2018 11 TRILL Smart Endnodes 12 draft-ietf-trill-smart-endnodes-11.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 September 12, 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 . . . . . . . . . . . . . . . . 6 66 4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 7 67 4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 7 68 5. Data Packet Processing . . . . . . . . . . . . . . . . . . . 9 69 5.1. Data Packet Processing for Smart Endnode . . . . . . . . 9 70 5.2. Data Packet Processing for Edge RBridge . . . . . . . . . 10 71 6. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. Informative References . . . . . . . . . . . . . . . . . 13 77 10.2. Normative References . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 encapsulating to the incorrect egress RBridge, 110 the 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 PDU: Protocol Data Unit. 131 RBridge: Routing Bridge, an alternative name for a TRILL switch. 133 Smart Endnode: An endnode that has the capability specified in this 134 document including learning and maintaining (MAC, Data Label, 135 Nickname) entries and encapsulating/decapsulating TRILL frame. 137 Transit RBridge: An RBridge exclusively forwards encapsulated frames. 138 It is also called a transit TRILL Switch. 140 TRILL: Transparent Interconnection of Lots of Links 141 [RFC6325][RFC7780]. 143 TRILL ES-IS: TRILL End System to Intermediate System, is a variation 144 of TRILL IS-IS designed to operate on a TRILL link among and between 145 one or more TRILL switches and end stations on that link[RFC8171]. 147 TRILL Switch: a device that implements the TRILL protocol; an 148 alternative term for an RBridge. 150 2.2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 3. Solution Overview 160 The Smart Endnode solution defined in this document addresses the 161 problem of the size and freshness of the endnode learning table in 162 edge RBridges. An endnode E, attached to an edge RBridge R, tells R 163 that E would like to be a "Smart Endnode", which means that E will 164 encapsulate and decapsulate the TRILL frame, using R's nickname. 165 Because E uses R's nickname, this solution does not consume extra 166 nicknames. 168 Take Figure 1 as the example Smart Endnode scenario: RB1, RB2 and RB3 169 are the RBridges in the TRILL domain, and SE1 and SE2 are the Smart 170 Endnodes which can encapsulate and decapsulate the TRILL packets. 171 RB1 is the edge RB that SE1 and SE2 have attached to. RB1 assigns 172 one of its nicknames to be used by SE1 and SE2. 174 Each Smart Endnode, SE1 and SE2, uses RB1's nickname when 175 encapsulating, and maintains an endnode table of (MAC, label, TRILL 176 egress switch nickname) for remote endnodes that it (SE1 or SE2) is 177 corresponding with. RB1 does not decapsulate packets destined for 178 SE1 or SE2, and does not learn (MAC, label, TRILL egress switch 179 nickname) for endnodes corresponding with SE1 or SE2, but RB1 does 180 decapsulate, and does learn (MAC, label, TRILL egress switch 181 nickname) for any endnodes attached to RB1 that have not declared 182 themselves to be Smart Endnodes. 184 Just as an RBridge learns and times out (MAC, label, TRILL egress 185 switch nickname), Smart Endnodes SE1 and SE2 also learn and time out 186 endnode entries. However, SE1 and SE2 might also determine, through 187 ICMP messages or other techniques that an endnode entry is not 188 successfully reaching the destination endnode, and can be deleted, 189 even if the entry has not timed out. 191 If SE1 wishes to correspond with destination MAC D, and no endnode 192 entry exists, SE1 will encapsulate the packet as an unknown 193 destination, or consulting a directory [RFC7067] (just as an RBridge 194 would do if there was no endnode entry). 196 +----------+ 197 |SE1(Smart | 198 |Endnode1) | \ +------------------------------+ 199 +----------+ \ / \ 200 \ /+------+ +------+ +-----+ \ +-----------+ 201 /-+-| RB 1 |---| RB2 |----| RB3 |-----+--|Endnode3 | 202 / | +------+ +------+ +-----+ | |MAC=D | 203 +----------+ / \ / +-----------+ 204 |SE2(Smart | \ / 205 | Endnode2)| +------------------------------+ 206 +----------+ 207 Figure 1 Smart Endnode Scenario 209 The mechanism in this draft is that the Smart Endnode SE1 issues a 210 Smart-Hello, indicating SE1's desire to act as a Smart Endnode, 211 together with the set of MAC addresses and Data Labels that SE1 owns. 212 The Smart-Hello is used to announce the Smart Endnode capability and 213 parameters (such as MAC address, Data Label etc.). The Smart-Hello 214 is a type of TRILL ES-IS PDU, which is specified in section 5 of 215 [RFC8171]. The detailed content for a Smart Endnode's Smart-Hello is 216 defined in section 4. 218 If RB1 supports having a Smart Endnode neighbor it also sends Smart- 219 Hellos. The Smart Endnode learns from RB1's Smart-Hellos what RB1's 220 nickname is and which trees RB1 can use when RB1 ingresses multi- 221 destination frames. Although Smart Endnode SE1 transmits Smart- 222 Hellos, it does not transmit or receive LSPs or E-L1FS FS-LSPs 223 [RFC7780]. 225 Since a Smart Endnode can encapsulate TRILL Data packets, it can 226 cause the Inner.Lable to be a Fine Grained Label [RFC7172], thus this 227 method supports FGL aware endnodes. When and how a Smart Endnode 228 decides to use the FGL instead of VLANs to encapsulate the TRILL Data 229 packet is out of scope in this document. 231 4. Smart-Hello Mechanism between Smart Endnode and RBridge 233 The subsections below describe Smart-Hello messages. 235 4.1. Smart-Hello Encapsulation 237 Although a Smart Endnode is not an RBridge, does not send LSPs or 238 maintain a copy of the link state database, and does not perform 239 routing calculations, it is required to have a "Hello" mechanism (1) 240 to announce to edge RBridges that it is a Smart Endnode and (2) to 241 tell them what MAC addresses it is handling in what Data Labels. 242 Similarly, an edge RBridge that supports Smart Endnodes needs a 243 message (1) to announce that support, (2) to inform Smart Endnodes 244 what nickname to use for ingress and what nickname(s) can be used as 245 egress nickname in a multi-destination TRILL Data packet, and (3) the 246 list of Smart Endnodes it knows about on that link. 248 The messages sent by Smart Endnodes and by edge RBridges that support 249 Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type 250 of TRILL ES-IS PDU, which is specified in [RFC8171]. 252 The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes 253 and for Smart-Hellos sent by Edge RBridges, consists of TRILL IS-IS 254 TLVs as described in the following two sub-sections. The non- 255 extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 256 8-bit size and type field. Both types of Smart-Hellos MUST include a 257 Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV: 259 +-+-+-+-+-+-+-+-+- 260 |Smart-Parameters| (1 byte) 261 +-+-+-+-+-+-+-+-+- 262 | Length | (1 byte) 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Holding Time | (2 bytes) 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Flags | (2 bytes) 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2 Smart Parameters APPsub-TLV 271 o Type: APPsub-TLV type Smart-Parameters, value is TBD1. 273 o Length: 4. 275 o Holding Time: A time in seconds as an unsigned integer. It has the 276 same meaning as the Holding Time field in IS-IS Hellos [IS-IS]. A 277 Smart Endnode and an Edge RBridge supporting Smart Endnodes MUST send 278 a Smart-Hello at least three times during their Holding Time. If no 279 Smart-Hellos is received from a Smart Endnode or Edge RBridge within 280 the most recent Holding Time it sent, it is assumed that it is no 281 longer available. 283 o Flags: At this time all of the Flags are reserved and MUST be send 284 as zero and ignored on receipt. 286 If more than one Smart Parameters APPsub-TLV appears in a Smart- 287 Hello, the first one is used and any following ones are ignored. If 288 no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart- 289 Hello is ignored. 291 4.2. Edge RBridge's Smart-Hello 293 The edge RBridge's Smart-Hello contains the following information in 294 addition to the Smart-Parameters APPsub-TLV: 296 o RBridge's nickname. The nickname sub-TLV, specified in section 297 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS 298 router capability) in a Smart-Hello frame. If more than one nickname 299 appears in the Smart-Hello, the first one is used and the following 300 ones are ignored. 302 o Trees that RB1 can use when ingressing multi-destination frames. 303 The Tree Identifiers Sub-TLV, specified in section 2.3.4 in 304 [RFC7176], is reused here. 306 o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in 307 section 2.5 in [RFC7176], is reused for this purpose. 309 An Authentication TLV MAY also be included. 311 4.3. Smart Endnode's Smart-Hello 313 A new APPsub-TLV (Smart-MAC TLV) is defined for use by Smart Endnodes 314 as defined below. In addition, there will be a Smart-Parameters 315 APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode 316 Smart-Hello. 318 If there are several VLANs/FGL Data Labels for that Smart Endnode, 319 the Smart-MAC APPsub-TLV is included several times in Smart Endnode's 320 Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV. 322 +-+-+-+-+-+-+-+-+ 323 |Type=Smart-MAC | (1 byte) 324 +-+-+-+-+-+-+-+-+ 325 | Length | (1 byte) 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |F|M| RSV | VLAN/FGL Data Label | (4 bytes) 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | MAC (1) (6 bytes) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ................. | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | MAC (N) (6 bytes) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 3 Smart-MAC APPsub-TLV 338 o Type: TRILL APPsub-TLV Type Smart-MAC, value is TBD2. 340 o Length: Total number of bytes contained in the value field of the 341 TLV, that is, the sum of the length of the F/M/RSV/FGL Data Label 342 fields and 6 times the number of MAC addresses present. So, if there 343 are n MAC addresses, this is 4+6*n. 345 o F: 1 bit. If it is set to 1, it indicates that the endnode 346 supports FGL data labels [RFC7172], and that this Smart-MAC APPsub- 347 TLV has an FGL in the following VLAN/FGL field. Otherwise, the VLAN/ 348 FGL Data Label field is a VLAN ID.(See below for the format of the 349 VLAN/FGL Data Label field). 351 o M: 1 bit. If it is set to 1, it indicates multi-homing(See 352 Section 6). If it is set to 0, it indicates that the Smart Endnodes 353 are not using multi-homing. 355 o RSV: 6 bits, is reserved for the future use. 357 o VLAN/FGL Data Label: 24bits. If F is 1, this field is a 24-bit FGL 358 Data Label for all subsequent MAC addresses in this APPsub-TLV. 359 Otherwise, if F is 0, the lower 12 bits is the VLAN of all subsequent 360 MAC addresses in this APPsub-TLV, and the upper 12 bits is not 361 used(sent as zero and ignored on receipt). If there is no VLAN/FGL 362 data label specified, the VLAN/FGL Data Label is zero. 364 o MAC(i): This is a 48-bit MAC address reachable in the Data Label 365 sent by the Smart Endnode that is announcing this APPsub-TLV. 367 5. Data Packet Processing 369 The subsections below specify Smart Endnode data packet processing. 370 All TRILL Data packets sent to or from Smart Endnodes are sent in the 371 Designated VLAN [RFC6325] of the local link but do not necessarily 372 have to be VLAN tagged. 374 5.1. Data Packet Processing for Smart Endnode 376 A Smart Endnode does not issue or receive LSPs or E-L1FS FS-LSPs or 377 calculate topology. It does the following: 379 o A Smart Endnode maintains an endnode table of (the MAC address of 380 remote endnode, Data Label, the nickname of the edge RBridge's 381 attached) entries of end nodes with which the Smart Endnode is 382 communicating. Entries in this table are populated the same way 383 that an edge RBridge populates the entries in its table: 385 * learning from (source MAC address ingress nickname) on packets 386 it decapsulates. 388 * by querying a directory [RFC7067]. 390 * by having some entries configured. 392 o When Smart Endnode SE1 wishes to send unicast frame to remote node 393 D, if (MAC address of remote endnode D, Data Label, nickname) 394 entry is in SE1's endnode table, SE1 encapsulates the ingress 395 nickname as the nickname of the RBridge(RB1), egress nickname as 396 indicated in D's table entry. If D is unknown, SE1 either queries 397 a directory or encapsulates the packet as a multi-destination 398 frame, using one of the trees that RB1 has specified in RB1's 399 Smart-Hello. The mechanism for querying a directory is given in 400 [RFC8171]. 402 o When SE1 wishes to send a BUM packet to the TRILL campus, SE1 403 encapsulates the packet using one of the trees that RB1 has 404 specified. 406 If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, 407 the destination MAC of the outer Ethernet is the All-RBridges 408 multicast address. 410 The Smart Endnode SE1 need not send Smart-Hellos as frequently as 411 normal RBridges. These Smart-Hellos could be periodically unicast to 412 the Appointed Forwarder RB1. In case RB1 crashes and restarts, or 413 the DRB changes and SE1 receives the Smart-Hello without mentioning 414 SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed 415 Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in 416 its Smart-Hellos as a Smart Endnode neighbor. 418 5.2. Data Packet Processing for Edge RBridge 420 The attached edge RBridge processes and forwards TRILL Data packets 421 based on the endnode property rather than for encapsulation and 422 forwarding the native frames the same way as the traditional 423 RBridges. There are several situations for the edge RBridges as 424 follows: 426 o If receiving an encapsulated unicast TRILL Data packet from a port 427 with a Smart Endnode, with RB1's nickname as ingress, the edge 428 RBridge RB1 forwards the frame to the specified egress nickname, as 429 with any encapsulated frame. However, RB1 SHOULD filter the 430 encapsulation frame based on the inner source MAC and Data Label as 431 specified for the Smart Endnode. If the MAC (or Data Label) are not 432 among the expected entries of the Smart Endnode, the frame would be 433 dropped by the edge RBridge. If the edge RBridge does not perform 434 this check, it makes it easier for a rogue end station to inject 435 bogus TRILL Data packets into the TRILL campus. 437 o If receiving a unicast TRILL Data packet with RB1's nickname as 438 egress from the TRILL campus, and the destination MAC address in the 439 enclosed packet is a MAC address that has been listed by a "Smart 440 Endnode", RB1 leaves the packet encapsulated to that Smart Endnode. 441 The outer Ethernet destination MAC is the destination Smart Endnode's 442 MAC address, the inner destination MAC address is either the Smart 443 Endnode's MAC address or some other MAC address that the Smart 444 Endnode advertised in its Smart Hello, and the outer Ethernet source 445 MAC address is the RB1's port MAC address. The edge RBridge still 446 decreases the Hop count value by 1, for there is one hop between the 447 RB1 and Smart Endnode. 449 o If receiving a multi-destination TRILL Data packet from a port with 450 a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation to the 451 TRILL campus based on the distribution tree indicated by the egress 452 nickname. If the egress nickname does not correspond to a 453 distribution tree, the packet is discarded. If there are any normal 454 endnodes (i.e, non-Smart Endnodes) attached to the edge RBridge RB1, 455 RB1 decapsulates the frame and sends the native frame to these ports 456 possibly pruned based on multicast listeners, in addition to 457 forwarding the multi-destination TRILL frame to the rest of the 458 campus. 460 o If RB1 receives a native multi-destination data frame, which is 461 sent by a non-Smart Endnode, from a port, including hybrid endnodes 462 (Smart Endnodes and non-Smart Endnodes), RB1 will encapsulate it as 463 multi-destination TRILL Data packet , and send the encapsulated 464 multi-destination TRILL Data Packet out that same port to the Smart 465 Endnodes attached to the port, and also send the encapsulated multi- 466 destination TRILL Data Packet to the TRILL campus through other 467 ports. 469 o If RB1 receives a multi-destination TRILL Data packet from a remote 470 RBridge, and the exit port includes hybrid endnodes(Smart Endnodes 471 and non-Smart Endnodes), it sends two copies of multicast frames out 472 the port, one as native and the other as TRILL encapsulated frame. 473 When Smart Endnode receives multi-destination TRILL Data packet, it 474 learns the remote (MAC address, Data Label, Nickname) entry. A Smart 475 Endnodes ignores native data frames. A normal (non-Smart) Endnode 476 receives the native frame and learns the remote MAC address and 477 ignores the TRILL data packet. This transit solution may bring some 478 complexity for the edge RBridge and waste network bandwidth resource, 479 so avoiding the hybrid endnodes scenario by attaching the Smart 480 Endnodes and non-Smart Endnodes to different ports is RECOMMENDED. 482 6. Multi-homing Scenario 484 Multi-homing is a common scenario for the Smart Endnode. The Smart 485 Endnode is on a link attached to the TRILL domain in two places: to 486 edge RBridge RB1 and RB2. Take the figure below as example. The 487 Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 488 separately. Both RB1 and RB2 could announce their nicknames to SE1. 490 . ..................... 491 . +------+ . 492 . | RB1 | . 493 . /+------+ . 494 +----------+ ./ +-----+ . +----------+ 495 |SE1(Smart |/. | RB3 |......| Smart | 496 | Endnode1)| .\ +-----+ . | Endnode2 | 497 +----------+ . \ . +----------+ 498 . +-----+ . 499 . | RB2 | TRILL . 500 . +-----+ Domain . 501 ....................... 503 Figure 4 Multi-homing Scenario 505 Smart Endnode SE1 can choose either RB1 or RB2's nickname, when 506 encapsulating and forwarding a TRILL data packet. If the active- 507 active load balance is considered for the multi-homing scenario, the 508 Smart Endnode SE1 could use both RB1 and RB2's nickname to 509 encapsulate and forward TRILL Data packet. SE1 uses RB1's nickname 510 when forwarding through RB1, and RB2's nickname when forwarding 511 through RB2. This will cause MAC flip-flopping(see [RFC7379]) of the 512 endnode table entry in the remote RBridges (or Smart Endnodes). The 513 solution for the MAC flip-flopping issue is to set a multi- homing 514 bit in the RSV field of the TRILL data packet. When remote RBridge 515 RB3 or Smart Endnodes receives a data packet with the multi-homed bit 516 set, the endnode entries (SE1's MAC address, label, RB1's nickname) 517 and (SE1's MAC address, label, RB2's nickname) will coexist as 518 endnode entries in the remote RBridge. (An alternative solution 519 would be to use the ESADI protocol to distribute multiple attachments 520 of a MAC address of a multi-homing group, The ESADI is deployed among 521 the edge RBridges (See section 5.3 of [RFC7357])). 523 7. Security Considerations 525 Smart-Hellos can be secured by using Authentication TLVs based on 526 [RFC5310]. If they are not secured, then it is easier for a rogue 527 end station that does not posses the required keying material to be 528 falsely recognized as a valid Smart Endnode. 530 For general TRILL Security Considerations, see [RFC6325]. As stated 531 there, since end stations are connected to edge RBridge ports by 532 Ethernet, those ports MAY require end stations to authenticate 533 themselves using [IEEE802.1X] and authenticate and encrypt traffic 534 to/from the RBridge port with [IEEE802.1AE]. 536 If they misbehave, Smart Endnodes can forge arbitrary ingress and 537 egress nicknames in the TRILL Headers of the TRILL Data packets they 538 construct. Decapsulating at egress RBridges or remote Smart Endnodes 539 that believe such a forged ingress nickname would send future traffic 540 destined for the inner source MAC address of the TRILL Data frame to 541 the wrong edge RBridge if data plane learning is in use. Because of 542 this, an RBridge port should not be configured to support Smart 543 Endnodes unless the end stations on that link are trusted or can be 544 adequately authenticated. 546 As with any end station, Smart Endnodes can forge the outer MAC 547 addresses of packets they send (See Section 6 of [RFC6325].) Because 548 they encapsulate TRILL Data packets, they can also forge inner MAC 549 addresses. The encapsulation performed by Smart Endnodes also means 550 they can send data in any Data Label which means they must be trusted 551 in order to enforce a security policy based on Data Labels. 553 The TRILL-Hello is a type of TRILL ES-IS, and is defined in 554 [RFC8171]. Receiving and processing TRILL-Hello for RBridges and 555 Smart Endnodes would not bring more security and vulnerability issues 556 than the TRILL ES-IS security defined in [RFC8171]. 558 For added security against the compromise of data due to its mis- 559 delivery for any reason, including the above, end-to-end encryption 560 and authentication should be considered; that is, encryption and 561 authentication from source end station to destination end station. 563 The mechanism described in this document requires Smart Endnodes to 564 be aware of the MAC address(es) of the TRILL edge RBridge(s) to which 565 they are attached and the egress RBridge nickname from which the 566 destination of the packets is reachable. With that information, 567 Smart Endnodes can learn a substantial amount about the topology of 568 the TRILL domain. Therefore, there could be a potential security 569 risk when the Smart Endnodes are not trusted or are compromised. 571 8. IANA Considerations 573 IANA is requested to allocate APPsub-TLV type numbers for the Smart- 574 MAC and Smart-Parameters APPsub-TLVs from the range below 256 and 575 update the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 576 Identifier 1" registry as follows. 578 +-----------+-------------------+------------------+ 579 | Protocol | Description | Reference | 580 +-----------+-------------------+------------------+ 581 | TBD1 | Smart-Parameters | [this document] | 582 | TBD2 | Smart-MAC | [this document] | 583 +-----------+-------------------+------------------+ 585 Table 1 587 9. Acknowledgements 589 The contributions of the following persons are gratefully 590 acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya 591 Krupakaran and Andrew Qu. 593 10. References 595 10.1. Informative References 597 [IEEE802.1AE] 598 "IEEE Standard for Local and metropolitan area networks-- 599 Media Access Control (MAC) Security.", 2006. 601 [IEEE802.1X] 602 "IEEE Standard for Local and metropolitan area networks-- 603 Port-Based Network Access Control", 2010. 605 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 606 Gashinsky, "Directory Assistance Problem and High-Level 607 Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 608 2013, . 610 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 611 "Problem Statement and Goals for Active-Active Connection 612 at the Transparent Interconnection of Lots of Links 613 (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 614 2014, . 616 10.2. Normative References 618 [IS-IS] ISO/IEC 10589:2002, Second Edition,, "Intermediate System 619 to Intermediate System Intra-Domain Routing Exchange 620 Protocol for use in Conjunction with the Protocol for 621 Providing the Connectionless-mode Network Service (ISO 622 8473)", 2002. 624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 625 Requirement Levels", BCP 14, RFC 2119, 626 DOI 10.17487/RFC2119, March 1997, 627 . 629 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 630 and M. Fanto, "IS-IS Generic Cryptographic 631 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 632 2009, . 634 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 635 Ghanwani, "Routing Bridges (RBridges): Base Protocol 636 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 637 . 639 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 640 D. Dutt, "Transparent Interconnection of Lots of Links 641 (TRILL): Fine-Grained Labeling", RFC 7172, 642 DOI 10.17487/RFC7172, May 2014, 643 . 645 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 646 D., and A. Banerjee, "Transparent Interconnection of Lots 647 of Links (TRILL) Use of IS-IS", RFC 7176, 648 DOI 10.17487/RFC7176, May 2014, 649 . 651 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 652 Stokes, "Transparent Interconnection of Lots of Links 653 (TRILL): End Station Address Distribution Information 654 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 655 September 2014, . 657 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 658 Ghanwani, A., and S. Gupta, "Transparent Interconnection 659 of Lots of Links (TRILL): Clarifications, Corrections, and 660 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 661 . 663 [RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, 664 "Transparent Interconnection of Lots of Links (TRILL): 665 Edge Directory Assistance Mechanisms", RFC 8171, 666 DOI 10.17487/RFC8171, June 2017, 667 . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 Authors' Addresses 675 Radia Perlman 676 Dell EMC 677 176 South Street 678 Hopkinton, MA 01748 679 USA 681 Phone: +1-206-291-367 682 Email: radiaperlman@gmail.com 684 Fangwei Hu 685 ZTE Corporation 686 No.889 Bibo Rd 687 Shanghai 201203 688 China 690 Phone: +86 21 68896273 691 Email: hu.fangwei@zte.com.cn 692 Donald Eastlake 693 Huawei Technologies 694 155 Beaver Street 695 Milford, MA 01757 696 USA 698 Phone: +1-508-634-2066 699 Email: d3e3e3@gmail.com 701 Ting Liao 702 Huawei Technologies 703 Nanjing, Jiangsu 210012 704 China 706 Email: liaoting1@huawei.com