idnits 2.17.1 draft-tissa-trill-multilevel-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Above Figure 1 depicts a sample Topology, Figure 2 depicts the corresponding logical topology. Local multicast trees and the global multicast trees have the same nickname "t". "X" denote the branches of the multicast tree that are not used for multicast traffic reception or transmission. L1 RBridges, RB1, RB7 install RPF check based on the default Affinity TLV. L1 area border RBridges MUST not install the default RPF check on L2 interfaces, instead they MUST honor the Area Affinity TLV and install explicit RPF checks. Strict RPF check on area border RBridges are mandatory to prevent transient loops during topology changes. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RB6 accepts the incoming multicast frame along tree "t" with the ingress RBridge nickname RB1 and performs applicable forwarding to locally attached ports. RB6, which is a non RP for tree "t" for area A2, MUST not forward the multicast frame to the global tree "t". == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Dynamic ranges are derived by the area border RBridges based on the local nickname ranges of its and other areas. As an example let's assume area A1 has local nickname range of 100-200, A2 has a local nickname range of 201-300. Then the dynamic range is from 1-99 and 301 to 65471 (0xFFBF). Nickname values 0 and 0xFFC0 to 0xFFFF are reserved and MUST not be included in the dynamic nickname ranges. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Each RBridge announces two sets of capabilities; global tree capabilities and local tree capabilities. It announces, maximum number of global distributions trees it can compute. RBridges utilize Global Tree sub-TLV for the purpose of announcing its global tree capability. RBridges announce local tree capabilities using The Tree sub-TLV [RFC6326]. Global tree space is disjoint from the local tree space and MUST not have any effect on each other. Please refer to [RFC6325] for the process of how local trees are derived. In this section we present how the total number of global trees needed is calculated and identification of nickname of each tree root. -- The document date (May 28, 2013) is 3976 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: 'RFC 6326' is mentioned on line 218, but not defined ** Obsolete undefined reference: RFC 6326 (Obsoleted by RFC 7176) == Unused Reference: 'RFC2234' is defined on line 957, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft Les Ginsberg 3 Intended status: Standard Track CISCO 4 Sam Aldrin 5 HuaWei 6 Ayan Banerjee 7 CISCO 9 May 28, 2013 10 Expires: November 2013 12 Default Nickname Based Approach for Multilevel TRILL 13 draft-tissa-trill-multilevel-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 28, 2009. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Multilevel TRILL allows the interconnection of multiple TRILL 56 networks to form a larger TRILL network without proportionally 57 increasing the size of the IS-IS LSP DB. In this document, an 58 approach based on default route concept is presented. Also, 59 presented in the document is a novel method of constructing multi- 60 destination trees using partial nickname space. Methods presented in 61 this document are compatible with the RFC6325 specified data plane 62 operations. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Conventions used in this document..............................4 68 3. Solution Overview..............................................4 69 4. Operational Overview...........................................5 70 4.1. Unicast Forwarding........................................5 71 4.2. IS-IS Protocol changes for unicast forwarding.............5 72 4.3. MAC Address Learning......................................5 73 4.4. Multicast.................................................6 74 4.5. Life of Multicast frame...................................9 75 5. Area Affinity sub-TLV.........................................10 76 6. Nickname acquisition and conflict resolution..................11 77 6.1. Nickname Management sub-TLV..............................13 78 7. Further optimizations.........................................14 79 7.1. Leaking of TRILL IS-IS sub-TLV within areas..............14 80 7.2. Identification of Global Trees...........................15 81 7.2.1. Global Tree capability sub-TLV......................17 82 7.2.2. Global Tree proposal sub-TLV........................17 83 7.2.3. Global Tree Identifier sub-TLV......................18 84 7.3. Announcing Group Addresses...............................18 85 8. Architecture Elements of Multi-level Multicast framework......21 86 8.1. Bootstrap RBridge........................................21 87 8.2. Rendezvous Point (RP)....................................22 88 8.3. Default Affinity sub-TLV.................................22 89 8.4. Area Affinity sub-TLV....................................22 90 8.5. TRILL BSR Protocol.......................................22 91 9. Security Considerations.......................................22 92 10. IANA Considerations..........................................23 93 11. References...................................................23 94 11.1. Normative References....................................23 95 11.2. Informative References..................................23 96 12. Acknowledgments..............................................24 98 1. Introduction 100 The TRILL Base Protocol Specification [RFC6325] provides a method 101 for forwarding Layer 2 data frames over multiple active links, 102 thereby optimizing network bandwidth and resiliency. TRILL requires 103 native Layer 2 frames to be encapsulated with the TRILL header. 104 TRILL devices (RBridges) are identified with a 16 bit identifier 105 called a nickname. The TRILL header contains egress and ingress 106 RBridge nicknames. Intermediate RBridges performs forwarding based 107 on the egress nickname. TRILL utilize the IS-IS protocol to 108 distribute RBridge nicknames. 110 TRILL Base Protocol Specification [RFC6325] specifies a tree based 111 paradigm to forward broadcast and multicast traffic as well as 112 unknown unicast traffic. 114 Traditional Layer 2 devices perform forwarding based on MAC 115 addresses. As a result, in theory, all of the devices in the network 116 are required to learn all of the MAC addresses in the Layer 2 117 domain. This leads to very large forwarding table sizes in the 118 devices which limits the size of the layer 2 domain. Forwarding 119 within the TRILL network occurs not based on MAC addresses but based 120 on the RBridge nicknames. Hence, TRILL based networks have 121 significant potential to be the core forwarding plane of very large 122 datacenters. 124 Large datacenters are often multisite in nature and contain a large 125 number of RBridges. TRILL is designed to be a single IS-IS area. As 126 the size of the TRILL network grows, the size of the IS-IS LSP 127 database grows, leading to network convergence delays and increased 128 volatility during transient conditions such as link flaps. 130 As mentioned above TRILL utilizes a tree based forwarding paradigm 131 for multi-destination traffic. In large TRILL networks this may lead 132 to sub-optimal forwarding. Additionally, entire network wide 133 multicasting may lead to network bandwidth inefficiencies and have a 134 negative impact on performance. 136 In order to support scaling and performance of large TRILL networks, 137 it is important to have methods to: 139 1. Limit the size of the IS-IS LSP database 140 2. Optimize multicast forwarding 141 3. Limit the scope of flooding and broadcast traffic 143 In this document we propose methods that allow implementing multi- 144 level TRILL without any data plane changes as well as meet the above 145 design goals. 147 Also presented in this document is a novel method of constructing 148 multi-destination trees using partial nickname space. 150 2. Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC-2119 [RFC2119]. 156 In this document, these words will appear with that interpretation 157 only when in ALL CAPS. Lower case uses of these words are not to be 158 interpreted as carrying RFC-2119 significance. 160 3. Solution Overview 162 Herein we present a high level view of the proposed solution; 163 differing the details of the solution to subsequent sections. 165 The TRILL campus is divided in to multiple IS-IS L1 Areas 166 interconnected by L2 backbone area. The backbone area may be inter- 167 connected by an IS-IS K2 area or by some other means. For example, 168 one does not preclude a configuration based approach for the L2 169 backbone. 171 Area border RBridges indicate their ability to reach other areas by 172 setting the Attach bit in IS-IS Link State PDU. 174 RBridges forward frames destined to RBridges in the area using the 175 exact match of nicknames. Frames destined to RBridges outside of the 176 L1 area are forwarded using the default route advertised by the area 177 border RBridges. 179 Campus wide Multi-destination trees are partitioned in to two parts. 180 A backbone tree rooted on the L2 backbone and local trees rooted 181 within each L1 area. For campus wide trees the local trees and the 182 backbone tree have the same nickname. This avoids the need for 183 egress RBridge nickname translation at the border RBridges). 185 One of the border RBridges performs connecting its local tree to the 186 corresponding backbone tree. The Affinity sub-TLV and Area Affinity 187 sub-TLV information facilitate constructing proper RPF states. 189 4. Operational Overview 191 4.1. Unicast Forwarding 193 The TRILL campus is divided in to multiple IS-IS L1 Areas with a 194 Layer 2 backbone. (Figure 1). 196 The "Attached" bit in IS-IS PDU is used to indicate the advertising 197 IS connected to other areas. In this document we propose to leverage 198 the "Attached" bit to identify the border RBRidges and forward 199 traffic for all un-resolved nicknames to the border RBridges. 201 Border RBridges possess the complete nickname space of the TRILL 202 campus. Utilizing this information, ingress area border RBRidge 203 forward TRILL frames to the egress area border RBridge via the L2 204 backbone. 206 Egress area border RBridges, forward the frame normally to the 207 intended destination in the given L1 Area. 209 4.2. IS-IS Protocol changes for unicast forwarding 211 Support for non zero IS-IS areas for TRILL. 213 No new TLV or sub-TLV required. 215 Border RBridges advertise LSP with the "Attached" bit set 217 L1 Area RBridges are required to advertise TRILL related sub-TLV 218 defined in [RFC 6326] with the router capability bit "S" set. The 219 capability bit "D" MUST be set to zero (0). This allows leaking L1 220 PDU to the L2 backbone area but not to other L1 areas [RFC4971]. 222 4.3. MAC Address Learning 224 Egress RBridge learn remote MAC addresses against the actual 225 nickname of the ingress RBRidge. 227 As an example: Let's Assume MAC address A is attached to RB1 and MAC 228 address B is attached to RB7. 230 RB1 receives a frame destined to MAC B. RB1 does not know the 231 location of MAC B. However, local policy such as, port or VLAN 232 indicates that the frame is of global scope. RB1 transmits the frame 233 on global tree "t" as an unknown unicast frame. 235 RB7 receives the frame and learn MAC A is associated with RB1. RB7 236 programs its forwarding tables such that MAC-A is associated with 237 RB1. It also forwards the frame to MAC-B. 239 MAC-B responds. RB7 has the association of MAC-A to RB1. Hence, RB7 240 forwards the frame to RB1 as a unicast frame, with egress RBridge 241 nickname as RB1 and ingress RBridge nickname as RB7. 243 The frame follows the normal uicast forwarding process explained 244 above and arrives at RB1. RB1, learns the MAC-B association to RB7 245 and updates its forwarding tables accordingly. Also, RB1 forwards 246 the frame to MAC-A. 248 4.4. Multicast 250 Multicast forwarding has two parts: 1. Construction of the multicast 251 trees 2. RPF (Reverse Path Forwarding) check. 253 In most of the real world deployments, not all of the traffic is 254 required or desired to span across the entire TRILL campus. The 255 majority of the traffic tends to have a local scope and some subset 256 of traffic to have a global scope. 258 The scope of global traffic may be identified either through VLAN or 259 via finegrain label that spans across the entire TRILL campus. 261 In this document we propose to classify TRILL multi-destination 262 trees into two types: 264 1. Local trees (trees that have a scope within the local area) 265 2. Global trees (trees that have a scope throughout the TRILL campus) 267 Multi-destination traffic of local scope is forwarded using Local 268 trees. Multi-destination traffic of global scope is forwarded using 269 global trees. 271 Construction of global multi-destination trees and performing RPF 272 check for such trees requires knowledge of all of the RBridges in 273 the entire TRILL campus. In a large TRILL campus, construction of 274 such global trees that need information of all RBridges may not only 275 lack scalability but also may run in to instabilities during network 276 changes. Additionally, when the TRILL campus is divided into 277 multiple IS-IS L1 areas, RBridges within an L1 areas do not possess 278 reachability information for other areas. Thus, constructing such 279 global trees may not be possible. 281 In this document we propose an [RFC6325] compatible approach of 282 building multicast trees to address the issues mentioned above. 284 In the proposed method, global trees (campus wide trees) are 285 partitioned in to two instances; a backbone tree instance and set of 286 local tree instance per each area. 288 Backbone tree - An instance of the tree rooted in the L2 backbone. 289 The Backbone tree is represented by the same nickname as the global 290 tree. 292 Local tree - An instance of a tree per area, per campus wide tree, 293 rooted within each area. Each instance of the tree in each area is 294 represented by the same nickname as the global tree. (This is 295 important to avoid the need for tree translation at the border 296 RBridges) 298 L2 LSPs advertise the backbone tree. 300 L1 LSPs advertise the corresponding local-tree within each area. 302 One of the L1-L2 area border RBridges in an given area is assigned 303 the role of Rendezvous Point (RP) for the specific local tree (more 304 details are presented in section 8. ). 306 Each RP functions as the plumb between the global tree and local 307 tree. Both the trees have exactly the same nickname. 309 RP An RP advertises affinity to the rest of the campus for the 310 specified tree by using the Affinity sub-TLV [trillcmt]. In the 311 Affinity TLV associated nickname MUST be specified as zero to 312 indicate the Affinity is related to default route. We refer to this 313 usage of Affinity TLV as the default Affinity sub-TLV in the rest of 314 the document. 316 Each RBridge in the local L1 area builds its multi-destination SPF 317 tree as specified in [RFC6325] and [trillcmt]. RPF checks are 318 performed as specified in [RFC6325] and [trillcmt]. Additionally, 319 RPF checks for default nicknames (i.e. all unknown nicknames to the 320 local L1 area) are performed per the association specified by the 321 default Affinity sub-TLV. 323 Additionally, each RP on behalf of the local Area it is representing 324 for multi-cast tree Tx, advertises Area Affinity-TLV towards the L2 325 backbone area. The Area Affinity TLV, include the L1 Area ID of the 326 associated area. The Area Affinity TLV, notifies RBridges in the L2 327 area to enable the RPF check to accept nicknames in the associated 328 L1 area from the announcing RP. The Area Affinity TLV allows greater 329 scaling of the IS-IS LSP DB. If Affinity TLV contains all of the 330 nicknames the IS-IS PDU size increases. Use of the Area Affinity 331 sub-TLV to summarize the entire area in a single sub-TLV, limits the 332 size of the LSP DB as well as PDU size. (Please see below for the 333 structure of the Area Affinity sub-TLV). 335 L1 Area A1 L2 Backbone L1 Area A2 336 +------------------+ +----------------+ +-----------------+ 337 | RB2 | | RB5 | 338 | +---+ | | +---+ | 339 | o---o o---o o--o o--o | 340 | RB1 | | | | | | RB7 | 341 | +---+ +---+ | | +---+ +---+ | 342 |o-o | | | | | | | 343 | | o--o +---+ | | +---+ o--o o-o | 344 | +---+ | | | | | | +---+ | 345 | o---o o---o o--o o--o | 346 | +---+ | | +---+ | 347 | RB3 +----------------+ RB6 | 348 +-----------------+ +-----------------+ 350 Figure 1 Sample Topology 352 L1 Area A1 L2 Backbone L1 Area A2 353 +-------------------+ +----------------+ +-----------------+ 354 | - t - | | - t - | | t | 355 | | \ \ | | / | \ | | - |- | 356 | | \ \ | | / | \ / | \ | 357 | | \ ----o RB2 o---- /|\ ----o RB5 o-- | \ | 358 | | \ (RP) | / \ | (RP) / \ | 359 | o \ | | / \ | | / o | 360 | \- | | / \ | | / RB7 | 361 | RB1 ---o RB3 | / \ | / | 362 | X---o \ t----- | 363 | | | ----X RB6 | 364 +-------------------+ +----------------+ +----------------+ 366 -t- Tree root for tree t 367 --o Port that accept multicast traffic for the tree "t" 368 --X Ports that do not accept multicast traffic for the tree "t" 370 Figure 2 Logical Topology 372 Above Figure 1 depicts a sample Topology, Figure 2 depicts the 373 corresponding logical topology. Local multicast trees and the global 374 multicast trees have the same nickname "t". "X" denote the branches 375 of the multicast tree that are not used for multicast traffic 376 reception or transmission. L1 RBridges, RB1, RB7 install RPF check 377 based on the default Affinity TLV. L1 area border RBridges MUST not 378 install the default RPF check on L2 interfaces, instead they MUST 379 honor the Area Affinity TLV and install explicit RPF checks. Strict 380 RPF check on area border RBridges are mandatory to prevent transient 381 loops during topology changes. 383 4.5. Life of Multicast frame. 385 RB1 ingresses multicast frames of global scope to global tree "t". 386 The multicast frame traverses the tree "t" and arrives at RBridges 387 RB2 and RB3. RB2 is the Rendezvous Point (RP) for tree "t" for Area 388 A1. RB2 forward the frame to backbone multicast tree "t" as well as 389 to the other local ports. RB3 is not the RP for tree "t" for area 390 A1. Hence, it forwards the frame to local ports but does not forward 391 along the backbone multicast tree "t". 393 The multicast frame traverses along the backbone tree "t" and 394 arrives at Area A2 border RBridges RB5 and RB6. The RB6, which is 395 not the Rendezvous Point (RP) for backbone tree "t" for Area A2, 396 accepts multi-destination frames arriving on L2 interface and only 397 forwards to other applicable L2 interfaces. Non RP RBridges do not 398 forward multi-destination frames arriving on global tree on L1 area 399 interface. RB5, the RP for the Area A2 for the multicast tree "t", 400 contains the RPF check to accept frames from others areas on tree 401 "t" on its L2 area interface. Hence, RB5, accept the multicast frame 402 from tree "t" and forward along the local tree "t" and its local 403 ports. 405 The multicast packet traverses along the local tree "t" in Area A2 406 and arrive at RB7. RB7 contains RPF check installed based on the 407 Default Affinity TLV for tree "t", to receive multicast traffic for 408 tree "t" that arrives from the RP facing interface. RB7 accepts the 409 multicast frame arriving on local tree "t" with ingress RBridge 410 nickname RB1 and performs applicable forwarding as specified in 411 [RFC6325]. 413 RB6 is an Area border RBRidge for Area A2, but not RP for the area. 414 RB6 receives the multicast frame through the local tree "t". Non RP 415 area border RBridges for RPF and multi-destination forwarding 416 purposes function like a L1 area RBridge. RB6, honors the default 417 Affinity TLV received from RB5 for local multicast tree "t". Hence, 418 it installs RPF check to accept all nicknames (default nickname) for 419 tree "t" from the L1 Area interface pointing towards RB5. 421 RB6 accepts the incoming multicast frame along tree "t" with the 422 ingress RBridge nickname RB1 and performs applicable forwarding to 423 locally attached ports. RB6, which is a non RP for tree "t" for area 424 A2, MUST not forward the multicast frame to the global tree "t". 426 5. Area Affinity sub-TLV 428 Area Affinity sub-TLV is a sub-TLV under IS-IS Router capability TLV 429 and contains the following structure. 431 +-+-+-+-+-+-+-+-+ 432 |Type=AREA-AFF | (1 byte) 433 +-+-+-+-+-+-+-+-+ 434 | Length | (1 byte) 435 +---------------+ 436 | Area-ID-Length| (1 byte) 437 +---------------+---------------+ 438 | Area ID | (variable 1..13) 439 . . 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | number of trees | (2 bytes) 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |tree-num of 1st preferred root | (2 bytes) 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |tree-num of 2nd preferred root | (2 bytes) 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 . . 449 +-------------------------------+ 450 |tree-num of Nth preferred root | (2 bytes) 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 3 Area Affinity TLV structure 455 o Type: AREA-AFF, (TBD). 457 o Length: variable. Length is 1 + length of Area ID + 2*n, where 458 n is the number listed tree numbers. 460 o Area-ID : (variable length) Is the IS-IS Area ID. Length can be 461 1-13 bytes long. 463 o Number of trees : number of trees for which association 464 (affinity) being announced. 466 o Tree-num of preferred root: The tree Number of the multicast 467 tree. 469 Area-affinity conflicts MUST be resolved using methods specified 470 in [trillcmt]. 472 6. Nickname acquisition and conflict resolution 474 In the proposed method, nicknames of RBridges in remote L1 areas are 475 not advertised into the local L1 area by area border RBridges. 476 However, L2 backbone RBridges and L1-L2 border RBridges contain the 477 nicknames used by all the RBridges in the campus. We propose to 478 introduce a new IS-IS sub-TLV under Router capability TLV to 479 distribute available nickname space. New IS-IS sub TLV is Nickname 480 Management sub-TLV. 482 Nickname Management sub-TLV is announced by the area border RBridges 483 in to the local L1 area with Router capability bits D set to one and 484 S set to one. Nickname Management sub-TLV is announced in to L2 area 485 by the area border RBridges with S and D bit clear. These settings 486 ensure Nickname Management TLV is confined to the local L1 area L2 487 area and does not leak to other L1 areas. 489 Nickname Management sub-TLV instance announced in to the local area, 490 contains two sets of ranges. Local nickname ranges and dynamic 491 nickname ranges. Local nickname ranges are one or more sets of 492 ranges that network administrator has configured on the border 493 RBridges. Multiple local nickname ranges allow network administrator 494 to configure multiple sets of non contiguous nickname ranges. 496 L1 area RBridges SHOULD, first, select a nickname or nicknames from 497 the local ranges. 499 If entire local nickname space has exhausted (i.e. taken up by other 500 RBridges), then L1 are RBridges SHOULD select a nickname or 501 nicknames from the dynamic ranges. 503 It is recommended that RBridges use different nickname priorities to 504 differentiate nickname acquired by different methods. Nickname 505 priorities are assigned based on the acquisition method such that 506 configured nicknames have highest priority, followed by nicknames 507 derived from the local range, followed by nicknames derived from the 508 dynamic range. 510 Dynamic ranges are derived by the area border RBridges based on the 511 local nickname ranges of its and other areas. As an example let's 512 assume area A1 has local nickname range of 100-200, A2 has a local 513 nickname range of 201-300. Then the dynamic range is from 1-99 and 514 301 to 65471 (0xFFBF). Nickname values 0 and 0xFFC0 to 0xFFFF are 515 reserved and MUST not be included in the dynamic nickname ranges. 517 Nickname Management sub-TLV instance announced in to the L2 backbone 518 area, contains only the local nickname ranges. Local nickname ranges 519 of each area allow other areas to derive applicable dynamic ranges 520 to announce in to the corresponding L1 area. 522 6.1. Nickname Management sub-TLV 524 +-+-+-+-+-+-+-+-+ 525 |Type=NICK-MGMT | (1 byte) 526 +-+-+-+-+-+-+-+-+ 527 | Length | (1 byte) 528 +---------------+ 529 | Area-ID-Length| (1 byte) 530 +---------------+---------------+ 531 | Area ID | (variable 1..13) 532 . . 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | NL | (1 byte) 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |starting nickname for l-range 1| (2 bytes) 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |end nickname for l-range 1 | (2 bytes) 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 . . 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |starting nickname for l-range n| (2 bytes) 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 |end nickname for l-range n | (2 bytes) 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | ND | (1 byte) 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |starting nickname for d-range 1| (2 bytes) 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |end nickname for d-range 1 | (2 bytes) 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 . . 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 |starting nickname for d-range n| (2 bytes) 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |end nickname for d-range n | (2 bytes) 558 +-------------------------------+ 560 Figure 4 Nickname Management sub-TLV structure 562 o Type: NICK-MGMT, (TBD). 564 o Length: variable. Length is 1 + length of Area ID + 1+2*2*NL + 565 1 + 2*2*ND, where NL is the number local ranges and ND is 566 number of dynamic ranges. 568 o Area-ID : (variable length) Is the IS-IS Area ID. Length can be 569 1-13 bytes long. 571 o NL : number of local nickname ranges. 573 o ND : number of dynamic ranges. 575 o Starting nickname for l-range n: starting nickname of the local 576 range n. 578 o End nickname for l-range n: End nickname of the local range n. 580 o Starting nickname for d-range n: starting nickname of the 581 dynamic range n. 583 o End nickname for d-range n: End nickname of the dynamic range 584 n. 586 NOTE: Multiple instances of the nickname management sub-TLV MAY be 587 included. Nickname management sub-TLV has usage in non multi-level 588 deployments as well. Nickname management sub-TLV allows 589 administrator to control nickname acquisition by RBridges. 591 7. Further optimizations 593 RFC6325 allows multiple instance of nickname sub-TLV. If more 594 specific forwarding is required, for some critical RBridges, such 595 nicknames MAY be advertised in a separate Router capability TLV, 596 with S bit set. So it leaks to all L1 areas. 598 7.1. Leaking of TRILL IS-IS sub-TLV within areas 600 At the boundary nodes, the following information needs to be leaked 601 from the Level-1 database to the Level-2 database. The nickname TLVs 602 that are learned from all nodes within the same site needs to be 603 redistributed to the Level-2 database. All such redistributed 604 nickname TLVs will have the root priority set to 0. Note, that all 605 border area nodes will announce this TLV into the Level-2 database. 606 As a result, all Level-2 nodes will be able to see the reachability 607 of all other nodes. This enables unicast traffic flow. With respect 608 to multicast, redistributed nicknames are not to be used in the root 609 election for global trees. The roots of the global trees will be 610 from the set of nicknames that are in the Level-2 database. Once the 611 roots have been identified, these nicknames need to be leaked back 612 to the Level-1 areas. Calculation of multi-destination trees are 613 presented in section 7.2. 615 7.2. Identification of Global Trees 617 It is expected only a sub-set of traffic requires a global reach 618 (inter Area). Majority of the traffic will be of local scope (intra 619 area). Scope of the traffic can be identified either based on VLAN 620 or fine-grain label. Traffic of global scope is forwarded using 621 global trees. The trees of global scope may be indentified: 623 1. By means of configuration 624 2. By means of multi-destination tree announcements sub-TLV. 626 Point number 2 above requires further clarifications. We propose to 627 introduce 3 new sub-TLV under IS-IS router capability TLV to 628 advertise global multi-destination trees. These new sub-TLV are 629 listed below. Format of the new sub-TLVs are presented in section 630 7.2.1. to 7.2.3. 632 o The Global Tree capability sub-TLV 633 o The Global Tree proposal sub-TLV 634 o The Global Tree identifier sub-TLV 636 Each RBridge announces two sets of capabilities; global tree 637 capabilities and local tree capabilities. It announces, maximum 638 number of global distributions trees it can compute. RBridges 639 utilize Global Tree sub-TLV for the purpose of announcing its global 640 tree capability. RBridges announce local tree capabilities using The 641 Tree sub-TLV [RFC6326]. Global tree space is disjoint from the local 642 tree space and MUST not have any effect on each other. Please refer 643 to [RFC6325] for the process of how local trees are derived. In this 644 section we present how the total number of global trees needed is 645 calculated and identification of nickname of each tree root. 647 Each area border RBridge, using the global tree sub-TLV received 648 from RBRidges in its local area, derives the number of trees the 649 area can support. The number of global trees "s", a local area can 650 support is the fewest number of global trees that an RBridge in 651 local area can support. Area border RBridges advertise in to the 652 backbone, using the global Tree capability sub-TLV, the number of 653 trees "s" that the given area can calculate. Global Tree capability 654 sub-TLV announced in to the L2 backbone are advertised with "S" and 655 "D" flags of Router Capability TLV set to 0. This prevent them 656 leaking to L1 areas. 658 Rbridges in the L2 backbone calculate the number of global trees the 659 campus can calculate. This number "i" is the fewest number of global 660 trees among all areas. 662 Each RBridge in the L2 backbone using Global Tree proposal sub-TLV 663 advertise the number of trees it want other RBridges in the L2 664 backbone to calculate. RBridges in the L2 backbone identifies number 665 of global trees they need to calculate based on the number of trees 666 "k" advertised by the highest priority RBridge in the L2 backbone. 668 The L2 area RBridge with the highest priority advertises set of 669 nicknames for the global tree roots. These tree roots are selected 670 based on tree root priority announced by L2 backbone RBridges. 671 Global Tree Identifier sub-TLV is used for the purpose. 673 BSR RBRidge of each L1 area advertises nicknames of global tree 674 roots using Global Tree Identifier sub-TLV in to the corresponding 675 local area. BSR also advertises the number of Global trees k the 676 local area needs to calculate using Global tree proposal sub-TLV. 678 RBridges in the local area contain only nicknames of the local area. 679 Global Tree Identifier sub-TLV announced by the BSR contains 680 nicknames that are unknown to the local L1 area RBridges. How do 681 local RBridges calculate it SPF ? 683 Global Tree Identifier sub_TLV contain nickname of the global trees 684 ordered in ascending order. Default Affinity TLV announced by RP 685 RBridge contains the tree-id(s) that it is an RP. Tree-id k in the 686 Default affinity TLV corresponds to nickname k in the Global Tree 687 Identifier. RBRidges in the local L1 area calculate its SPF tree 688 assuming the tree-k is rooted at the RP RBridge announcing the 689 Default affinity sub-TLV for that tree. 691 Global Tree proposal sub-TLV and Global Tree Identifier sub-TLV MUST 692 only be advertised by BSR. Sub-TLV from highest priority RBRidge is 693 chosen, in the event of multiple RBridges advertising conflicting 694 sub-TLVs. 696 7.2.1. Global Tree capability sub-TLV 698 +-+-+-+-+-+-+-+-+ 699 |Type = GL-TREES| (1 byte) 700 +-+-+-+-+-+-+-+-+ 701 | Length | (1 byte) 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Maximum trees able to compute | (2 byte) 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Figure 5 Global Tree Capability sub-TLV 708 Type: Router Capability sub-TLV type, TBD 710 Length: 2. 712 Maximum trees able to compute: An unsigned 16-bit integer indicates 713 maximum number of global trees the announcing RBridge able to 714 compute. 716 7.2.2. Global Tree proposal sub-TLV 718 +-+-+-+-+-+-+-+-+ 719 |Type = GL-TR-PR| (1 byte) 720 +-+-+-+-+-+-+-+-+ 721 | Length | (1 byte) 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Maximum trees to compute | (2 byte) 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Figure 6 Global Tree Proposal sub-TLV 728 Type: Router Capability sub-TLV type, TBD (GL-TR-PR) 730 Length: 2. 732 Maximum trees to compute: An unsigned 16-bit integer indicates 733 maximum number of global trees the announcing RBridge wants area 734 RBRidges to calculate. 736 7.2.3. Global Tree Identifier sub-TLV 738 +-+-+-+-+-+-+-+-+ 739 |Type=GLTR-RT-IDs| (1 byte) 740 +-+-+-+-+-+-+-+-+ 741 | Length | (1 byte) 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |Starting Tree Number | (2 bytes) 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Nickname (K-th root) | (2 bytes) 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Nickname (K+1 - th root) | (2 bytes) 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Nickname (...) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Figure 7 Global Tree Identifier sub-TLV 754 Type: Router Capability sub-TLV type, set to TBD (GLTR-RT-IDs). 756 Length: 2 + 2*n, where n is the number of nicknames listed. 758 Starting Tree Number: This identifies the starting tree number ofthe 759 nicknames that are trees for the domain. This is set to 1 for the sub- 760 TLV containing the first list. Other Tree-Identifiers sub-TLVs will 761 have the number of the starting list they contain. In the event a tree 762 identifier can be computed from two such sub-TLVs and they are 763 different, then it is assumed that this is a transient condition that 764 will get cleared. During this transient time, such a tree SHOULD NOT 765 be computed unless such computation is indicated by all relevant sub- 766 TLVs present. 768 Nickname: The nickname at which a distribution tree is rooted. 770 7.3. Announcing Group Addresses 772 Group Address announcements facilitate optimization of multicast 773 forwarding. [RFC6326] and [rfc6326bis], define series of sub-TLV to 774 announce various flavors of Group addresses. These sub-TLVs are 775 encapsulated in Group Address TLV (142). We propose to define new 776 set of sub-TLV under Group Address TLV to carry Group Address 777 announcements applicable to Global trees. IS-IS Group Address TLV 778 (142) does not have flags to control the scope of the TLV. Hence, 779 explicit, sub-TLV definitions are required to indentify group 780 announcements that have global scope. 782 New sub-TLV numbers are required for the following. 784 o Group MAC Address Sub-TLV 785 o Group IPv4 Address Sub-TLV 786 o Group IPv6 Address Sub-TLV 787 o Group Labeled MAC Address Sub-TLV 788 o Group Labeled IPv4 Address Sub-TLV 789 o Group Labeled IPv6 Address Sub-TLV 791 Above sub-TLVs as defined in [RFC6326] and [rfc6326bis] applies to 792 all trees within the TRILL campus. New sub-TLV definitions include 793 flexibility to define the applicable multicast trees. This 794 flexibility allows applications to further optimize multicast 795 pruning per multicast tree basis. 797 New group address sub-TLV will be named as below and they have 798 common TLV header as defined in Figure 8. 800 o Group MAC Address-multicast tree Sub-TLV 801 o Group IPv4 Address-multicast tree Sub-TLV 802 o Group IPv6 Address-multicast tree Sub-TLV 803 o Group Labeled MAC Address-multicast tree Sub-TLV 804 o Group Labeled IPv4 Address-multicast tree Sub-TLV 805 o Group Labeled IPv6 Address-multicast tree Sub-TLV 807 +-+-+-+-+-+-+-+-+ 808 |Type=G-ADDR-TR | (1 byte) 809 +-+-+-+-+-+-+-+-+ 810 | Length | (1 byte) 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | RESV | Topology-ID | (2 bytes) 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | number of trees | (2 bytes) 815 +-------------------------------+ 816 | nickname of kth tree | (2 bytes) 817 +-------------------------------+ 818 | nickname of k+1 tree | (2 bytes) 819 +-------------------------------+ 820 . . 821 | | 822 +-------------------------------+ 823 | nickname of (k+n) tree | (2 bytes) 824 +-------------------------------+ 825 | RESV | VLAN ID/Label | (2 or 3 bytes) 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 |Num Group Recs | (1 byte) 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | GROUP RECORDS (1) | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 . . 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | GROUP RECORDS (m) | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Figure 8 Common structure of Group-Address-multicast tree sub-TLVs 840 o Type: G-ADDR-TR, (TBD). Defines sub-TLV for 842 o Group MAC Address-multicast tree Sub-TLV 843 o Group IPv4 Address-multicast tree Sub-TLV 844 o Group IPv6 Address-multicast tree Sub-TLV 845 o Group Labeled MAC Address-multicast tree Sub-TLV 847 o Length: Applicable length of the sub-TLV in bytes. Excludes 848 length of G-ADDR-TR and Length fields. 850 o Topology ID: 2 byte identifier of the topology instance id. 852 o Number of trees: Number of tree nicknames included in the sub- 853 TLV. The nicknames included in the sub-TLV MUST be sorted in 854 ascending order. 856 o Nickname of kth tree: 2 byte nickname of the kth tree to which 857 this Group address-tree announcement applies. 859 o VLAN ID/Label: Either 4bit reserved followed by 12bit VLAN ID 860 or 24bit finegrain label. Please see [rfc6326bis] for details. 862 o Num Grp Recs: Number of Group Records to follow. 864 o Group Record: Contents of the Group Records depend on the G- 865 ADDR-TR definition and identical to their counterparts defined 866 in [rfc6326bis]. 868 8. Architecture Elements of Multi-level Multicast framework 870 o Bootstrap RBridge 872 o Rendezvous Point (RP) 874 o Default Affinity sub-TLV 876 o Area Affinity sub-TLV 878 o RP Election Protocol 880 Five main elements of the multi-level multicast framework are listed 881 above. Functional overviews of the elements are discussed below. 882 Details, such as state machines, PDU format, etc, will be presented 883 in later versions of this document. 885 8.1. Bootstrap RBridge 887 Each Area has one more area border RBridges between the Area and the 888 L2 backbone area. For each area one of its area border RBridges is 889 elected as the Bootstrap RBridge. 891 Border RBridges communicate with each other using the TRILL BSR 892 protocol. Each border RBridge has a configured priority to be a 893 Bootstrap RBridge with system-ID as the tie breaker. The RBridge 894 with the highest priority become the bootstrap RBridge for the area. 896 Bootstrap RBRidge selects the Rendezvous Point (RP) RBridges and 897 assign each RP a set of trees for which RP will function as the 898 gateway between the local and global multicast trees. To avoid loops 899 and/or packet duplication the set of trees MUST only be allocated to 900 one and only one RP. 902 8.2. Rendezvous Point (RP) 904 Rendezvous Point (RP) RBridge performs the function of gateway (or 905 acts as a point of plumbing) between the local multicast tree and 906 the corresponding global multicast tree rooted in the L2 backbone 907 area. 909 Bootstrap RBridge designates one of the border RBridges (including 910 itself) as the RP for a set of (mutually exclusive) trees. 912 Each border RBridge, using TRILL BSR protocol, announces its desire 913 to be an RP. The desire to be an RP is a configurable option and 914 enabled by default to be an RP. 916 8.3. Default Affinity sub-TLV 918 Default Affinity sub-TLV is announced by each RP to inform the 919 RBridges in the L1 Area the association of the default nickname to a 920 set of trees through the announcing RP [trillcmt]. 922 RBridges in the L1 area, based on the Default Affinity sub-TLV 923 installs the RPF check for default nickname for the specified tree 924 "t" on an interface facing towards the announcing RP. 926 8.4. Area Affinity sub-TLV 928 The Area Affinity sub-TLV announced by each RP to inform the 929 RBridges in L2 backbone Area the association of local L1 Area 930 nicknames to a set of trees through the announcing RP (Figure 3). 932 RBridges in the L2 backbone area or has interfaces to the L2 933 backbone area, based on the Area Affinity sub-TLV, installs the RPF 934 check for the nicknames in the indicated L1 Area, for the specified 935 tree "t", on an interface facing towards the announcing RP. 937 8.5. TRILL BSR Protocol 939 9. Security Considerations 941 TBD 943 10. IANA Considerations 945 IANA is requested to add the Area Affinity sub-TLV, Nickname 946 Management sub-TLV, Global Tree capability sub-TLV, Global tree 947 proposal sub-TLV, Global tree Identfier sub-TLV as sub-TLVs under 948 Router capability TLV. 950 11. References 952 11.1. Normative References 954 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 955 Requirement Levels", BCP 14, RFC 2119, March 1997. 957 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 958 Syntax Specifications: ABNF", RFC 2234, Internet Mail 959 Consortium and Demon Internet Ltd., November 1997. 961 [RFC4971] Vasseur, JP, et.al, "Intermediate System to Intermediate 962 System (IS-IS) Extensions for Advertising Router 963 Information ", RFC 4971, July 2007. 965 [RFC6325] Perlma, R., et.al, "Routing Bridges (RBridges): Base 966 Protocol Specification", RFC 6325, July 2011. 968 [trillcmt]Senevirathne, T., et.al, "Coordinated Multicast Trees 969 (CMT)for TRILL", Work in Progress, January 2012. 971 [RFC4971] Vasseur, JP, et.al, "Intermediate System to Intermediate 972 System (IS-IS) Extensions for Advertising Router 973 Information", RFC 4971, July 2007. 975 11.2. Informative References 977 [RFC6326] Eastlake, D, et.al, "Transparent Interconnection of Lots 978 of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. 980 [rfc6326bis] Eastlake, D, et.al, "Transparent Interconnection of 981 Lots of Links (TRILL) Use of IS-IS", Work in Progress, 982 draft-eastlake-isis-rfc6326bis-04.txt, January 2012. 984 [trillml] Perlman, R., et.al, "RBridges: Multilevel TRILL", Work in 985 Progress, draft-perlman-trill-rbridge-multilevel-03.txt, 986 October 2011. 988 12. Acknowledgments 990 We wish to thank Leonard Tracy, Dinesh Dutt and Ashok Ganesan for 991 reviewing and providing constructive feedback. 993 This document was prepared using 2-Word-v2.0.template.dot. 995 Authors' Addresses 997 Tissa Senevirathne 998 CISCO Systems 999 375 East Tasman Drive 1000 San Jose CA 95134 1002 Phone: 408-853-2291 1003 Email: tsenevir@cisco.com 1005 Les Ginsberg 1006 CISCO Systems 1007 510 McCarthy Blvd. 1008 Milpitas CA 95035 1010 Phone: 408-527-7729 1011 Email:ginsberg@cisco.com 1013 Sam Aldrin 1014 Huawei Technologies 1015 2330 Central Express Way 1016 Santa Clara, CA 95951 1018 Email: aldrin.ietf@gmail.com 1020 Ayan Banerjee 1021 CISCO Systems 1022 425 East Tasman Drive 1023 San Jose CA 95134 1025 Phone: 408-527-0539 1026 Email: ayabaner@cisco.com