idnits 2.17.1 draft-zhang-trill-multilevel-single-nickname-00.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 (March 9, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '256' on line 327 -- Looks like a reference, but probably isn't: '257' on line 328 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Donald Eastlake 4 Huawei 5 Radia Perlman 6 EMC 7 Expires: September 10, 2015 March 9, 2015 9 Single Area Border RBridge Nickname for TRILL Multilevel 10 draft-zhang-trill-multilevel-single-nickname-00.txt 12 Abstract 14 A major issue in multilevel TRILL is how to manage RBridge nicknames. 15 In this document, the area border RBridge uses a single nickname in 16 both Level 1 and Level 2. RBridges in Level 2 must obtain unique 17 nicknames but RBridges in different Level 1 areas may have the same 18 nicknames. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 59 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Nickname Handling on Border RBridges . . . . . . . . . . . . . 3 62 3.1. Actions on Unicast Packets . . . . . . . . . . . . . . . . 3 63 3.2. Actions on Multi-Destination Packets . . . . . . . . . . . 4 64 4. Per-flow Load Balancing . . . . . . . . . . . . . . . . . . . . 5 65 5. Protocol Extensions for Discovery . . . . . . . . . . . . . . . 5 66 5.1. Discovery of Border RBridges in L1 . . . . . . . . . . . . 6 67 5.2. Discovery of Border RBridge Sets in L2 . . . . . . . . . . 6 68 6. E-L1FS/E-L2FS Backwards Compatibility . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. TRILL APPsub-TLVs . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 TRILL multilevel techniques are designed to improve TRILL scalability 80 issues. As described in [MultiL], there have been two proposed 81 approaches. One approach, which is referred as the "unique nickname" 82 approach, gives unique nicknames to all the TRILL switches in the 83 multilevel campus, either by having the Level-1/Level-2 border TRILL 84 switches advertise which nicknames are not available for assignment 85 in the area, or by partitioning the 16-bit nickname into an "area" 86 field and a "nickname inside the area" field. The other approach, 87 which is referred as the "aggregated nickname" approach, involves 88 assigning nicknames to the areas, and allowing nicknames to be reused 89 in different areas, by having the border TRILL switches rewrite the 90 nickname fields when entering or leaving an area. 92 The approach specified in this document is different from both 93 "unique nickname" and "aggregated nickname" approach. In this 94 document, the nickname of an area border RBridge is used in both 95 Level 1 (L1) and Level 2 (L2). No additional nicknames are assigned 96 to the L1 areas. Each L1 area is denoted by the group of all 97 nicknames of those border RBridges of the area. For this approach, 98 nicknames in L2 MUST be unique but nicknames inside different L1 99 areas MAY be reused. 101 2. Acronyms and Terminology 103 2.1. Acronyms 105 Data Label: VLAN or FGL 107 IS-IS: Intermediate System to Intermediate System [ISIS] 109 2.2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 Familiarity with [RFC6325] is assumed in this document. 117 3. Nickname Handling on Border RBridges 119 This section provides an illustrative example and description of the 120 border learning border RBridge nicknames. 122 Area {2,20} level 2 Area {3,30} 123 +-------------------+ +-----------------+ +--------------+ 124 | | | | | | 125 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 126 | 27 | | | | 44 | 127 | ----RB20--- ----RB30--- | 128 +-------------------+ +-----------------+ +--------------+ 130 Figure 3.1: An example topology for TRILL multilevel 132 In Figure 3.1, RB2, RB20, RB3 and RB30 are area border TRILL switches 133 (RBridges). Their nicknames are 2, 20, 3 and 30 respectively. Area 134 border RBridges use the set of border nicknames to denote the L1 area 135 that they are attached to. For example, RB2 and RB20 use nicknames 136 {2,20} to denote the L1 area on the left. 138 A source S is attached to RB27 and a destination D is attached to 139 RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 140 (and in fact, they could even have the same nickname, since the TRILL 141 switch nickname will not be visible outside these Level 1 areas). 143 3.1. Actions on Unicast Packets 144 Let's say that S transmits a frame to destination D and let's say 145 that D's location is learned by the relevant TRILL switches already. 146 These relevant switches have learned the following: 148 1) RB27 has learned that D is connected to nickname 3. 149 2) RB3 has learned that D is attached to nickname 44. 151 The following sequence of events will occur: 153 - S transmits an Ethernet frame with source MAC = S and destination 154 MAC = D. 156 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 157 and egress RBridge = 3 producing a TRILL Data packet. 159 - RB2 and RB20 have announced in the Level 1 IS-IS instance in area 160 {2,20}, that they are attached to all those area nicknames, 161 including {3,30}. Therefore, IS-IS routes the packet to RB2 (or 162 RB20, if RB20 on the least-cost route from RB27 to RB3). 164 - RB2, when transitioning the packet from Level 1 to Level 2, 165 replaces the ingress TRILL switch nickname with its own nickname, 166 so replaces 27 with 2. Within Level 2, the ingress RBridge field 167 in the TRILL header will therefore be 2, and the egress RBridge 168 field will be 3. Also RB2 learns that S is attached to nickname 27 169 in area {2,20} to accommodate return traffic. RB2 SHOULD 170 synchronize with RB20 that MAC = S is attached to nickname 27. 172 - The packet is forwarded through Level 2, to RB3, which has 173 advertised, in Level 2, its L2 nickname as 3. 175 - RB3, when forwarding into area {3,30}, replaces the egress 176 nickname in the TRILL header with RB44's nickname (44). The 177 ingress nickname MAY be replaced with an area nickname selected 178 from {2,20}. See Section 4 for the detail of the selection method. 179 Suppose nickname 2 is selected. So, within the destination area, 180 the ingress nickname will be 2 and the egress nickname will be 44. 182 - RB44, when decapsulating, learns that S is attached to nickname 2, 183 which is one of the area nicknames of the ingress. 185 3.2. Actions on Multi-Destination Packets 187 Now suppose that D's location has not been learned by RB27 and/or 188 RB3. What will happen, as it would in TRILL today, is that RB27 will 189 forward the packet as multi-destination, choosing a tree. As the 190 multi-destination packet transitions into Level 2, RB2 replaces the 191 ingress nickname with its own nickname for the area. If RB27 does not 192 know the location of D, the packet must be flooded, subject to 193 possible pruning, in Level 2 and, subject to possible pruning, from 194 Level 2 into every Level 1 area that it reaches on the Level 2 195 distribution tree. There may be multiple eligible border RBridges for 196 this area to transit the multi-destination packets from Level 2 to a 197 Level 1. It's important that these area border RBridges agree on an 198 election method to determine who is the Designated Boarder RBridge 199 (DBRB) for the transition, otherwise RBridges in this area will see 200 packet duplication. It's RECOMMNEDED that the pseudorandom algorithm 201 as defined in Section 5.3 of [RFC7357] is used as the election 202 method. 204 Now suppose that RB27 has learned the location of D (attached to 205 nickname 3), but RB3 does not know where D is. In that case, RB3 must 206 turn the packet into a multi-destination packet within area {3,30}. 207 In this case, care must be taken so that, another border TRILL switch 208 in that area not forward the now multi-destination packet back into 209 Level 2. Therefore, it would be desirable to have a marking, somehow, 210 that indicates the scope of this packet's distribution to be "only 211 this area" (see also Section 4 of [MultiL]). 213 4. Per-flow Load Balancing 215 When a packet from other areas arrives at an area border RBridge, 216 this RBridge MAY select one area nickname of the ingress to replace 217 the ingress nickname of the packet. The selection is simply based on 218 a pseudorandom algorithm as defined in Section 5.3 of [RFC7357]. With 219 the random ingress nickname replacement, the border RBridge actually 220 achieves a per-flow load balance for returning traffic. 222 All area border RBridges in an L1 area MUST agree on the same 223 pseudorandom algorithm. The source MAC address, ingress area 224 nicknames, egress area nicknames and the Data Label are candidate 225 factors of the input of this pseudorandom algorithm. Note that the 226 value of the destination MAC address SHOULD be excluded from the 227 input of this pseudorandom algorithm, otherwise the egress RBridge 228 will see one source MAC address flip flopping among multiple ingress 229 RBridges. 231 When a packet originated from an area arrives at the area border 232 RBridge, this RBridge MAY select one area nickname of the egress to 233 replace the egress nickname of the packet. By default, it SHOULD 234 choose the egress area border RBridge with the least cost route to 235 reach. The pseudorandom algorithm as defined in Section 5.3 of 236 [RFC7357] may be used as well. In that case, however, the ingress 237 area border RBridge may take the non-least-cost Level 2 route to 238 forward the TRILL data packet to the egress area border RBridge. 240 5. Protocol Extensions for Discovery 242 5.1. Discovery of Border RBridges in L1 244 The following Level 1 Border RBridge APPsub-TLV will be included in 245 an E-L1FS FS-LSP fragment zero [RFC7180bis] as an APPsub-TLV of the 246 TRILL GENINFO-TLV. Through listening to this Appsub-TLV, an area 247 border RBridge discovers all other area border RBridges in this area. 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = L1-BORDER-RBRIDGE | (2 bytes) 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Length | (2 bytes) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Sender Nickname | (2 bytes) 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) 259 o Length: 2 261 o Sender Nickname: The nickname the originating IS will use as the 262 L1 Border RBridge nickname. This field is useful because the 263 originating IS might own multiple nicknames. 265 5.2. Discovery of Border RBridge Sets in L2 267 The following APPsub-TLV will be included in an E-L2FS FS-LSP 268 fragment zero [RFC7180bis] as an APPsub-TLV of the TRILL GENINFO-TLV. 269 Through listening to this APPsub-TLV in L2, an area border RBridge 270 discovers all groups of L1 border RBridges and each such group 271 identifies an area. 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type = L1-BORDER-RB-GROUP | (2 bytes) 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Length | (2 bytes) 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | L1 Border RBridge Nickname 1 | (2 bytes) 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | ... | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | L1 Border RBridge Nickname k | (2 bytes) 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) 287 o Length: 2*k. If length is not a multiple of 2, the APPsub-TLV is 288 corrupt and MUST be ignored. 290 o L1 Border RBridge Nickname: The nickname that an area border 291 RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- 292 GROUP TLV generated by an area border RBridge MUST include all L1 293 Border RBridge nicknames of the area. It's RECOMMENDED that these 294 k nicknames are ordered in ascending order according to the 2- 295 octet nickname considered as an unsigned integer. 297 6. E-L1FS/E-L2FS Backwards Compatibility 299 All Level 2 RBridges MUST support E-L2FS [RFC7356] [rfc7180bis]. The 300 Extended TLVs defined in Section 5 are to be used in Extended Level 301 1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 302 support both E-L1FS and E-L2FS. RBridges that do not support either 303 E-L1FS or E-L2FS cannot serve as area border RBridges but they can 304 well appear in an L1 area acting as non-area-border RBridges. 306 7. Security Considerations 308 For general TRILL Security Considerations, see [RFC6325]. 310 The newly defined TRILL APPsub-TLVs in Section 5 are transported in 311 IS-IS PDUs whose authenticity can be enforced using regular IS-IS 312 security mechanism [ISIS][RFC5310]. This document raises no new 313 security issues for IS-IS. 315 8. IANA Considerations 317 8.1. TRILL APPsub-TLVs 319 IANA is requested to allocate two new types under the TRILL GENINFO 320 TLV [RFC7357] for the TRILL APPsub-TLVs defined in Section 5. The 321 following entries are added to the "TRILL APPsub-TLV Types under IS- 322 IS TLV 251 Application Identifier 1" Registry on the TRILL Parameters 323 IANA web page. 325 Type Name Reference 326 --------- ---- --------- 327 tbd1[256] L1-BORDER-RBRIDGE [This document] 328 tbd2[257] L1-BORDER-RB-GROUP [This document] 330 9. References 332 9.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 338 Ghanwani, "Routing Bridges (RBridges): Base Protocol 339 Specification", RFC 6325, July 2011. 341 [RFC7356] L. Ginsberg, S. Previdi, et al, "IS-IS Flooding Scope 342 LSPs", RFC 7356, June 2014. 344 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 345 Stokes, "Transparent Interconnection of Lots of Links 346 (TRILL): End Station Address Distribution Information 347 (ESADI) Protocol", RFC 7357, September 2014. 349 9.2. Informative References 351 [ISIS] ISO, "Intermediate system to Intermediate system routeing 352 information exchange protocol for use in conjunction with 353 the Protocol for providing the Connectionless-mode Network 354 Service (ISO 8473)", ISO/IEC 10589:2002. 356 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 357 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 358 RFC 5310, February 2009. 360 [RFC7180bis] D. Eastlake, M. Zhang, et al, "TRILL: Clarifications, 361 Corrections, and Updates", draft-eastlake-trill-rfc7180bis, 362 work in progress. 364 [MultiL] Perlman, R., Eastlake, D., et al, "Flexible Multilevel 365 TRILL", draft-perlman-trill-rbridge-multilevel, work in 366 progress. 368 Author's Addresses 370 Mingui Zhang 371 Huawei Technologies 372 No.156 Beiqing Rd. Haidian District, 373 Beijing 100095 P.R. China 375 EMail: zhangmingui@huawei.com 377 Donald E. Eastlake, 3rd 378 Huawei Technologies 379 155 Beaver Street 380 Milford, MA 01757 USA 382 Phone: +1-508-333-2270 383 EMail: d3e3e3@gmail.com 385 Radia Perlman 386 EMC 387 2010 256th Avenue NE, #200 388 Bellevue, WA 98007 USA 390 EMail: radia@alum.mit.edu