idnits 2.17.1 draft-manral-isis-trill-multi-topo-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 (June 22, 2012) is 4325 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) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) == Outdated reference: A later version (-05) exists of draft-ietf-trill-rbridge-af-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Vishwas Manral 3 INTERNET-DRAFT Hewlett-Packard Co. 4 Intended status: Proposed Standard Donald Eastlake 5 Expires: December 21, 2012 Mingui Zhang 6 Huawei 7 Ayan Banerjee 8 Cisco Systems 9 June 22, 2012 11 Multiple Topology Routing Extensions for Transparent Interconnection 12 of Lots of Links (TRILL) 13 draft-manral-isis-trill-multi-topo-04.txt 15 Abstract 17 This document describes optional extensions to the TRILL protocol's 18 use of IS-IS (Intermediate System to Intermediate Systems). These 19 extensions support multiple topologies (MT) within the same TRILL 20 campus and protocol instance of IS-IS. 22 Status of This Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. Distribution of this document is 26 unlimited. Comments should be sent to the TRILL working group 27 mailing list . 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Table of Contents 47 1. Introduction............................................3 48 2. Terminology.............................................3 50 3. TLV Enhancements for Multiple Topology..................4 51 4. Multi-Topology Changes to Appointed Forwarders..........5 53 5. Security Considerations.................................6 54 6. IANA Considerations.....................................6 55 7. Acknowledgements........................................6 57 8. References..............................................7 58 8.1 Normative References...................................7 59 8.2 Informative References.................................7 61 1. Introduction 63 Maintaining Multiple Topologies (MT) in an Rbridge campus requires 64 extensions to the base TRILL protocol use of IS-IS [ISIStrill]. 65 These extensions change the packet encoding on the wire. This 66 document describes such extensions so that multiple topologies can be 67 supported as described in [RFC5120]. 69 2. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 IS-IS: Intermediate-System to Intermediate-System 77 LSP: Link State Protocol Data Unit (PDU) 79 Rbridge: Routing Bridge 81 SPF: Shortest Path First Algorithm 83 TRILL: Transparent Interconnection with Lots of Links 85 TLV: Type, Length and Value 87 3. TLV Enhancements for Multiple Topology 89 Currently the Router Capability TLV is specified in [RFC4971]. For 90 TRILL, many sub-TLV's are specified as being carried in the Router 91 Capability TLV which carries information only for a single Topology. 93 The following extensions are required to TRILL use of IS-IS to 94 support multi-topology: 96 1. The Nicknames sub-TLV, Trees sub-TLV, Tree Identifiers sub-TLV, 97 Trees Used Identifiers sub-TLV, and VLAN Group sub-TLV, MAY be 98 encapsulated in the MT-CAP TLV (TLV #144) [ISISieee]. 100 2. The Multi-Topology TLV [RFC5120] MAY be advertized in the TRILL 101 LAN Hellos and RBridge LSPs. It will contain topology identifiers 102 for one or more topologies in which the Rbridge is participating. 103 An RBridge is considered MT aware as long at it advertises at 104 least one MT TLV in its LSP. 106 3. The MTU sub-TLV [ISIStrill] MAY occur in the MT ISN TLV #222 107 [RFC5120] as well as in the Extended IS Reachability TLV #22. 109 4. The Topology Mapping (TOPO-MAP) sub-TLV, which occurs within a 110 Router Capapbilities TLV (TLV #242) for MT Aware RBridges [trill- 111 mt] is specified below. This sub-TLV may occur more than once in 112 the same or in multiple Router Capapbilities TLVs. 114 +-+-+-+-+-+-+-+-+ 115 |Type = TOPO-MAP| (1 byte) 116 +-+-+-+-+-+-+-+-+ 117 | Length | (1 byte) 118 +-+-+-+-+-+-+-+-+ 119 | RESV |TAS| (1 byte) 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |R| ABR | Topology 1 | (2 bytes) 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |R| ABR | Topology 2 | (2 bytes) 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | . . . 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |R| ABR | Topology N | (2 bytes) 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 o Type: Router Capability sub-TLV Type, set to TBD (TOPO-MAP). 132 o Length: 1 + 2*n where n is the number of topology to 133 topology mapping entries. 135 o RESV: Five reserved bits, must be sent as zero and ignored 136 on receipt. 138 o TAS: Topology Abbreviation Size as apecified in [trill-mt]. 140 o R: Reserved bit. must be sent as zero and ignored on 141 receipt. 143 o ABR, Topology: Each 2-byte mapping entries specifies that 144 ABR is the abbreviation for the 12-bit topology number 145 given. 147 4. Multi-Topology Changes to Appointed Forwarders 149 The TRILL IS-IS DRB election protocol is a bit different from Layer-3 150 IS-IS as described in [RFCadj]. The DRB corresponds to the DIS 151 (Designated Intermediate System) and is responsible for specifing the 152 Designated VLAN for communication between the RBridges on the Link 153 [RFCtrill]. As in [RFC5120], there is only one DRB on a link. 155 However, the DRB also handles all native frames being ingressed from 156 or egressed to the like, as it chooses, or may appoint other RBridges 157 on the link Appointed Forwarder [RFCaf] for one or more VLANs. 158 Appointed Forwarders are per topology. The appointed forwarder sub- 159 TLV is already a part of the MT-PORT-CAP TLV, which is Multi-Topology 160 Aware. 162 5. Security Considerations 164 The extensions to TRILL use of IS-IS specified herein add no new 165 Security Considerations beyond those already present with multi- 166 topology IS-IS and TRILL. See [RFC5120] for IS-IS multi-topology 167 security considerations. See [RFCtrill] for TRILL base protocol 168 security considerations. 170 6. IANA Considerations 172 IANA is requested to update the subregistry of the IS-IS TLV Code 173 points Registry which shows permitted occurrence of sub-TLVs within 174 TLVs #22, #141, and #222 to show that the MTU sub-TLV is permitted in 175 TLV #222 as well as in TLV #22. 177 IANA is requested to assign sub-TLV numbers within the MT-CAP TLV 178 (TLV #144) [ISISieee] for the Nicknames sub-TLV, Trees sub-TLV, Tree 179 Identifiers sub-TLV, Trees Used Identifiers sub-TLV, and VLAN Group 180 sub-TLV [ISIStrill]. Noting that there is no conflict between the 181 numbers of these sub-TLVs within the Router Capabilities TLV #242 and 182 with any other number so far assigned within the MT-CAP TLV, it is 183 requested that these sub-TLVs be assigned the same number within the 184 MT-CAP TLV as they have within the Router Capabilities TLV #242. 186 IANA is request to assign a sub-TLV number within the Router 187 Capabilities TLV (TV #242) for the TOPO-MAP sub-TLV. 189 7. Acknowledgements 191 The authors would like to thank Meenakshi Kaushik and Dinesh Dutta. 193 8. References 195 Normative and informative references for this document are given 196 below. 198 8.1 Normative References 200 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 [RFC4971] - Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 204 System to Intermediate System (IS-IS) Extensions for 205 Advertising Router Information", RFC 4971, July 2007. 207 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 208 Topology (MT) Routing in Intermediate System to Intermediate 209 Systems (IS-ISs)", RFC 5120, February 2008. 211 [RFCtrill] - R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. 212 Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- 213 trill-rbridge-protocol-16.txt, in RFC Editor queue. 215 [ISIStrill] - D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. 216 Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill-05.txt, 217 work in progress. 219 [RFCadj] - D. Eastlake, R. Perlman, A. Ghanwani, D. Dutt, V. Manral, 220 "RBridges: Adjacency", draft-ietf-trill-adj, work in progress. 222 [ISISieee] - D. Fedyk, P. Ashwood-Smith, "IS-IS Extensions Supporting 223 IEEE 802.1aq Shortest Path Bridging", draft-ietf-isis-ieee- 224 aq-05.txt, in RFC Editor queue. 226 [RFCaf] - Perlman, R., D. Eastlake, Y. Li, A. Banerjee, H. Fangwei, 227 "RBridges: Appointed Forwarders", draft-ietf-trill-rbridge- 228 af-04, work in progress. 230 [trill-mt] - Perlman, R., D. Eastlake, M. Zhang, A. Banerjee, V. 231 Manral, "RBridges: Multiple Topology TRILL", draft-eastlake- 232 trill-rbridge-multi-topo-00.txt, work in progress. 234 8.2 Informative References 236 None. 238 Authors' Addresses 240 Vishwas Manral 241 Hewlett-Packard Co. 242 19111 Pruneridge Ave. 243 Cupertino, CA 95014 USA 245 Phone: 1-408-447-0000 246 Email: vishwas.manral@hp.com 248 Donald Eastlake 3rd 249 Huawei Technologies (USA) 250 155 Beaver Street 251 Milford, MA 01757 USA 253 Phone: 1-508-333-2270 254 Email: d3e3e3@gmail.com 256 Mingui Zhang 257 Huawei Technologies Co.,Ltd 258 HuaWei Building, No.3 Xinxi Rd., Shang-Di 259 Information Industry Base, Hai-Dian District, 260 Beijing, 100085 P.R. China 262 Email: zhangmingui@huawei.com 264 Ayan Banerjee 265 Cisco Systems 266 170 West Tasman Drive 267 San Jose, CA 95134 USA 269 Email: ayabaner@cisco.com 271 Copyright and IPR Provisions 273 Copyright (c) 2011 IETF Trust and the persons identified as the 274 document authors. All rights reserved. 276 This document is subject to BCP 78 and the IETF Trust's Legal 277 Provisions Relating to IETF Documents 278 (http://trustee.ietf.org/license-info) in effect on the date of 279 publication of this document. Please review these documents 280 carefully, as they describe your rights and restrictions with respect 281 to this document. Code Components extracted from this document must 282 include Simplified BSD License text as described in Section 4.e of 283 the Trust Legal Provisions and are provided without warranty as 284 described in the Simplified BSD License. The definitive version of 285 an IETF Document is that published by, or under the auspices of, the 286 IETF. Versions of IETF Documents that are published by third parties, 287 including those that are translated into other languages, should not 288 be considered to be definitive versions of IETF Documents. The 289 definitive version of these Legal Provisions is that published by, or 290 under the auspices of, the IETF. Versions of these Legal Provisions 291 that are published by third parties, including those that are 292 translated into other languages, should not be considered to be 293 definitive versions of these Legal Provisions. For the avoidance of 294 doubt, each Contributor to the IETF Standards Process licenses each 295 Contribution that he or she makes as part of the IETF Standards 296 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 297 language to the contrary, or terms, conditions or rights that differ 298 from or are inconsistent with the rights and licenses granted under 299 RFC 5378, shall have any effect and shall be null and void, whether 300 published or posted by such Contributor, or included with or in such 301 Contribution.