idnits 2.17.1 draft-tissa-trill-mt-encode-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: Methods proposed in this document encode the MT topology ID into TRILL data frames without modifying the TRILL header. Hence, MT capable, RBridges interfacing with non-MT capable RBridges can selectively not encode the proposed MT extensions on interfaces with non-MT capable RBridges. Non MT capable RBridges do not required to be in the base topology. They can be in any valid topology. Only restriction is non-MT capable RBridges can belong to a single topology only. In its IS-IS HELLO messages, RrRidges exchange its MT capability and topology information. RBridges that are not capable of supporting proposed MT extension in data plane, MUST announce itself as non MT capable, but MAY advertise its association to a topology other than the base topology by including MT extensions proposed in [RFC5120]. MT encoding capability is announced by setting the proposed MT encoding capability bit in Port TRILL Version sub-TLV [rfc6326bis]. Presence of IS-IS Multi Topology TLV [RFC5120], indicates only the associated topology. MT encoding capability indicates RBRidges ability to support proposed data plane extensions. When MT capability is not set RBridge MUST not use the proposed data plane encoding methods, instead it must associate the announcing RBRidge to the advertised topology or base topology in the absence of Multi-Topology TLV [RFC5120]. -- The document date (September 11, 2012) is 4244 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: 'RFC5120' is mentioned on line 140, but not defined == Missing Reference: 'RFC6325' is mentioned on line 160, but not defined == Unused Reference: 'RF5120' is defined on line 347, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-manral-isis-trill-multi-topo-03 == Outdated reference: A later version (-03) exists of draft-eastlake-trill-rbridge-multi-topo-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 Satya Dillikar 4 Intended status: Standard Track CISCO 6 Ayan Banerjee 7 Consultant 9 Sam Aldrin 10 HuaaWei 12 Naveen Nimmu 13 Broadcom 15 September 11, 2012 16 Expires: March 2013 18 Multi Topology Encoding within TRILL data frames 19 draft-tissa-trill-mt-encode-02.txt 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on December 11, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. 56 Abstract 58 Two alternate methods of encoding Multi Topology Identifier within 59 the TRILL data frames are presented. Methods proposed herein do not 60 require overloading TRILL RBridge nickname to encode Multi Topology 61 Identifier. A method that expands TRILL nickname space from 16bits 62 to 24 bits is also presented in this draft. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Conventions used in this document..............................4 68 3. Multi Topology Encoding........................................4 69 3.1. Nickname construction.....................................5 70 3.2. Use of Next-Hop VLAN for MT Encoding......................5 71 4. Multi Topology Interoperability................................6 72 4.1. Interoperability during Migration.........................6 73 4.2. Interoperability with RBridges with Non MT capable data 74 plane..........................................................7 75 4.3. Interoperability with MT unaware RBRdiges.................8 76 5. Backward compatibility.........................................8 77 6. IS-IS sub-TLV definition.......................................8 78 6.1. MT capability.............................................8 79 7. Security Considerations........................................9 80 8. Assignment Considerations.....................................9 81 8.1. IANA Considerations.......................................9 82 8.2. IEEE Considerations.......................................9 83 9. References.....................................................9 84 9.1. Normative References......................................9 85 9.2. Informative References....................................9 86 10. Acknowledgments...............................................9 87 Authors' Addresses...............................................10 89 1. Introduction 91 Multi Topology is an attractive concept that allows creating 92 different virtual topologies or overlays on top of a single physical 93 topology. There are several important applications. Few such 94 applications are listed below. The list below is by no means an 95 exhaustive list and there are other applications that may utilize 96 the MT framework. 98 Application specific topology (Storage topology vs. data topology) 100 Virtual topologies for different customers 102 Expansion of TRILL nickname space 104 Traffic Engineering 106 [RFC5120] presents Multi topology (MT) framework for IS-IS. MT has 107 two important parts; IS-IS control plane extensions and Data plane 108 encoding. [RFC5120] presents IS-IS control plane extensions. [TRILL- 109 MT1] and [TRILL-MT2] presents required IS-IS sub-TLV definitions and 110 the data plane encoding for TRILL. 112 In this document we propose methods that facilitate encoding of 16 113 bit Multi topology ID in to TRILL frames without reducing the 114 effective TRILL nickname space. Additionally, the proposed scheme 115 does not require definition of new Topology mapping sub-TLV. In 116 other words, IS-IS control plane is similar to [RFC5120] and does 117 not require additional complexity of mapping absolute Topology ID to 118 abbreviated topology ID. 120 Methods proposed in this document encode the MT topology ID into 121 TRILL data frames without modifying the TRILL header. Hence, MT 122 capable, RBridges interfacing with non-MT capable RBridges can 123 selectively not encode the proposed MT extensions on interfaces with 124 non-MT capable RBridges. Non MT capable RBridges do not required to 125 be in the base topology. They can be in any valid topology. Only 126 restriction is non-MT capable RBridges can belong to a single 127 topology only. In its IS-IS HELLO messages, RrRidges exchange its MT 128 capability and topology information. RBridges that are not capable 129 of supporting proposed MT extension in data plane, MUST announce 130 itself as non MT capable, but MAY advertise its association to a 131 topology other than the base topology by including MT extensions 132 proposed in [RFC5120]. MT encoding capability is announced by 133 setting the proposed MT encoding capability bit in Port TRILL 134 Version sub-TLV [rfc6326bis]. Presence of IS-IS Multi Topology TLV 135 [RFC5120], indicates only the associated topology. MT encoding 136 capability indicates RBRidges ability to support proposed data plane 137 extensions. When MT capability is not set RBridge MUST not use the 138 proposed data plane encoding methods, instead it must associate the 139 announcing RBRidge to the advertised topology or base topology in 140 the absence of Multi-Topology TLV [RFC5120]. 142 TRILL protocol, as defined in [RFC6325], defines 16bit nickname 143 space. 16bit nickname space allows up to 65536 unique nicknames. 144 However, it has been discussed in the working group that, more the 145 65536 unique names are required in certain large deployments. 146 Possible usage of Upperbits of Nickname is also being considered 147 for encoding Multitoplogy, which further reduces the available nick 148 name space. Presented in this document is a method that allows 149 expanding the 16bit nickname space to a 24bit nickname space, 150 without modifying the TRILL header defined in [RFC6325]. 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC-2119 [RFC2119]. 158 3. Multi Topology Encoding 160 [RFC6325] TRILL Base Protocol, proposes encoding scheme of TRILL 161 frames. TRILL frames contain outer MAC Header, 802.1QTAG, TRILL 162 header and user Data. We propose to include multi topology ID after 163 the 802.1Q TAG. Multi Toplogy ID is preceded by Ethernet Type MT- 164 ETHTYPE. 166 Outer Ethernet Header: 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Outer Destination MAC Address | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Outer Destination MAC Address | Outer Source MAC Address | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Outer Source MAC Address | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |Ethertype = MT-ETHTYPE | MT-ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | TRILL Header | 179 . . 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 . Payload . 184 . . 185 | | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 1 MT ID extensions in TRILL 191 Ethtype-MT : 16 bit Ethtype to encode Multi Topology ID. 193 MT-ID : 16bit Multi Topology IDNICKN-Ethtype : 16 bit Ethtype to 194 encode nickname expansion. 196 3.1. Nickname construction 198 Each RBridge that is compatible with the proposed scheme, First 199 check for presence of Nick-Ethtype, if present extract the EG-NICKN- 200 MSB and IG-NICKN-MSB. EG-NICKN-MSB and IG-NICKN-MSB are then 201 concatenated with the Egress TRILL nickname and the Ingress TRILL 202 nickname to form 24bit nickname space. The derived nickname MUST be 203 utilized for forwarding. 205 3.2. Use of Next-Hop VLAN for MT Encoding 207 Alternatively, Next-Hop VLAN may be utilized to encode MT ID in 208 point to point only networks. Next Hop VLAN on TRILL outer header is 209 independent of the inner VLAN. On Point-Pont links Next Hop VLAN is 210 only required to be of local significance. Hence, we propose to map 211 topologies to Next-Hop VLAN per link basis. 213 For sake of simplicity, we propose to map topology-id to Next-VLAN 214 based on local policies such as configuration. 216 4. Multi Topology Interoperability 218 There are three possible scenarios of Interoperability with RBridges 219 that are non-MT capable. 221 1. Interoperability During migration. 222 2. Interoperability with RBridges that are non-MT capable in the data 223 plane. (i.e. Software is MT aware and supports the extensions 224 specified here-in but, data plane is not capable of supporting the 225 proposed encoding methods). 226 3. Interoperability with Rbridges that are MT unaware in both Control 227 and data planes. 229 4.1. Interoperability during Migration 231 We recommend upgrading from the core to the edge, as depicted in 232 the figure below. With this approach, different clusters of RBridges 233 may belong to different topologies or to the same topology. RBridges 234 in the core provide connectivity to RBridge clusters at the edge in 235 a topology aware manner. 237 +-----------+ 238 | | Edge-1 to Edge 4 are 239 | Edge-1 | RBridge clusters that are 240 | | Non MT aware 241 | | 242 +-----------+ 243 o 244 | 245 o 246 +---------------+ 247 +----------+ | | 248 | | | Core (Topology| +----------+ 249 |Edge 3 |o--------o| aware) | | | 250 | | | Topologies |o--------o| Edge 4 | 251 +----------+ | T1 and T2 | | | 252 | | +----------+ 253 +---------------+ 254 o 255 | 256 O 257 +-----------+ 258 | | 259 |Edge 2 | 260 | | 261 | | 262 +-----------+ 264 Figure 1 MT aware interconnect 266 In the above diagram Core may be configured to connect Edge 1 and 267 Edge 2 to a different Topology than the topology of Edge 3 and Edge 268 4. 270 RBridges in Edge 1 - 4 are not required to be MT capable or aware. 271 RBridges in the core associate the corresponding links to the 272 appropriate topology. 274 4.2. Interoperability with RBridges with Non MT capable data plane 276 RBridges with Non MT capable data plane may implement MT support by 277 dedicating a separate link for each topology. 279 Alternatively, RBRidges, on point-point links may assign a different 280 next hop VLAN for different topologies and derive topology ID based 281 on VLAN. Use Next-Hop VLAN reduces the need for multiple physical 282 links. This method may be utilized as a permanent method for MT 283 encoding in Point-Pont only networks. 285 4.3. Interoperability with MT unaware RBRdiges 287 MT aware RBridges identify MT unaware RBridges with either not 288 presence of capability flags (pre RFC6326bis) or MT capability flags 289 not being set (Section 6.1. ). In such an event MT aware RBridges 290 MUST only forward traffic related to the base topology to MT unaware 291 RBridges. Additionally, proposed encoding MUST be removed prior to 292 forwarding to MT unaware RBRidges. 294 5. Backward compatibility 296 The proposed methods are encoded as part of the outer header of the 297 TRILL frame. An RBridge that is aware of the proposed extensions 298 when interfacing with an RBridge that is not capable of the proposed 299 extensions MUST remove the proposed encoding from the outer header, 300 prior to transmission of TRILL frames on those links that has 301 RBridges that are not capable of the proposed extensions. 303 6. IS-IS sub-TLV definition 305 6.1. MT capability 307 We propose to define two MT capability flags within Port TRILL 308 Version sub-TLV. 310 1. MT Encoding capability 311 2. MT to NH-VLAN Encoding capability 313 MT Encoding capability flag indicates the RBridge is capable 314 encoding MT ID using ETHTYPE-MT as defined in section 3. 316 MT to NH-VLAN Encoding capability flag indicates the announcing 317 RBRidge is capable of using NH-VLAN to MT ID mapping as presented in 318 section 3.2. 320 When both of the flags are set RBRridge SHOULD select MT Encoding 321 capability. 323 7. Security Considerations 325 TBD 327 8. Assignment Considerations 329 8.1. IANA Considerations 331 IANA is requested to allocate MT Encoding capability Flag,MT to NH- 332 VLAN Encoding capability Flags and Nickname MSB capability flag 333 under Port TRILL version sub-TLV. 335 8.2. IEEE Considerations 337 IEEE is requested to assign new Ether Type to represent MT-ETHTYPE 338 defined in section 3. 340 9. References 342 9.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RF5120] Przygienda, T. et.al , "M-ISIS: Multi Topology (MT) 348 Routing in Intermediate System to Intermediate System (IS- 349 ISs)", RFC 5120, February, 2008. 351 9.2. Informative References 353 [TRILL-MT1] Manral,V. et.al., "Multiple Topology Routing Extensions 354 for Transparent Interconnection of Lots of Links (TRILL)", 355 draft-manral-isis-trill-multi-topo-03, Work in Progress, 356 December, 2011. 358 [TRILL-MT2] Eastlake, D. et.al., "Multi Topology TRILL", draft- 359 eastlake-trill-rbridge-multi-topo-02, Work in Progress, 360 January, 2012. 362 [rfc6326bis] Eastlake, D. et.al., "Transparent Interconnection of 363 Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis- 364 rfc6326bis-02, Work in Progress, December, 2011. 366 10. Acknowledgments 368 Special acknowledgment to Dinesh Dutt, for encouragements, support 369 and coming up with the initial idea. 371 This document was prepared using 2-Word-v2.0.template.dot. 373 Authors' Addresses 375 Tissa Senevirathne 376 CISCO Systems 377 375 East Tasman Drive, 378 San Jose, CA 95134 380 Phone: +1-408-853-2291 381 Email: tsenevir@cisco.com 383 Les Ginsberg 384 CISCO Systems 385 510 McCarthy Blvd, 386 Milpitas, CA 95035. 388 Email: ginsberg@cisco.com 390 Satya Dillikar 391 CISCO Systems 392 375 East Tasman Drive, 393 San Jose, CA 95134 395 Email: dsatya@cisco.com 397 Ayan Banerjee 398 Consultant 400 Email: ayabaner@gmail.com 401 Sam Aldrin 402 HuaWei Technologies 403 2330 Central Expressway 404 Santa Clara, CA 95951, USA 406 Email: aldrin.ietf@gmail.com 408 Naveen Nimmu 409 Broadcom th 9 Floor, Building no 9, Raheja Mind space 410 Hi-Tec City, Madhapur, 411 Hyderabad - 500 081 India. 413 Email: naveen@broadcom.com