idnits 2.17.1 draft-hegde-isis-advertising-te-protocols-00.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 (August 16, 2016) is 2810 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) == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS WG S. Hegde 3 Internet-Draft C. Bowers 4 Intended status: Standards Track Juniper Networks 5 Expires: February 17, 2017 P. Mattes 6 M. Nanduri 7 Microsoft 8 I. Mohammad 9 Arista Networks 10 August 16, 2016 12 Advertising TE protocols in IS-IS 13 draft-hegde-isis-advertising-te-protocols-00 15 Abstract 17 This document defines a mechanism to indicate which traffic 18 engineering protocols are enabled on a link in IS-IS. It does so by 19 introducing a new traffic-engineering protocol sub-TLV for TLV-22. 20 This document also describes mechanisms to address backward 21 compatibility issues for implementations that have not yet been 22 upgraded to software that understands this new sub-TLV. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 17, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Traffic-engineering protocol sub-TLV . . . . . . . . . . 4 68 4. Backward compatibility . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 IS-IS extensions for traffic engineering are specified in [RFC5305]. 80 [RFC5305] defines several link attributes such as administrative 81 group, maximum link bandwidth, and shared risk link groups (SRLGs) 82 which can be used by traffic engineering applications. Additional 83 link attributes for traffic engineering have subsequently been 84 defined in other documents as well. Most recently [RFC7810] defined 85 link attributes for delay, loss, and measured bandwidth utilization. 87 The primary consumers of these traffic engineering link attributes 88 have been RSVP-based applications that use the advertised link 89 attributes to compute paths which will subsequently be signalled 90 using RSVP-TE. However, these traffic engineering link attributes 91 have also been used by other applications, such as IP/LDP fast- 92 reroute using loop-free alternates as described in [RFC7916]. In the 93 future, it is likely that traffic engineering applications based on 94 Segment Routing [I-D.ietf-spring-segment-routing] will also use these 95 link attributes. 97 Existing IS-IS standards do not provide a mechanism to explicitly 98 indicate whether or not RSVP has been enabled on a link. Instead, 99 different RSVP-TE implementations have used the presence of certain 100 traffic engineering sub-TLVs in IS-IS to infer that RSVP signalling 101 is enabled on a given link. A study was conducted with various 102 vendor implementations to determine which traffic engineering sub- 103 TLVs cause an implementation to infer that RSVP signalling is enabled 104 on a link. The results are shown in Figure 1. 106 +--------+--------------------------------------------+ 107 | TLV/ | Sub-TLV name | X | Y | Z | 108 |sub-TLV | | | | | 109 +--------+--------------------------------------------+ 110 |22 |Extended IS Reachability TLV | N | N | N | 111 |22/3 |Administrative group (color) | N | Y | Y | 112 |22/4 |Link Local/Remote ID | N | N | N | 113 |22/6 |IPV4 Interface Address | N | N | N | 114 |22/8 |IPV4 Neighbor Address | N | N | N | 115 |22/9 |Max Link Bandwidth | N | Y | Y | 116 |22/10 |Max Reservable Link Bandwidth| N | Y | Y | 117 |22/11 |Unreserved Bandwidth | Y | Y | Y | 118 |22/14 |Extended Admin Group | N | Y | N | 119 |22/18 |TE Default Metric | N | N | N | 120 |22/20 |Link Protection Type | N | Y | Y | 121 |22/21 |Interface Switching | N | Y | Y | 122 | | Capability | | | | 123 |22/22 |TE Bandwidth Constraints | N | Y | Y | 124 |22/33-39|TE Metric Extensions(RFC7180)| N | N | N | 125 |138 |SRLG TLV | N | Y | Y | 126 +--------+--------------------------------------------+ 128 Figure 1: Traffic engineering Sub-TLVs that cause implementation X, 129 Y, or Z to infer that RSVP signalling is enabled on a link 131 The study indicates that the different implementations use the 132 presence of different sub-TLVs under TLV 22 (or the presence of TLV 133 138) to infer that RSVP signalling is enabled on a link. It is 134 possible that other implementations may use other sub-TLVs to infer 135 that RSVP is enabled on a link. 137 This document defines a standard way to indicate whether or not RSVP, 138 segment routing, or another future protocol is enabled on a link. In 139 this way, implementations will not have to infer whether or not RSVP 140 is enabled based on the presence of different sub-TLVs, but can use 141 the explicit indication. When network operators want to use a non- 142 RSVP traffic engineering application (such as IP/LDP FRR or segment 143 routing), they will be able to advertise traffic engineer sub-TLVs 144 and explicitly indicate what traffic engineering protocols are 145 enabled on a link. 147 2. Motivation 149 The motivation of this document is to provide a mechanism to 150 advertise TE attributes for current and future applications without 151 ambiguity. The following objectives help to accomplish this in a 152 range of deployment scenarios. 154 1. Advertise TE attributes for the link for variety of applications. 156 2. Allow the solution to be backward compatible so that nodes that 157 do not understand the new advertisement do not cause issues for 158 existing RSVP deployment. 160 3. Allow the solution to be extensible for any new applications that 161 need to look at TE attributes. 163 3. Solution 165 3.1. Traffic-engineering protocol sub-TLV 167 A new sub-TLV Traffic-engineering protocol sub-TLV is added in the 168 TLV 22 [RFC5305] or TLV 222 to indicate the protocols enabled on the 169 link. The sub-TLV has flags in the value field to indicate the 170 protocol enabled on the link. The length field is variable to allow 171 the flags field to grow for future requirements. 173 Type : TBD suggested value 40 174 Length: Variable 175 Value : 176 0 1 2 3 177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Flags | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: Traffic-Engineering Protocol sub-TLV 184 Type : TBA (suggested value 40) 186 Length: variable (in bytes) 187 Value: The value field consists of bits indicating the protocols 188 enabled on the link. This document defines the two protocol values 189 below. 191 +----------+-------------------------------+ 192 | Value | Protocol Name | 193 +----------+-------------------------------+ 194 |0x01 | RSVP | 195 +----------+-------------------------------+ 196 |0x02 | Segment Routing | 197 +----------+-------------------------------+ 199 Figure 3: Flags for the protocols 201 The RSVP flag is set to one to indicate that RSVP-TE is enabled on a 202 link. The RSVP flag is set to zero to indicate that RSVP-TE is not 203 enabled on a link. 205 The Segment Routing flag is set to one to indicate that Segment 206 Routing is enabled on a link. The Segment Routing flag is set to 207 zero to indicate that Segment Routing is not enabled on a link. 209 All undefined flags MUST be set to zero on transmit and ignored on 210 receipt. 212 An implementation that supports the TE protocol sub-TLV and sends TLV 213 22 MUST advertise the TE protocol sub-TLV in TLV 22 for that link, 214 even when both the RSVP and SR flags are set to zero. This allows a 215 receiving router to determine whether or not the sending router is 216 capable of sending the TE protocol sub-TLV. It is used for backward 217 compatibility as described in Section 4. 219 4. Backward compatibility 221 Routers running older software that do not understand the new 222 Traffic-Engineering protocol sub-TLV will continue to interpret the 223 presence of some sub-TLVs in TLV 22 or the presence of TLV 138 as 224 meaning that RSVP is enabled a link. A network operator may not want 225 to or be able to upgrade all routers in the domain at the same time. 226 There are two backward compatibility scenarios to consider depending 227 on whether the router that doesn't understand the new TE protocol 228 sub-TLV is an RSVP-TE ingress router or an RSVP-TE transit router. 230 Suppose we have an upgraded transit router that explicitly indicates 231 that RSVP is not enabled on a link by advertising the TE protocol 232 sub-TLV with the RSVP flag set to zero. An RSVP-TE ingress router 233 that has not been upgraded to understand the new TE protocol sub-TLV 234 will not understand that RSVP-TE is not enabled on the link, and may 235 include the link on a path computed for RSVP-TE. When the network 236 tries to signal an explicit path LSP using RSVP-TE through that link, 237 it will fail. In order to avoid this scenario, an operator can use 238 the mechanism described below. 240 For this scenario, the basic idea is to use the existing 241 administrative group link attribute as a means of preventing existing 242 RSVP implementations from using a link. The network operator defines 243 an administrative group to mean that RSVP is not enabled on a link. 244 We call this admin group the RSVP-not-enabled admin group. If the 245 operator needs to advertise a TE sub-TLV (maximum link bandwidth, for 246 example) on a link, but doesn't want to enable RSVP on that link, 247 then the operator also advertises the RSVP-not-enabled admin group on 248 that link. The operator can then use existing mechanisms to exclude 249 links advertising the RSVP-not-enabled admin group from the 250 constrained shortest path first (CSPF) computation used by RSVP. 251 This will prevent RSVP implementations from attempting to signal 252 RSVP-TE LSPs across links that do not have RSVP enabled. Once the 253 entire network domain is upgraded to understand the TE protocol sub- 254 TLV in this draft, the configuration involving the RSVP-not-enabled 255 admin group is no longer needed for this network. 257 The other scenario to consider is when the RSVP-TE ingress router has 258 been upgraded to understand the TE protocol sub-TLV, but an RSVP-TE 259 transit router has not. In this case, the transit router is not 260 capable of sending the TE protocol sub-TLV. If the RSVP-TE ingress 261 router understands that the transit router is not capable of sending 262 the TE protocol sub-TLV, then it can continue inferring whether or 263 not RSVP-TE is enabled on the transit router links based on the 264 presence of TE sub-TLVs, as it does today. We require an upgraded 265 router to send the TE protocol sub-TLV if it sends TLV 22, even when 266 both the RSVP and SR flags are set to zero. This allows the 267 receiving router to interpret the absence of the TE-protocol sub-TLV 268 together with presence of TLV 22 to mean that the sending router has 269 not been upgraded. This allows the upgraded RSVP-TE ingress router 270 to distingish between transit routers that have been upgraded and 271 those that haven't, and behave accordingly. 273 5. Security Considerations 275 This document does not introduce any further security issues other 276 than those discussed in [RFC1195] and [RFC5305]. 278 6. IANA Considerations 280 This specification updates one IS-IS registry: 282 The extended IS reachability TLV Registry 284 i) Traffic-engineering Protocol sub-tlv = Suggested value 40 286 7. Acknowledgements 288 The authors thank Alia Atlas and Les Ginsberg for helpful discissions 289 on the topic of this draft. 291 8. References 293 8.1. Normative References 295 [I-D.ietf-spring-segment-routing] 296 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 297 and R. Shakir, "Segment Routing Architecture", draft-ietf- 298 spring-segment-routing-09 (work in progress), July 2016. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 306 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 307 2008, . 309 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 310 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 311 RFC 7810, DOI 10.17487/RFC7810, May 2016, 312 . 314 8.2. Informative References 316 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 317 dual environments", RFC 1195, DOI 10.17487/RFC1195, 318 December 1990, . 320 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 321 Horneffer, M., and P. Sarkar, "Operational Management of 322 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 323 July 2016, . 325 Authors' Addresses 327 Shraddha Hegde 328 Juniper Networks 329 Embassy Business Park 330 Bangalore, KA 560093 331 India 333 Email: shraddha@juniper.net 335 Chris Bowers 336 Juniper Networks 337 1194 N. Mathilda Ave. 338 Sunnyvale, CA 94089 339 US 341 Email: cbowers@juniper.net 343 Paul Mattes 344 Microsoft 345 One Microsoft Way 346 Redmond, WA 98052 347 US 349 Email: pamattes@microsoft.com 351 Mohan Nanduri 352 Microsoft 353 One Microsoft Way 354 Redmond, WA 98052 355 US 357 Email: mnanduri@microsoft.com 359 Imtiyaz Mohammad 360 Arista Networks 361 Global Tech Park 362 Bangalore, KA 560103 363 India 365 Email: imtiyaz@arista.com