idnits 2.17.1 draft-hegde-isis-advertising-te-protocols-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 == Line 72 has weird spacing: '...transit route...' == Line 74 has weird spacing: '...ingress route...' -- The document date (August 17, 2016) is 2809 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) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 18, 2017 P. Mattes 6 M. Nanduri 7 S. Giacalone 8 Microsoft 9 I. Mohammad 10 Arista Networks 11 August 17, 2016 13 Advertising TE protocols in IS-IS 14 draft-hegde-isis-advertising-te-protocols-01 16 Abstract 18 This document defines a mechanism to indicate which traffic 19 engineering protocols are enabled on a link in IS-IS. It does so by 20 introducing a new traffic-engineering protocol sub-TLV for TLV-22. 21 This document also describes mechanisms to address backward 22 compatibility issues for implementations that have not yet been 23 upgraded to software that understands this new sub-TLV. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 18, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Explicit and unambiguous indication of TE protocol . . . 4 68 2.2. Limit increases in link state advertisements . . . . . . 5 69 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Traffic-engineering protocol sub-TLV . . . . . . . . . . 5 71 4. Backward compatibility . . . . . . . . . . . . . . . . . . . 7 72 4.1. Scenario with upgraded RSVP-TE transit router but RSVP- 73 TE ingress router not upgraded . . . . . . . . . . . . . 7 74 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP- 75 TE transit router not upgraded . . . . . . . . . . . . . 8 76 4.3. Need for a long term solution . . . . . . . . . . . . . . 8 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 IS-IS extensions for traffic engineering are specified in [RFC5305]. 88 [RFC5305] defines several link attributes such as administrative 89 group, maximum link bandwidth, and shared risk link groups (SRLGs) 90 which can be used by traffic engineering applications. Additional 91 link attributes for traffic engineering have subsequently been 92 defined in other documents as well. Most recently [RFC7810] defined 93 link attributes for delay, loss, and measured bandwidth utilization. 95 The primary consumers of these traffic engineering link attributes 96 have been RSVP-based applications that use the advertised link 97 attributes to compute paths which will subsequently be signalled 98 using RSVP-TE. However, these traffic engineering link attributes 99 have also been used by other applications, such as IP/LDP fast- 100 reroute using loop-free alternates as described in [RFC7916]. In the 101 future, it is likely that traffic engineering applications based on 102 Segment Routing [I-D.ietf-spring-segment-routing] will also use these 103 link attributes. 105 Existing IS-IS standards do not provide a mechanism to explicitly 106 indicate whether or not RSVP has been enabled on a link. Instead, 107 different RSVP-TE implementations have used the presence of certain 108 traffic engineering sub-TLVs in IS-IS to infer that RSVP signalling 109 is enabled on a given link. A study was conducted with various 110 vendor implementations to determine which traffic engineering sub- 111 TLVs cause an implementation to infer that RSVP signalling is enabled 112 on a link. The results are shown in Figure 1. 114 +--------+--------------------------------------------+ 115 | TLV/ | Sub-TLV name |Implementation| 116 |sub-TLV | +--------------+ 117 | | | X | Y | Z | 118 +--------+--------------------------------------------+ 119 |22 |Extended IS Reachability TLV | N | N | N | 120 |22/3 |Administrative group (color) | N | Y | Y | 121 |22/4 |Link Local/Remote ID | N | N | N | 122 |22/6 |IPV4 Interface Address | N | N | N | 123 |22/8 |IPV4 Neighbor Address | N | N | N | 124 |22/9 |Max Link Bandwidth | N | Y | Y | 125 |22/10 |Max Reservable Link Bandwidth| N | Y | Y | 126 |22/11 |Unreserved Bandwidth | Y | Y | Y | 127 |22/14 |Extended Admin Group | N | Y | N | 128 |22/18 |TE Default Metric | N | N | N | 129 |22/20 |Link Protection Type | N | Y | Y | 130 |22/21 |Interface Switching | N | Y | Y | 131 | | Capability | | | | 132 |22/22 |TE Bandwidth Constraints | N | Y | Y | 133 |22/33-39|TE Metric Extensions(RFC7180)| N | N | N | 134 |138 |SRLG TLV | N | Y | Y | 135 +--------+--------------------------------------------+ 137 Figure 1: Traffic engineering Sub-TLVs that cause implementation X, 138 Y, or Z to infer that RSVP signalling is enabled on a link 140 The study indicates that the different implementations use the 141 presence of different sub-TLVs under TLV 22 (or the presence of TLV 142 138) to infer that RSVP signalling is enabled on a link. It is 143 possible that other implementations may use other sub-TLVs to infer 144 that RSVP is enabled on a link. 146 This document defines a standard way to indicate whether or not RSVP, 147 segment routing, or another future protocol is enabled on a link. In 148 this way, implementations will not have to infer whether or not RSVP 149 is enabled based on the presence of different sub-TLVs, but can use 150 the explicit indication. When network operators want to use a non- 151 RSVP traffic engineering application (such as IP/LDP FRR or segment 152 routing), they will be able to advertise traffic engineer sub-TLVs 153 and explicitly indicate what traffic engineering protocols are 154 enabled on a link. 156 2. Motivation 158 The motivation of this document is to provide a mechanism to 159 advertise TE attributes for current and future applications without 160 ambiguity. The following objectives help to accomplish this in a 161 range of deployment scenarios. 163 1. Advertise TE attributes for the link for variety of applications. 165 2. Allow the solution to be backward compatible so that nodes that 166 do not understand the new advertisement do not cause issues for 167 existing RSVP deployment. 169 3. Allow the solution to be extensible for any new applications that 170 need to look at TE attributes. 172 4. Allow the TE protocol enabled on a link to be communicated 173 unambiguously. 175 5. The solution should try to limit any increases to the quantity 176 and size of link state advertisements. 178 2.1. Explicit and unambiguous indication of TE protocol 180 Communicating unambiguously which TE protocol is enabled on a link is 181 important to be able to share this information with other consumers 182 through other protocols, aside from just the IGP. For example, for a 183 network that running both RSVP-TE and SR, it will be useful to 184 communicate which TE protocols are enabled on which links via BGP-LS 185 [RFC7752] to a central controller. Typically, BGP-LS relies on the 186 IGP to distribute IGP topology and traffic engineering information so 187 that only a few BGP-LS sessions with the central controller are 188 needed. In order for a router running a BGP-LS session to a central 189 controller to correctly communicate what TE protocols are enabled on 190 the links in the IGP domain, that information first needs to be 191 communicated unambiguously within the IGP itself. As Figure 1 192 illustrates, that is currently not the case. 194 2.2. Limit increases in link state advertisements 196 Over the years, the size of the networks running IS-IS has grown both 197 in terms of the total number of nodes as well as the number of links 198 interconnecting those nodes. IS-IS has proven to be quite scalable, 199 running in very large networks to simultaneously support routing of 200 IPv4 and IPv6 traffic, as well as the distribution of MPLS traffic 201 engineering information. With the advent of cloud scale computing, 202 we expect the demands placed on IS-IS by network operators to 203 continue to grow as networks become larger and more richly 204 interconnected. If we expect IS-IS to continue to scale to meet this 205 challenge, then as we evolve IS-IS, we should be careful to limit the 206 increases in both the quantity and size of link state advertisements 207 to the amount necessary to solve the problem at hand. The solution 208 described in this draft attempts to do that. 210 3. Solution 212 3.1. Traffic-engineering protocol sub-TLV 214 A new sub-TLV Traffic-engineering protocol sub-TLV is added in the 215 TLV 22 [RFC5305] or TLV 222 to indicate the protocols enabled on the 216 link. The sub-TLV has flags in the value field to indicate the 217 protocol enabled on the link. The length field is variable to allow 218 the flags field to grow for future requirements. 220 Type : TBD suggested value 40 221 Length: Variable 222 Value : 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Flags | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 2: Traffic-Engineering Protocol sub-TLV 231 Type : TBA (suggested value 40) 233 Length: variable (in bytes) 234 Value: The value field consists of bits indicating the protocols 235 enabled on the link. This document defines the two protocol values 236 below. 238 +----------+-------------------------------+ 239 | Value | Protocol Name | 240 +----------+-------------------------------+ 241 |0x01 | RSVP | 242 +----------+-------------------------------+ 243 |0x02 | Segment Routing | 244 +----------+-------------------------------+ 246 Figure 3: Flags for the protocols 248 The RSVP flag is set to one to indicate that RSVP-TE is enabled on a 249 link. The RSVP flag is set to zero to indicate that RSVP-TE is not 250 enabled on a link. 252 The Segment Routing flag is set to one to indicate that Segment 253 Routing is enabled on a link. The Segment Routing flag is set to 254 zero to indicate that Segment Routing is not enabled on a link. 256 All undefined flags MUST be set to zero on transmit and ignored on 257 receipt. 259 An implementation that supports the TE protocol sub-TLV and sends TLV 260 22 MUST advertise the TE protocol sub-TLV in TLV 22 for that link, 261 even when both the RSVP and SR flags are set to zero. In other 262 words, whenever the TE protocol sub-TLV is supported, it MUST be 263 sent, even if no TE protocols are enabled on the link. This allows a 264 receiving router to determine whether or not the sending router is 265 capable of sending the TE protocol sub-TLV. 267 A router supporting the TE protocol sub-TLV which receives an 268 advertisement for a link containing TLV 22 with the TE protocol sub- 269 TLV present SHOULD respect the values of the flags in the TE protocol 270 sub-TLV. The receiving router SHOULD only consider links with a 271 given TE protocol enabled for inclusion in a path using that TE 272 protocol. Conversely, links for which the TE protocol sub-TLV is 273 present, but for which the TE protocol flag is not set to one, SHOULD 274 NOT be included in any TE CSPF computations on the receiving router 275 for the protocol in question. 277 The ability for a receiving router to determine whether or not the 278 sending router is capable of sending the TE protocol sub-TLV is also 279 used for backward compatibility as described in Section 4. 281 An implementation that supports the TE protocol sub-TLV SHOULD be 282 able to advertise TE sub-TLVs without enabling RSVP-TE signalling on 283 the link. 285 4. Backward compatibility 287 Routers running older software that do not understand the new 288 Traffic-Engineering protocol sub-TLV will continue to interpret the 289 presence of some sub-TLVs in TLV 22 or the presence of TLV 138 as 290 meaning that RSVP is enabled a link. A network operator may not want 291 to or be able to upgrade all routers in the domain at the same time. 292 There are two backward compatibility scenarios to consider depending 293 on whether the router that doesn't understand the new TE protocol 294 sub-TLV is an RSVP-TE ingress router or an RSVP-TE transit router. 296 4.1. Scenario with upgraded RSVP-TE transit router but RSVP-TE ingress 297 router not upgraded 299 An upgraded RSVP-TE transit router is able to explicitly indicate 300 that RSVP is not enabled on a link by advertising the TE protocol 301 sub-TLV with the RSVP flag set to zero. However, an RSVP-TE ingress 302 router that has not been upgraded to understand the new TE protocol 303 sub-TLV will not understand that RSVP-TE is not enabled on the link, 304 and may include the link on a path computed for RSVP-TE. When the 305 network tries to signal an explicit path LSP using RSVP-TE through 306 that link, it will fail. In order to avoid this scenario, an 307 operator can use the mechanism described below. 309 For this scenario, the basic idea is to use the existing 310 administrative group link attribute as a means of preventing existing 311 RSVP implementations from using a link. The network operator defines 312 an administrative group to mean that RSVP is not enabled on a link. 313 We call this admin group the RSVP-not-enabled admin group. If the 314 operator needs to advertise a TE sub-TLV (maximum link bandwidth, for 315 example) on a link, but doesn't want to enable RSVP on that link, 316 then the operator also advertises the RSVP-not-enabled admin group on 317 that link. The operator can then use existing mechanisms to exclude 318 links advertising the RSVP-not-enabled admin group from the 319 constrained shortest path first (CSPF) computation used by RSVP. 320 This will prevent RSVP implementations from attempting to signal 321 RSVP-TE LSPs across links that do not have RSVP enabled. Once the 322 entire network domain is upgraded to understand the TE protocol sub- 323 TLV in this draft, the configuration involving the RSVP-not-enabled 324 admin group is no longer needed for this network. 326 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP-TE transit 327 router not upgraded 329 The other scenario to consider is when the RSVP-TE ingress router has 330 been upgraded to understand the TE protocol sub-TLV, but the RSVP-TE 331 transit router has not. In this case, the transit router has not 332 been upgraded, so it is not yet capable of sending the TE protocol 333 sub-TLV. If the transit router has RSVP-TE enabled on a link, we 334 would like for the RSVP-TE ingress router to still be able to use the 335 link for RSVP-TE paths. While it is possible to describe a solution 336 for this scenario that makes use of administrative groups, we 337 describe a simpler solution below. 339 The solution for this scenario relies on the following observation. 340 If the RSVP-TE ingress router can understand that the transit router 341 is not capable of sending the TE protocol sub-TLV, then it can 342 continue inferring whether or not RSVP-TE is enabled on the transit 343 router links based on the presence of TE sub-TLVs, just as it does 344 today. 346 To accomplish this, we require an upgraded router to send the TE 347 protocol sub-TLV if it sends TLV 22, even when both the RSVP and SR 348 flags are set to zero. In other words, whenever the TE protocol sub- 349 TLV is supported, it MUST be sent, even if no TE protocols are 350 enabled on the link. see Section 3. This allows the receiving 351 router to interpret the absence of the TE-protocol sub-TLV together 352 with presence of TLV 22 to mean that the sending router has not been 353 upgraded. This allows the upgraded RSVP-TE ingress router to 354 distinguish between transit routers that have been upgraded and those 355 that haven't. When the transit router has been upgraded, then the 356 RSVP-TE ingress router uses the information in the TE protocol sub- 357 TLV. When the transit router has not been upgraded, then RSVP-TE 358 ingress router contines to infer whether or not RSVP-TE is enabled on 359 the transit router links based on the presence of TE sub-TLVs, just 360 as it does today. The solution for this scenario requires no 361 configuration on the part of network operators. 363 4.3. Need for a long term solution 365 The use of the adminstrative group link attribute to prevent an RSVP- 366 TE ingress router from computing a path using a given link is an 367 effective short term workaround to allow networks to incrementally 368 upgrade the routers to software that understands the new TE-protocol 369 sub-TLV. One might also consider a long term solution based solely 370 on the use of operator-defined adminstrative groups to communicate 371 the TE protocol enabled on a link. However, we do not consider this 372 workaround to be an effective long term solution because it relies on 373 operator configuration that would have to be maintained in the long 374 term. As discussed in Section 2, continuing to have to infer which 375 TE protocol is enabled on a link also limits our ability to 376 communicate this information unambiguously in an interoperable manner 377 for use by other applications such as central controllers. 379 5. Security Considerations 381 This document does not introduce any further security issues other 382 than those discussed in [RFC1195] and [RFC5305]. 384 6. IANA Considerations 386 This specification updates one IS-IS registry: 388 The extended IS reachability TLV Registry 390 i) Traffic-engineering Protocol sub-tlv = Suggested value 40 392 7. Acknowledgements 394 The authors thank Alia Atlas and Les Ginsberg for helpful discissions 395 on the topic of this draft. 397 8. References 399 8.1. Normative References 401 [I-D.ietf-spring-segment-routing] 402 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 403 and R. Shakir, "Segment Routing Architecture", draft-ietf- 404 spring-segment-routing-09 (work in progress), July 2016. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 412 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 413 2008, . 415 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 416 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 417 RFC 7810, DOI 10.17487/RFC7810, May 2016, 418 . 420 8.2. Informative References 422 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 423 dual environments", RFC 1195, DOI 10.17487/RFC1195, 424 December 1990, . 426 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 427 S. Ray, "North-Bound Distribution of Link-State and 428 Traffic Engineering (TE) Information Using BGP", RFC 7752, 429 DOI 10.17487/RFC7752, March 2016, 430 . 432 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 433 Horneffer, M., and P. Sarkar, "Operational Management of 434 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 435 July 2016, . 437 Authors' Addresses 439 Shraddha Hegde 440 Juniper Networks 441 Embassy Business Park 442 Bangalore, KA 560093 443 India 445 Email: shraddha@juniper.net 447 Chris Bowers 448 Juniper Networks 449 1194 N. Mathilda Ave. 450 Sunnyvale, CA 94089 451 US 453 Email: cbowers@juniper.net 455 Paul Mattes 456 Microsoft 457 One Microsoft Way 458 Redmond, WA 98052 459 US 461 Email: pamattes@microsoft.com 462 Mohan Nanduri 463 Microsoft 464 One Microsoft Way 465 Redmond, WA 98052 466 US 468 Email: mnanduri@microsoft.com 470 Spencer Giacalone 471 Microsoft 472 One Microsoft Way 473 Redmond, WA 98052 474 US 476 Email: Spencer.Giacalone@microsoft.com 478 Imtiyaz Mohammad 479 Arista Networks 480 Global Tech Park 481 Bangalore, KA 560103 482 India 484 Email: imtiyaz@arista.com