idnits 2.17.1 draft-wu-trill-lsp-ext-tree-distr-opt-01.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 draft header indicates that this document updates RFC6325, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2012) is 4204 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) == Unused Reference: 'RFC5029' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'TRILL-ML' is defined on line 420, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) == Outdated reference: A later version (-10) exists of draft-perlman-trill-rbridge-multilevel-03 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transparent Interconnection of Lots of Q. Wu 3 Links Working Group W. Hao 4 Internet-Draft Huawei 5 Updates: 6325 (if approved) October 22, 2012 6 Intended status: Standards Track 7 Expires: April 25, 2013 9 LSP extension for Tree Distribution Optimization across sites 10 draft-wu-trill-lsp-ext-tree-distr-opt-01 12 Abstract 14 This document specifies an extension to LSP for the Rbridge in one 15 site to advertise Global VLAN scope and associated link attribute to 16 all the Rbridges both in the site of that Border Rbridge and the 17 other adjacent sites in the same campus. With this extension, 18 RBridges can prune the distribution tree of multi-destination frames 19 according to the scope of the VLAN and link attribute defined in this 20 document. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. TLV and Sub-TLV Extensions to IS-IS for Inter-site 60 Distribution Tree . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Global-VLANs Sub-TLV for the Router Capability TLV . . . . 6 62 4.1.1. Definition of Fields in Sub-TLV . . . . . . . . . . . 6 63 4.2. Link-Attributes Sub-TLV extension for extended IS 64 reachability TLV . . . . . . . . . . . . . . . . . . . . . 7 65 5. Use of TLV and Sub-TLV for Tree Distribution Optimization 66 across sites . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Unicast Forwarding Consideration . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 73 Appendix A. Change Logs . . . . . . . . . . . . . . . . . . . . . 16 74 A.1. draft-wu-trill-lsp-ext-tree-distr-opt-01 . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Large datacenters are often multi-site in nature and may contain a 80 large number of Rbridges in each site. A trill Campus network may 81 also be designed to be multilevel can be divided in to multiple IS-IS 82 [IS-IS][RFC1195]L1 Areas interconnected by L2 backbone area. Routing 83 between Rbridges within a IS-IS L1 area/ site is known as "Level 1 84 routing". Routing between IS-IS L1 areas or sites is known as "Level 85 2 routing". The IS-IS L1 area supports Level 1 routing and consists 86 of Rbridges within the site and link between Rbridges within the 87 site. The L2 backbone area supports Level 2 routing and consists of 88 Border Rbridges and links between the Border Rbridges. Border 89 Rbridges may participate in one or more L1 areas as Level-1 Rbridges 90 inside each site, in addition to their role as Level 2 Rbridge across 91 sites. 93 In Trill campus network, RBridges use distribution trees to forward 94 multi-destination frames. In case of one Trill campus network having 95 multiple sites, the traffic associated with some distributed trees 96 may travel between sites while the traffic associated with other 97 distributed trees may be limited to only one site and not allowed to 98 go across other sites. The traffic spanning across sites is also 99 referred to as the traffic with global scope. In order to support 100 scaling and performance of large TRILL networks in the real 101 deployments, it is desirable to forward most of Multi-destination 102 Trill traffic within the site and reduce the traffic that is required 103 to span across sites within the entire TRILL campus. According to 104 The TRILL base protocol, each distribution tree SHOULD be pruned per 105 VLAN. When it is inevitable to construct trees that have a scope 106 across sites throughout the TRILL campus, it is necessary to treat 107 traffic tagged with VLAN differently based on VLAN scope and distinct 108 the link between Rbridges in one site and link between two Border 109 Rbridge in two sites to support large scale multi-tenants 110 application. 112 This document specifies an extension to LSP for the Rbridge in one 113 site to advertise Global VLAN scope and associated link attribute to 114 all the Rbridges both in the site of that Border Rbridge and the 115 other adjacent sites in the same campus. With this extension, 116 RBridges can prune the distribution tree of multi-destination frames 117 according to the scope of the VLAN and link attribute defined in this 118 document. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC2119 [RFC2119]. 126 3. Motivations 128 Distinguishing global vlan from local vlan is to increase the number 129 of tenants by not breaking the VLAN tag size limits. E.g. one campus 130 being divided into n sites, without distinction between global vlan 131 and local vlan, at most support 4K tenants. However, if we 132 distinguish global vlan from local vlan, suppose each site support 133 only local vlan. Then each site support 4K tenants, the total number 134 of tenants supported by one campus can be increased to 4n*K.Suppose 135 some sites support local vlan, some sites support both local vlan and 136 global vlan, the total number of tenants supported by one campus 137 (4K,4n*K). 139 4. TLV and Sub-TLV Extensions to IS-IS for Inter-site Distribution Tree 141 This section describes data formats and code points for the TLVs and 142 sub-TLVs added to IS-IS defined by this specification to support the 143 multi-level TRILL or re-used from that already contained in the 144 standard IS-IS extensions defined in [RFC6326]. 146 4.1. Global-VLANs Sub-TLV for the Router Capability TLV 148 The optional Global-VLANs sub-TLV specifies the VLANs that have 149 global scope and enable Construction of global multi-destination 150 trees among different sites. It has the following format: 152 +-+-+-+-+-+-+-+-+ 153 | Type | (1 byte) 154 +-+-+-+-+-+-+-+-+ 155 | Length | (1 byte) 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | RESV | Start VLAN ID | (2 bytes) 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | VLAN bit-map.... 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 1: Report Block Structure 164 4.1.1. Definition of Fields in Sub-TLV 166 Type: 8bits 168 Router Capability sub-TLV type, set to TBD (GLOBAL-VLANs). 170 Length: 8bits 172 Variable, minimum 3. 174 RESV: 4bits 176 4 reserved bits that MUST be sent as zero and ignored on receipt. 178 Start VLAN ID:12bits 180 The 12-bit VLAN ID that is represented by the high order bit of 181 the first byte of the VLAN bit-map. 183 VLAN bit-map: 185 The highest order bit indicates the VLAN equal to the start VLAN 186 ID, the next highest bit indicates the VLAN equal to start VLAN ID 187 + 1, continuing to the end of the VLAN bit-map field. 189 4.2. Link-Attributes Sub-TLV extension for extended IS reachability TLV 191 The link-attribute sub-TLV is carried within the TLV 22 and has a 192 format identical to the sub-TLV format used by the Traffic 193 Engineering Extensions for IS-IS ([RFC3784]): 1 octet of sub-type, 1 194 octet of length of the value field of the sub-TLV followed by the 195 value field -- in this case, a 16 bit flags field. 197 The Link-attribute sub-type is 19 and the link-attribute has a length 198 of 2 octets. 200 This sub-TLV is OPTIONAL and MUST appear at most once for a single IS 201 neighbor. If a received Link State Packet (LSP) contains more than 202 one Link-Attribute Sub-TLV, an implementation SHOULD decide to 203 consider only the first encountered instance. The following bit is 204 defined: 206 Public Link Type For TRILL(0x03) When set, this indicates that the 207 link is public link for TRILL sites interconnection. 209 5. Use of TLV and Sub-TLV for Tree Distribution Optimization across 210 sites 212 When the TRILL campus is divided into multiple sites, each site may 213 have one or more Border Rbridges used to interconnect other remaining 214 sites and form the Level 2 IS-IS Trill network. Such Level2 IS-IS 215 Trill network can be used to construct global multi-destination tree 216 spanning across various sites. 218 TRILL Site 1 TRILL Site 2 219 +-------------------+ +---------------+ +-------------------+ 220 | | | | | | 221 | +---+ +----+ | | WAN | |+----+ +---+ | 222 | |RB1|------+BRB2| |--|L2 Connectivity|---||BRB3|-------|RB4| | 223 | +---+ +----+ | | | |+----+ +---+ | 224 | | | | | | 225 +-------------------+ +---------------+ +-------------------+ 226 | 227 | 228 +-------------------+ 229 | +----+ | 230 | |BRB5| | 231 | +----+ | 232 | +---+ | +---+ | 233 | |RB6|---+---|RB7| | 234 | +---+ +---+ | 235 +-------------------+ 236 TRILL Site 3 238 Figure 1: Example of multiple sites within one Trill Campus 240 In order to support scaling and performance of large TRILL networks 241 in the real deployments, firstly, not all the links between the level 242 2 Rbridges need to be used to Construct global multi- destination 243 trees. If the link between the level 2 Rbridges is allowed to 244 construct global multi-destination trees, we can set this link 245 attribute into "public interface for global tree construction". In 246 this document, we reuse Link Attribute sub-TLV for the extended IS 247 reachability TLV and allocate a new bit value inside link Attribute 248 Sub-TLV to support indication of "public link for global tree 249 Construction". The Border Rbridge in one site need to advertise this 250 link attribute Sub-TLV to all the neighboring Border Rbridges in 251 other neighboring sites and then this sub-TLV will be further 252 forwarded to all the Rbridges in the site of each neighboring Border 253 Rbridge. RBridges in each site can prune the distribution tree of 254 multi-destination frames according to such link attribute. 256 Secondly, not all traffic should have global scope and need to span 257 across sites. Since each distribution tree SHOULD be pruned per VLAN 258 according to [RFC6325], we can specify a set of Global VLANs to 259 identify the traffic that has global scope. In this document, we 260 define one new sub-TLV for the Router Capability TLV, i.e., Global- 261 VLANs Sub- TLV. This Sub-TLV can be used by Rbriges in one site to 262 determine whether Construction of global multi-destination trees 263 across sites is allowed. In order to achieve this, the tree root or 264 highest priority RBridge in one site configured to know a number of 265 appropriate VLANs as Global VLANs and announce such information to 266 the nearest border Rbridge; Then such Border Rbridge in this site 267 need to advertise Global VLAN Sub-TLV to all the neighboring Border 268 Rbridges in other neighboring sites and then this sub-TLV will be 269 further forwarded to all the Rbridges in the site of each neighboring 270 Border Rbridge. When Global VLAN and link attribute Sub-TLV 271 described above has been distributed to all the corresponding 272 Rbridges in the downstream of the tree root or highest priority 273 RBridge, RBridges can prune the distribution tree of multi- 274 destination frames according to the scope of the VLAN and link 275 attribute defined in this document, eliminating branches that own 276 link type mismatching with Distribution Tree scope identified by 277 VLAN. If the distribution tree is local tree and has branches 278 including a link with link attribute is set to public link for global 279 tree construction, those branches should be eliminated. If the 280 distribution tree is global tree and has branches containing a link 281 with link attribute not set to public link for global tree 282 construction, those branches also should be eliminated. 284 +---+ 285 | a | 286 +---+ 287 L1 \ \ L2 288 \ \ 289 \ \ 290 +---+ +---+ 291 | b | | c | 292 +---+ +---+ 293 L3 \ \ L4 294 VLAN20 \ \ 295 \ \ 296 +---+ +---+ 297 | d | | e | 298 +---+ +---+ 299 _ _ 300 _ _ \ 301 public link _L5 _L6 \ L7 302 _ _ \ 303 +---+ +---+ +---+ 304 | f | | g | | h | 305 +---+ +---+ +---+ 307 VLAN10 VLAN10 VLAN20 309 Figure 2: Distribution Tree 311 Take distribution tree in Figure 2 as an example, Rbridge a is root 312 node. Rbridge f,g are leaf nodes that have end station on VLAN 10 313 while Rbridge b,h are another two leaf nodes and that have end 314 station on VLAN 20. The link between Rbridge d and f is public link 315 used across sites while the other links in the figure 2 are links 316 owned by one single site. Assume VLAN 10 are local VLAN and VLAN 20 317 are Global VLAN, after distribution tree pruning is done, Rbrige c 318 should eliminate branch that has Rridge d and f since distribution 319 tree is pruned based on local VLAN 10 and Link 5 in that branch is 320 public link, which mismatch with each other. 322 6. Unicast Forwarding Consideration 324 In unicast forwarding, the MAC forwarding table for a Trill Border 325 Rbridge is usually learned through the data plane, i.e.,MAC address 326 is learnt from received Broadcast,Unknown, Unicast,Multicast packet 327 through distribution tree. For end stations on the local vlan, the 328 broadcast scope is limited to one local site, the Border Rbridge only 329 learns MAC address of locally attached end station and the forwarding 330 path between end stations within one site can be built for unicast. 331 For end stations on global VLAN, end stations between two sites are 332 within the same layer 2 broadcast domain, the Border Rbridge can 333 learn MAC address of end stations across sites and the forward path 334 between two sites can be built as well for unicast. Therefore 335 unicast forwarding between sites can be controlled through LSP 336 extension we defined in this document. 338 If the Border Rbridge is statically configured with unicast 339 forwarding table and the nickname of the destination Rbridge is 340 specified as one Rbridge's nickname in other sites, the unicast 341 packet must be forced to forward to the other sites. In this case, 342 the Border Rbridge in other sites performs security check to the 343 received packet. If the VLAN associated with the received packet is 344 local VLAN and the packet is ingressed from public link across site, 345 the packet should be discarded. If the VLAN associated with the 346 received packet is Global VLAN, the packet should be allowed to 347 ingress from public link across sites. 349 7. IANA Considerations 351 IANA is requested to assign a new codepoint for the Global-VLANs Sub- 352 TLV defined in this document and carried within TLV 242. 354 IANA has created a registry for bit values inside the link-attributes 355 sub-TLV called "link-attribute bit values for sub-TLV 19 of TLV 22". 357 This document instructs IANA to add a new bit value in the link- 358 attribute bit values for sub-TLV 19 of TLV 22 registry as follows: 360 Value Name Reference 361 ----- ---- --------- 362 0x3 Public Link Type between sites [This document] 364 Further values are to be allocated by the Standards Action process 365 defined in [RFC2434], with Early Allocation (defined in [RFC4020]) 366 permitted. 368 8. Security Considerations 370 The security considerations documented in [RFC4971][RFC5305] are 371 applicable for the Sub-TLV extension defined in this document. 373 9. References 375 9.1. Normative References 377 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 378 Routing Exchange Protocol for use in Conjunction with the 379 Protocol for Providing the Connectionless-mode Network 380 Service (ISO 8473)", ISO/IEC 10589:2002 Second Edition, 381 2002. 383 [RFC1195] Ohta, M., "Use of OSI IS-IS for routing in TCP/IP and dual 384 environments", December 1990. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", March 1997. 389 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 390 IANA Considerations Section in RFCs", RFC 2434, 391 October 1998. 393 [RFC3784] Smit, H., "Intermediate System to Intermediate System 394 (IS-IS) Extensions for Traffic Engineering (TE)", 395 June 2004. 397 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 398 Standards Track Code Points", RFC 4020, February 2005. 400 [RFC4971] Vasseur, J., "Intermediate System to Intermediate System 401 (IS-IS) Extensions for Advertising Router Information", 402 July 2007. 404 [RFC5029] Vasseur, J. and S. Previdi, "SDP: Session Description 405 Protocol", September 2007. 407 [RFC5305] Li, T. and H. Smit, "S-IS Extensions for Traffic 408 Engineering", RFC 5305, October 2008. 410 [RFC6325] Perlman, R., Eastlake , D., Dutt, D., Gai, S., and A. 411 Ghanwani, "Routing Bridges (RBridges): Base Protocol 412 Specification", RFC 6325, July 2011. 414 [RFC6326] Eastlake , D., Banerjee, A., Dutt, D., Perlman, R., and A. 415 Ghanwani, "Transparent Interconnection of Lots of Links 416 (TRILL) Use of IS-IS", RFC 6326, July 2011. 418 9.2. Informative References 420 [TRILL-ML] 421 Perlman , R., Eastlake, D., Ghanwani, A., and H. Zhai, 422 "RBridges: Multilevel TRILL", 423 ID draft-perlman-trill-rbridge-multilevel-03, 424 October 2011. 426 Appendix A. Change Logs 428 A.1. draft-wu-trill-lsp-ext-tree-distr-opt-01 430 The following are the major changes to previous version 431 draft-wu-trill-lsp-ext-tree-distr-opt-00: 433 o Add one new section to discuss Unicast Forwarding. 435 o Add one new section to clarify the motivation to write this draft. 437 o Some other editorial changes. 439 Authors' Addresses 441 Qin Wu 442 Huawei 443 101 Software Avenue, Yuhua District 444 Nanjing, Jiangsu 210012 445 China 447 Email: bill.wu@huawei.com 449 Weiguo Hao 450 Huawei 451 101 Software Avenue, Yuhua District 452 Nanjing, Jiangsu 210012 453 China 455 Email: haoweiguo@huawei.com