idnits 2.17.1 draft-ietf-trill-smart-endnodes-04.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 255: '...hat VLAN. It is RECOMMENDED that Smar...' RFC 2119 keyword, line 269: '...h types of Smart-Hellos MUST include a...' RFC 2119 keyword, line 291: '... MUST send a Smart-Hello at least...' RFC 2119 keyword, line 296: '...he Flags are reserved and MUST be send...' RFC 2119 keyword, line 322: '...utentication TLV MAY also be included....' (5 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 15, 2016) is 2808 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) == Missing Reference: '0x005' is mentioned on line 565, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 1 error (**), 0 flaws (~~), 2 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 16, 2017 ZTE Corporation 6 Donald. Eastlake 3rd 7 Huawei technology 8 Kesava. Krupakaran 9 Dell 10 Ting. Liao 11 ZTE Corporation 12 August 15, 2016 14 TRILL Smart Endnodes 15 draft-ietf-trill-smart-endnodes-04.txt 17 Abstract 19 This draft addresses the problem of the size and freshness of the 20 endnode learning table in edge RBridges, by allowing endnodes to 21 volunteer for endnode learning and encapsulation/decapsulation. Such 22 an endnode is known as a "Smart Endnode". Only the attached edge 23 RBridge can distinguish a "Smart Endnode" from a "normal endnode". 24 The smart endnode uses the nickname of the attached edge RBridge, so 25 this solution does not consume extra nicknames. The solution also 26 enables Fine Grained Label aware endnodes. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 16, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 5 66 4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 5 67 4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 7 68 4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 8 69 5. Data Packet Processing . . . . . . . . . . . . . . . . . . . 9 70 5.1. Data Packet Processing for Smart Endnode . . . . . . . . 9 71 5.2. Data Packet Processing for Edge RBridge . . . . . . . . . 10 72 6. Multi-homing Scenario . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Informative References . . . . . . . . . . . . . . . . . 13 78 10.2. Normative References . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The IETF TRILL (Transparent Interconnection of Lots of Links) 84 protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame 85 forwarding without configuration, safe forwarding even during periods 86 of temporary loops, and support for multipathing of both unicast and 87 multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] 88 [RFC7176] link state routing and encapsulating traffic using a header 89 that includes a hop count. Devices that implement TRILL are called 90 "RBridges" (Routing Bridges) or "TRILL Switches". 92 An RBridge that attaches to endnodes is called an "edge RBridge" or 93 "edge TRILL Switch", whereas one that exclusively forwards 94 encapsulated frames is known as a "transit RBridge" or "transit TRILL 95 Switch". An edge RBridge traditionally is the one that encapsulates 96 a native Ethernet frame with a TRILL header, or that receives a 97 TRILL-encapsulated packet and decapsulates the TRILL header. To 98 encapsulate efficiently, the edge RBridge must keep an "endnode 99 table" consisting of (MAC, Data Label, TRILL egress switch nickname) 100 sets, for those remote MAC addresses in Data Labels currently 101 communicating with endnodes to which the edge RBridge is attached. 103 These table entries might be configured, received from ESADI 104 [RFC7357], looked up in a directory [RFC7067], or learned from 105 decapsulating received traffic. If the edge RBridge has attached 106 endnodes communicating with many remote endnodes, this table could 107 become very large. Also, if one of the MAC addresses and Data Labels 108 in the table has moved to a different remote TRILL switch, it might 109 be difficult for the edge RBridge to notice this quickly, and because 110 the edge RBridge is encapsulting to the incorrect egress RBridge, the 111 traffic will get lost. 113 2. Solution Overview 115 The Smart Endnode solution proposed in this document addresses the 116 problem of the size and freshness of the endnode learning table in 117 edge RBridges. An endnode E, attached to an edge RBridge R, tells R 118 that E would like to be a "Smart Endnode", which means that E will 119 encapsulate and decapsulate the TRILL frame, using R's nickname. 120 Because E uses R's nickname, this solution does not consume extra 121 nicknames. 123 Take the below figure as the example Smart Endnode scenario: RB1, RB2 124 and RB3 are the RBridges in the TRILL domain, and smart SE1 and SE2 125 are the smart ennodes which can encapsulate and decapsulate the TRILL 126 packets. RB1 is the edge RB and it is been attached by SE1 and SE2. 127 RB1 assigns its nickname to SE1 and SE2. 129 Each Smart Endnode, SE1 and SE2, uses RB1's nickname when 130 encapsulating, and maintains an endnode table of (MAC, label, TRILL 131 egress switch nickname) for remote endnodes that it (SE1 or SE2) is 132 corresponding with. RB1 does not decapsulate packets destined for 133 SE1 or SE2, and does not learn (MAC, label, TRILL egress switch 134 nickname) for endnodes corresponding with SE1 or SE2, but RB1 does 135 decapsulate, and does learn (MAC, label, TRILL egress switch 136 nickname) for any endnodes attached to RB1 that have not declared 137 themselves to be Smart Endnodes. 139 Just as an RBridge learns and times out (MAC, label, TRILL egress 140 switch nickname), Smart Endnodes SE1 and SE2 also learn and time out 141 endnode entries. However, SE1 and SE2 might also determine, through 142 ICMP messages or other techniques that an endnode entry is not 143 successfully reaching the destination endnode, and can be deleted, 144 even if the entry has not timed out. 146 If SE1 wishes to correspond with destination MAC D, and no endnode 147 entry exists, SE1 will encapsulate the packet as an unknown 148 destination, or examining updates to the ESADI link state database 149 [RFC7357], or consulting a directory [RFC7067] (just as an RBridge 150 would do if there was no endnode entry). 152 +----------+ 153 |SE1(Smart | 154 |Endnode1) | \ +------------------------------+ 155 +----------+ \ / \ 156 \ /+------+ +------+ +-----+ \ +----------+ 157 /-+-| RB 1 |---| RB2 |----| RB3 |-----+--| Endnode1 | 158 / | +------+ +------+ +-----+ | +----------+ 159 +----------+ / \ / 160 |SE2(Smart | \ / 161 | Endnode2)| +------------------------------+ 162 +----------+ 163 Figure 1 Smart Endnode Scenario 165 The mechanism in this draft is that the Smart Endnode SE1 issues a 166 Smart-Hello, indicating SE1's desire to act as a Smart Endnode, 167 together with the set of MAC addresses and Data Labels that SE1 owns, 168 and whether SE1 would like to receive ESADI packets. The Smart-Hello 169 is a light type of TRILL-hello formatted as a native RBridge Channel 170 [RFC7178] message, which is used to announce the Smart Endnode 171 capability and parameters (such as MAC address, VLAN ID etc.). The 172 detailed content for a smart endnode's Smart-Hello is defined in 173 section 4. 175 If RB1 supports having a Smart Endnode neighbor it also sends Smart- 176 Hellos. The smart endnode learns from RB1's Smart-Hellos what RB1's 177 nickname is and which trees RB1 can use when RB1 ingresses multi- 178 destination frames. Although Smart Endnode SE1 transmits Smart- 179 Hellos, it does not transmit or receive LSPs or E-L1FS FS-LSPs 180 [RFC7780]. 182 Since a Smart Endnode can encapsulate TRILL Data packets, it can 183 cause the Inner.Lable to be a Fine Grained Label [RFC7172], thus this 184 method supports FGL aware endnodes. 186 3. Terminology 188 Edge RBridge: An RBridge providing endnode service on at least one of 189 its ports. It is also called an edge TRILL Switch. 191 Data Label: VLAN or FGL. 193 DRB: Designated RBridge [RFC6325]. 195 ESADI: End Station Address Distribution Information [RFC7357]. 197 FGL: Fine Grained Label [RFC7172]. 199 IS-IS: Intermediate System to Intermediate System [IS-IS]. 201 RBridge: Routing Bridge, an alternative name for a TRILL switch. 203 Smart Endnode: An endnode that has the capability specified in this 204 document including learning and maintaining (MAC, Data Label, 205 Nickname) entries and encapsulating/decapsulating TRILL frame. 207 Transit RBridge: An RBridge exclusively forwards encapsulated frames. 208 It is also named as transit RBridge. 210 TRILL: Transparent Interconnection of Lots of Links 211 [RFC6325][RFC7780]. 213 TRILL Switch: a device that implements the TRILL protocol; an 214 alternative term for an RBridge. 216 4. Smart-Hello Mechanism between Smart Endnode and RBridge 218 The subsections below describe Smart-Hello messages. 220 4.1. Smart-Hello Encapsulation 222 Although a Smart Endnode is not an RBridge, does not send LSPs or 223 maintain a copy of the link state database, and does not perform 224 routing calculations, it is required to have a "Hello" mechanism (1) 225 to announce to edge RBridges that it is a Smart Endnode and (2) to 226 tell them what MAC addresses it is handling in what Data Labels. 227 Similarly, an edge RBridge that supports Smart Endnodes needs a 228 message (1) to announce that support, (2) to inform Smart Endnodes 229 what nickname to use for ingress and what nickname(s) can be used as 230 egress nickname in a multi-destination TRILL Data packet, and (3) the 231 list of smart end nodes it knows about on that link. 233 The messages sent by Smart Endnodes and by edge RBridges that support 234 Smart Endnodes are called "Smart-Hellos", and are carried through 235 native RBridge Channel messages (see Section 4 of [RFC7178]). They 236 are structured as follows: 238 +----------+----------------+-------------+----------+ 239 | Ethernet | RBridge | Smart-Hello | Ethernet | 240 | Header | Channel Header | Payload | FCS | 241 +----------+----------------+-------------+----------+ 243 Figure 2 Smart-Hello Structure 245 In the Ethernet Header, the source MAC address is the address of the 246 Smart Endnode or edge RBridge port on which the message is sent. If 247 the Smart-Hello is sent by a Smart Endnode and is multicast, the 248 destination MAC address is All-Edge-RBridges. If the Smart-Hello is 249 unicast to an edge RBridge, the destination MAC address is the MAC 250 address of the RBridge. If the Smart-Hello is sent by an Edge 251 RBridge and is multicast, the destination MAC address is TRILL-End- 252 Stations, and if it is unicast to a Smart Endnode, the MAC address is 253 the MAC address of the Smart Endnode. The frame is sent in the 254 Designated VLAN of the link so if a VLAN tag is present, it specifies 255 that VLAN. It is RECOMMENDED that Smart-Hellos be sent with priority 256 7 to minimize the probability that they might be delayed or lost in 257 any bridges that might be in the link. 259 The RBridge Channel Header begins with the RBridge Channel Ethertype. 260 In the RBridge Channel Header, the Channel Protocol number is as 261 assigned by IANA (see Section 8) and in the flags field, the NA bit 262 is one, the MH bit is zero and the setting of the SL bit is an 263 implementation choice. 265 The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes 266 and for Smart-Hellos sent by Edge RBridges, consists of TRILL IS-IS 267 TLVs as described in the following two sub-sections. The non- 268 extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 269 8-bit size and type field. Both types of Smart-Hellos MUST include a 270 Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV: 272 +-+-+-+-+-+-+-+-+- 273 |Smart-Parameters| (1 byte) 274 +-+-+-+-+-+-+-+-+- 275 | Length | (1 byte) 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Holding Time | (2 bytes) 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Flags | (2 bytes) 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 3 Smart Parameters APPsub-TLV 284 Type: APPsub-TLV type Smart-Parameters, value is TBD1. 286 Length: 4. 288 Holding Time: A time in seconds as an unsigned integer. It has 289 the same meaning as the Holding Time field in IS-IS Hellos [IS-IS] 290 . A Smart Endnode and an Edge RBridge supporting Smart Endndoes 291 MUST send a Smart-Hello at least three times during their Holding 292 Time. If no Smart-Hellos is received from a Smart Endnode or Edge 293 RBridge within the most recent Holding Time it sent, it is assumed 294 that it is no longer available. 296 Flags: At this time all of the Flags are reserved and MUST be send 297 as zero and ignored on receipt. 299 If more than one Smart Parameters APPsub-TLV appears in a Smart- 300 Hello, the first one is used and any following ones are ignored. If 301 no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart- 302 Hello is ignored. 304 4.2. Edge RBridge's Smart-Hello 306 The edge RBridge's Smart-Hello contains the following information in 307 addition to the Smart-Parameters APPsub-TLV: 309 o RBridge's nickname. The nickname sub-TLV, specified in section 310 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS 311 router capability) in a Smart-Hello frame. If more than one 312 nickname appears in the Smart-Hello, the first one is used and the 313 following ones are ignored. 315 o Trees that RB1 can use when ingressing multi-destination frames. 316 The Tree Identifiers Sub-TLV, specified in section 2.3.4 in 317 [RFC7176], is reused here. 319 o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in 320 section 2.5 in [RFC7176], is reused for this purpose. 322 o An Autentication TLV MAY also be included. 324 4.3. Smart Endnode's Smart-Hello 326 A new APPsub-TLV (Smart-MAC TLV) is defined for use by Smart Endnodes 327 as defined below. In addition, there will be a Smart-Parameters 328 APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode 329 Smart-Hello. 331 If there are several VLANs/FGL Data Labels for that Smart Endnode, 332 the Smart-MAC APPsub-TLV is included several times in Smart Endnode's 333 Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV. 335 +-+-+-+-+-+-+-+-+ 336 |Type=Smart-MAC | (1 byte) 337 +-+-+-+-+-+-+-+-+ 338 | Length | (1 byte) 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 |E|F|RSV | VLAN/FGL Data Label | (2 bytes or 4 bytes) 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | MAC (1) (6 bytes) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | ................. | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | MAC (N) (6 bytes) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 4 Smart-MAC APPsub-TLV 351 o Type: TRILL APPsub-TLV Type Smart-MAC, value is TBD2. 353 o Length: Total number of bytes contained in the value field. 355 o E: one bit. If it sets to 1, which indicates that the endnode 356 should receive ESADI frames for the VLAN or FGL in the APPsub-TLV. 358 o F: one bit. If it sets to 1, which indicates that the endnode 359 supports FGL data label, otherwise, the VLAN/FGL Data Labels 360 [RFC7172] and that this Smart-MAC APPsub-TLV has an FGL in the 361 following VLAN/FGL field. Otherwise, the VLAN/FGL Data Label 362 field is a VLAN ID. 364 o RSV: 2 bits or 6 bits, is reserved for the future use. If VLAN/ 365 FGL Data Label indicates the VLAN ID(F flag sets to 0), the RESV 366 field is 2 bits long. Otherwise it is 6 bits. 368 o VLAN/FGL Data Label: This carries a 12-bits VLAN identifier or 369 24-bits FGL Data Label that is valid for all subsequent MAC 370 addresses in this APPsub-TLV, or the value zero if no VLAN/FGL 371 data label is specified. 373 o MAC(i): This is a 48-bit MAC address reachable in the Data Label 374 given from the Smart Endnode that is announcing this APPsub-TLV. 376 5. Data Packet Processing 378 The subsections below specify Smart Endnode data packet processing. 379 All TRILL Data packets sent to or from Smart Endnodes are sent in the 380 Designated VLAN [RFC6325] of the local link but do not necessarily 381 have to be VLAN tagged. 383 5.1. Data Packet Processing for Smart Endnode 385 A Smart Endnode does not issue or receive LSPs or E-L1FS FS-LSPs or 386 calculate topology. It does the following: 388 o Smart Endnode maintains an endnode table of (the MAC address of 389 remote endnode, Data Label, the nickname of the edge RBridge's 390 attached) entries of end nodes with which the Smart Endnode is 391 communicating. Entries in this table are populated the same way 392 that an edge RBridge populates the entries in its table: 394 * learning from (source MAC address ingress nickname) on packets 395 it decapsulates. 397 * from ESADI [RFC7357]. 399 * by querying a directory [RFC7067]. 401 * by having some entries configured. 403 o When Smart Endnode SE1 wishes to send unicast frame to remote node 404 D, if (MAC address of remote endnode D, Data Label, nickname) 405 entry is in SE1's endnode table, SE1 encapsulates with ingress 406 nickname=the nicknamae of the RBridge(RB1), egress nickname as 407 indicated in D's table entry. If D is unknown, SE1 either queries 408 a directory or runs ESADI protocol, or encapsulates the packet as 409 a multi-destination frame, using one of the trees that RB1 has 410 specified in RB1's Smart-Hello. The mechanism for querying a 411 directory or running ESADI is out of scope for this document. 413 o When SE1 wishes to send a a multi-destination (multicast, unknown 414 unicast, or broadcast) to the TRILL campus, SE1 encapsulates the 415 packet using one of the trees that RB1 has specified. 417 Whether the Smart Endnode SE1 sends a multi-destination TRILL Data 418 packet, the destination MAC of the outer Ethernet is the MAC address 419 of RB1's port. 421 The Smart Endnode SE1 need not send Smart-Hellos as frequently as 422 normal RBridges. These Smart-Hellos could be periodically unicast to 423 the Appointed Forwarder RB1 through native RBridge Channel messages. 424 In case RB1 crashes and restarts, or the DRB changes and SE1 receives 425 the Smart-Hello without mentioning SE1, SE1 SHOULD send a Smart-Hello 426 immediately. If RB1 is Appointed Forwarder for any of the VLANs that 427 SE1 claims, RB1 MUST list SE1 in its Smart-Hellos as a Smart Endnode 428 neighbor. 430 5.2. Data Packet Processing for Edge RBridge 432 The attached edge RBridge processes and forwards TRILL Data packets 433 based on the endnode property rather than for encapsulation and 434 forwarding the native frames the same way as the traditional 435 RBridges. There are several situations for the edge RBridges as 436 follows: 438 o If receiving an encapsulated unicast TRILL Data packet from a port 439 with a Smart Endnode, with RB1's nickname as ingress, the edge 440 RBridge RB1 forwards the frame to the specified egress nickname, 441 as with any encapsulated frame. However, RB1 MAY filter the 442 encapsulation frame based on the inner source MAC and Data Label 443 as specified for the Smart Endnode. If the MAC (or Data Label) 444 are not among the expected entries of the Smart Endnode, the frame 445 would be dropped by the edge RBridge. 447 o If receiving a unicast TRILL Data packet with RB1's nickname as 448 egress from the TRILL campus, and the destination MAC address in 449 the enclosed packet is listed as "smart endnode", RB1 leaves the 450 packet encapsulated when forwarding to the smart endnode, and both 451 the outer and inner Ethernet destination MAC is the destination 452 smart endnod's MAC address, and the outer Ethernet source MAC 453 address is the RB1's port MAC address. The edge RBridge still 454 decreases the Hop count value by 1, for there is one hop between 455 the RB1 and Smart Endnode. 457 o If receiving an multi-destination TRILL Data packet from a port 458 with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation 459 to the TRILL campus based on the distribution tree indicated by 460 the egress nickname. If the egress nickname does not correspond 461 to a distribution tree, the packet is discarded. If there are any 462 normal endnodes (i.e, non-Smart Endnodes) attached to the edge 463 RBridge RB1, RB1 decapsulates the frame and sends the native frame 464 to these ports possibly pruned based on multicast listeners, in 465 addition to forwarding the multi-destination TRILL frame to the 466 rest of the campus. 468 o When RB1 receives a multi-destination TRILL Data packet from a 469 remote RBridge, and the exit port includes hybrid endnodes(Smart 470 Endnodes and non-Smart Endnodes), it sends two copies of multicast 471 frames out the port, one as native and the other as TRILL 472 encapsulated frame. When Smart Endnode receives multi-destination 473 TRILL Data packet, it learns the remote (MAC address, Data Label, 474 Nickname) entry, A Smart Endnodes ignores native data frames. A 475 normal (non-smart) endnode receives the native frame and learns 476 the remote MAC address and ignores the TRILL data packet. This 477 transit solution may bring some complexity for the edge RBridge 478 and waste network bandwidth resource, so avoiding the hybrid 479 endnodes scenario by attaching the Smart Endnodes and non-Smart 480 Endnodes to different ports is RECOMMENDED. Another solution is 481 that if there are one or more endnodes on a link, the non-Smart 482 Endnodes are ignored on a link; but we can configure a port to 483 support mixed links. If RB1 is configured that the link is "Smart 484 Endnode only", then it will only send and receive TRILL- 485 encapsulated frames on that link. If it is configured to "non- 486 smart-endnodes only" on a port, it will only send and receive 487 native frames from that port. 489 6. Multi-homing Scenario 491 Multi-homing is a common scenario for the Smart Endnode. The Smart 492 Endnode is on a link attached to the TRILL domain in two places: to 493 edge RBridge RB1 and RB2. Take the figure below as example. The 494 Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 495 separately. Both RB1 and RB2 could announce their nicknames to SE1. 497 . ..................... 498 . +------+ . 499 . | RB1 | . 500 . /+------+ . 501 +----------+ ./ +-----+ . +----------+ 502 |SE1(Smart |/. | RB3 |......| Smart | 503 | Endnode1)| .\ +-----+ . | Endnode2 | 504 +----------+ . \ . +----------+ 505 . +-----+ . 506 . | RB2 | TRILL . 507 . +-----+ Domain . 508 ....................... 510 Figure 5 Multi-homing Scenario 512 There are several solutions for this scenario: 514 (1) Smart Endnode SE1 can choose either RB1 or RB2's nickname, when 515 encapsulating a frame, whether the encapsulated frame is sent 516 via RB1 or RB2. If SE1 uses RB1's nickname, in this scenario, 517 SE1 will encapsulate with TRILL ingress nickname RB1 when 518 transmitting on either port. This is simple, but means that all 519 return traffic will be via RB1. If Smart Endnode SE1 wants to 520 do active-active load splitting, and uses RB1's nickname when 521 forwarding through RB1, and RB2's nickname when forwarding 522 through RB2, this will cause MAC flip-flopping(see [RFC7379]) of 523 the endnode table entry in the remote RBridges (or Smart 524 Endnodes). One solution is to set a multi- homing bit in the 525 RSV field of the TRILL data packet. When remote RBridge RB3 or 526 Smart Endnodes receives a data packet with the multi-homed bit 527 set, the endnode entries (SE1's MAC address, label, RB1's 528 nickname) and (SE1's MAC address, label, RB2's nickname) will 529 coexist as endnode entries in the remote RBridge. Another 530 solution is to use the ESADI protocol to distribute multiple 531 attachments of a MAC address of a multi-homing group (See 532 section 5.3 of [RFC7357]). 534 (2) RB1 and RB2 might indicate, in their Smart-Hellos, a virtual 535 nickname that attached end nodes may use if they are multihomed 536 to RB1 and RB2, separate from RB1 and RB2's nicknames (which 537 they would also list in their Smart-Hellos). This would be 538 useful if there were many end nodes multihomed to the same set 539 of RBridges. This would be analogous to a pseudonode nickname; 540 return traffic would go via the shortest path from the source to 541 the endnode, whether it is RB1 or RB2. If Smart Endnode SE1 542 loses connectivity to RB2, then SE1 would revert to using RB1's 543 nickname. In order to avoid RPF check issue for multi- 544 destination frame, the affinity TLV [RFC7783] could be used in 545 this solution. 547 7. Security Considerations 549 Smart-Hellos can be secured by using Authentication TLVs based on 550 [RFC5310]. 552 For general TRILL Security Considerations, see [RFC6325]. 554 For native RBridge channel Security Considerations, see [RFC7178]. 556 8. IANA Considerations 558 IANA is requested to allocate an RBridge Channel Protocol number 559 (0x005 suggested) to indicate a Smart-Hello frame and update the 560 "RBridge Channel Protocols" registry as follows. 562 +-------------+--------------+------------------+ 563 | Protocol | Description | Reference | 564 +-------------+--------------+------------------+ 565 | TBD[0x005] | Smart-Hello | [this document] | 566 +-------------+--------------+------------------+ 568 Table 1 570 IANA is requested to allocate APPsub-TLV type numbers for the Smart- 571 MAC and Smart-Parameters APPsub-TLVs from the range below 256 and 572 update the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 573 Identifier 1" registry as follows. 575 +-----------+--------------+------------------+ 576 | Protocol | Description | Reference | 577 +-----------+--------------+------------------+ 578 | TBD1 | Smart-Hello | [this document] | 579 | TBD2 | Smart-MAC | [this document] | 580 +-----------+--------------+------------------+ 582 Table 2 584 9. Acknowledgements 586 The contributions of the following persons are gratefully 587 acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, and Andrew Qu. 589 10. References 591 10.1. Informative References 593 [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 594 Gashinsky, "Directory Assistance Problem and High-Level 595 Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 596 2013, . 598 [RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 599 "Problem Statement and Goals for Active-Active Connection 600 at the Transparent Interconnection of Lots of Links 601 (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 602 2014, . 604 10.2. Normative References 606 [IS-IS] ISO/IEC 10589:2002, Second Edition,, "Intermediate System 607 to Intermediate System Intra-Domain Routing Exchange 608 Protocol for use in Conjunction with the Protocol for 609 Providing the Connectionless-mode Network Service (ISO 610 8473)", 2002. 612 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 613 and M. Fanto, "IS-IS Generic Cryptographic 614 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 615 2009, . 617 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 618 Ghanwani, "Routing Bridges (RBridges): Base Protocol 619 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 620 . 622 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and 623 D. Dutt, "Transparent Interconnection of Lots of Links 624 (TRILL): Fine-Grained Labeling", RFC 7172, 625 DOI 10.17487/RFC7172, May 2014, 626 . 628 [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 629 D., and A. Banerjee, "Transparent Interconnection of Lots 630 of Links (TRILL) Use of IS-IS", RFC 7176, 631 DOI 10.17487/RFC7176, May 2014, 632 . 634 [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 635 Ward, "Transparent Interconnection of Lots of Links 636 (TRILL): RBridge Channel Support", RFC 7178, 637 DOI 10.17487/RFC7178, May 2014, 638 . 640 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 641 Stokes, "Transparent Interconnection of Lots of Links 642 (TRILL): End Station Address Distribution Information 643 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 644 September 2014, . 646 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 647 Ghanwani, A., and S. Gupta, "Transparent Interconnection 648 of Lots of Links (TRILL): Clarifications, Corrections, and 649 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 650 . 652 [RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, 653 "Coordinated Multicast Trees (CMT) for Transparent 654 Interconnection of Lots of Links (TRILL)", RFC 7783, 655 DOI 10.17487/RFC7783, February 2016, 656 . 658 Authors' Addresses 660 Radia Perlman 661 EMC Corporation 662 2010 156th Ave NE, suite #200 663 Bellevue, WA 98007 664 USA 666 Phone: +1-206-291-367 667 Email: radiaperlman@gmail.com 669 Fangwei Hu 670 ZTE Corporation 671 No.889 Bibo Rd 672 Shanghai 201203 673 China 675 Phone: +86 21 68896273 676 Email: hu.fangwei@zte.com.cn 678 Donald Eastlake,3rd 679 Huawei technology 680 155 Beaver Street 681 Milford, MA 01757 682 USA 684 Phone: +1-508-634-2066 685 Email: d3e3e3@gmail.com 687 Kesava Vijaya Krupakaran 688 Dell 689 Olympia Technology Park 690 Guindy Chennai 600 032 691 India 693 Phone: +91 44 4220 8496 694 Email: Kesava_Vijaya_Krupak@Dell.com 695 Ting Liao 696 ZTE Corporation 697 No.50 Ruanjian Ave. 698 Nanjing, Jiangsu 210012 699 China 701 Phone: +86 25 88014227 702 Email: liao.ting@zte.com.cn