idnits 2.17.1 draft-hu-trill-traffic-engineering-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 : ---------------------------------------------------------------------------- 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 (July 5, 2012) is 4306 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: 'RFC2702' is defined on line 262, but no explicit reference was found in the text == Unused Reference: 'RFC3272' is defined on line 266, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Q-2005' == Outdated reference: A later version (-09) exists of draft-eastlake-isis-rfc6326bis-01 == Outdated reference: A later version (-03) exists of draft-eastlake-trill-rbridge-multi-topo-02 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL WG Fangwei. Hu 3 Internet-Draft ZTE 4 Intended status: Standards Track Jacni. Qin 5 Expires: January 6, 2013 Cisco 6 Donald. Eastlake 3rd 7 Huawei technology 8 Radia. Perlman 9 Intel Labs 10 July 5, 2012 12 Trill Traffic Engineering 13 draft-hu-trill-traffic-engineering-01 15 Abstract 17 This document specifies the control plane procedures to support 18 Traffic Engineering (TE) in the TRILL protocol. Traffic Engineering 19 permits management configuration of the path followed by certain 20 unicast frames in a TRILL campus. 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 January 6, 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 1.1. Comparison of TE with Multi-Topology . . . . . . . . . . . 3 58 1.2. Comparison with Layer 3 IS-IS Traffic Engineering . . . . . 3 59 1.3. Requirements Language . . . . . . . . . . . . . . . . . . . 4 60 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. TRILL TE Nickname Allocation . . . . . . . . . . . . . . . . . 4 62 4. Uses of Traffic Engineering . . . . . . . . . . . . . . . . . . 4 63 4.1. Protection . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. Special Link Characteristics . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The IETF TRILL (Transparent Interconnection of Lots of Links) 76 protocol implemented by devices called RBridges (Routing Bridges, 77 [RFC6325]), provides optimal pair-wise data frame forwarding without 78 configuration, safe forwarding even during periods of temporary 79 loops, and support for multipathing of both unicast and multicast 80 traffic. TRILL accomplishes this by using IS-IS [RFC1195] link state 81 routing and encapsulating traffic using a header that includes a hop 82 count. 84 TE(Traffic Engineering) in a flexible technique that can enhance the 85 performance of an operational network at both the traffic and 86 resource. To support TE in IP networks, extensions to IS-IS 87 [RFC5305], have been specified. 89 Similarly, for TE in TRILL networks, this document describes the 90 control plane procedures and necessary extensions to IS-IS in the 91 context of TRILL protocol. 93 1.1. Comparison of TE with Multi-Topology 95 Multi-topology [I-D.eastlake-trill-rbridge-multi-topo] affects all 96 frames, multi-destination as well as known unicast. It constrains 97 frames being routed by a particular topology to certain links and, in 98 general, different costs can be provided for the same link as used in 99 different topologies. The number of available topologies is 100 typically limited due to the multiplicative effect of the number of 101 topologies on the routing computation effort. 103 Traffic Engineering applies only to unicast frames as indicated by 104 the use of a TE egress nickname in TRILL network. The forwarding for 105 such frames at each RBridge along the traffic-engineered path can be 106 statically configured or computed based on TE routing metric. 108 However, in both cases, the topology or TE status of a frame can be 109 determined from the egress nickname in the TRILL Header. 111 1.2. Comparison with Layer 3 IS-IS Traffic Engineering 113 Layer 3 IS-IS Traffic Engineering uses Router ID TLV(TLV 134) 114 [RFC5305] which is typically extracted from the IP address of a 115 loopback interface, to identify the endpoints of tunnels for Traffic 116 Engineering paths. 118 While for TRILL Traffic Engineering, there are no complicated signal 119 protocols and explicitly tunnels signaled, so some "TE Router ID TLV 120 for TRILL" is not required. 122 1.3. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Solution Overview 130 Instead of using explicitly signaled "tunnels" (e.g., MPLS LSP- 131 tunnels for TE), which will require dedicated signaling protocols 132 (e.g., RSVP-TE or CR-LDP) and additional encapsulation in forwarding 133 procedures, nicknames allocated for TE routing path are specially 134 marked in the LSP of the RBridge holding the nickname. The TE path 135 may be calculated based on the TE metrics carried by sub-TLVs inside 136 the existing Extended IS Reachability TLV (TLV type 22, defined in 137 [RFC5305] ) or may be statically configured. Ultimately, a shared 138 forwarding table is generated to maintain forwarding information for 139 the basic routing path and forwarding information for the TE routing 140 path. Other procedures of TRILL protocol for routing and 141 encapsulation are not changed. 143 How to determine whether a frame should be forwarded along least cost 144 routing path or along a particular TE egress nickname routing path is 145 out of the scope of this document. 147 3. TRILL TE Nickname Allocation 149 A dedicated space of nickname, named TE nickname MUST be allocated 150 for TE path calculation. TE nickname allocation and selection 151 procedures MUST follow what have been specified in [RFC6325]. The TE 152 nickname should be marked in the link state database for TE routing 153 path calculation. The RBridges with TE function enabled should 154 acquire both nicknames and TE nicknames. 156 This document uses Interested VLANs and Roots sub-TLV ([RFC6325]) to 157 specify TE nickname. The VID value 0xFFF reserved in 158 [IEEE802.1Q-2005], is redefined to mark the TE nicknames. 160 Another solution is to use the T flag in the nicknanme Flag Sub-TLV 161 defined in ([RFC6326bis]) to indicats that the nickname is used for 162 traffic engineering routing. 164 4. Uses of Traffic Engineering 166 Traffic Engineering is a flexible facility with a variety of uses. 168 4.1. Protection 170 Reliability is one important purpose of TE deployment. TE path can 171 be calculated as the backup path for the basic path, and used for 172 link or node protection of the basic path. The TE path is identified 173 and formed by TE nickname. When nodes or links on basic path fail, 174 frame traffic can switch to TE routing path. See the following 175 example: 177 +-----+ +-----+ basic +-----+ +-----+ 178 | RB1 |--+---| RB2 |-----------| RB3 |---+--| RB4 | 179 +-----+ | +-----+ +-----+ | +-----+ 180 | | 181 | +-----+ TE +-----+ | 182 +---| RB5 |-----------| RB6 |---+ 183 +-----+ +-----+ 185 RB1->RB2->RB3->RB4 is the primary routing path, and the nicknames of 186 RB1, RB2, RB3 and RB4 are N1, N2, N3 and N4. The TE routing path is 187 RB1-> RB5->RB6->RB4, and the TE nicknames of RB1, RB5, RB6 and RB4 188 are Nte1, Nte5, Nte6 and Nte4. If for example, RB2, or RB3, or the 189 link between RB2 and RB3 fails, when RB1 detects the failure, it 190 switches the frame traffic to the TE routes by encapsulating the 191 TRILL frame with Nte4 as the egress nickname instead of N4. The 192 frame traffic will then be forwarded based on the routing information 193 for the TE path. 195 When the basic route path is recovered or a new basic path is set up, 196 the traffic should be able to switched back over the basic route 197 path. While the switchover function should be configurable and 198 deployment specific. 200 4.2. Special Link Characteristics 202 TE can be used to send frames over paths so that the links in the 203 path have selected special characteristics. For example, assume MTU 204 testing ([RFC6325])is performed and the results reported in Extended 205 IS-IS Reachability sub-TLVs as described in ([RFC6326bis])and some 206 links in a campus can handle jumbo frames while others can only 207 handle a little over the classic Ethernet maximum. TE could then be 208 used to engineer paths that were limited to links that could handle 209 jumbo frames. 211 5. Security Considerations 213 For general TRILL Security Considerations, see([RFC6325]). 215 6. Acknowledgements 217 TBD 219 7. IANA Considerations 221 IANA is requested to allocate capability bit TBD in the TRILL-VER 222 sub-TLV capability bits ([RFC6326bis]) to indicate an RBridge has TE 223 implemented and enabled. 225 8. References 227 8.1. Normative References 229 [IEEE802.1Q-2005] 230 "IEEE Standard for Local and metropolitan area networks / 231 Virtual Bridged Local Area Networks, 802.1Q-2005", 232 May 2006. 234 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 235 dual environments", RFC 1195, December 1990. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, March 1997. 240 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 241 Engineering", RFC 5305, October 2008. 243 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 244 Ghanwani, "Routing Bridges (RBridges): Base Protocol 245 Specification", RFC 6325, July 2011. 247 [RFC6326bis] 248 Eastlake, D., Banerjee, A., Dutt, D., Ghanwani, A., and R. 249 Perlman, "Transparent Interconnection of Lots of Links 250 (TRILL) Use of IS-IS", 251 draft-eastlake-isis-rfc6326bis-01.txt, work in process, 252 Oct 2011. 254 8.2. Informative References 256 [I-D.eastlake-trill-rbridge-multi-topo] 257 Eastlake, D., Zhang, M., Perlman, R., Banerjee, A., and V. 258 Manral, "Multiple Topology TRILL", 259 draft-eastlake-trill-rbridge-multi-topo-02 (work in 260 progress), January 2012. 262 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 263 McManus, "Requirements for Traffic Engineering Over MPLS", 264 RFC 2702, September 1999. 266 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 267 Xiao, "Overview and Principles of Internet Traffic 268 Engineering", RFC 3272, May 2002. 270 Authors' Addresses 272 Fangwei Hu 273 ZTE 274 No.889 Bibo Rd 275 Shanghai, 201203 276 China 278 Phone: +86 21 68896273 279 Email: hu.fangwei@zte.com.cn 281 Jacni Qin 282 Cisco 283 Shanghai, 284 China 286 Phone: +86 1391 8619 913 287 Email: jacni@jacni.com 289 Donald Eastlake,3rd 290 Huawei technology 291 155 Beaver Street 292 Milford, MA 01757 293 USA 295 Phone: +1-508-634-2066 296 Email: d3e3e3@gmail.com 297 Radia Perlman 298 Intel Labs 299 2200 Mission College Blvd. 300 Santa Clara, CA 95054-1549 301 USA 303 Phone: +1-408-765-8080 304 Email: Radia@alum.mit.edu