idnits 2.17.1 draft-hegde-isis-advertising-te-protocols-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 == Line 72 has weird spacing: '...transit route...' == Line 74 has weird spacing: '...ingress route...' -- The document date (March 12, 2017) is 2596 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: September 13, 2017 P. Mattes 6 M. Nanduri 7 S. Giacalone 8 Microsoft 9 I. Mohammad 10 Arista Networks 11 March 12, 2017 13 Advertising TE protocols in IS-IS 14 draft-hegde-isis-advertising-te-protocols-02 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 September 13, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 running both RSVP-TE and SR, it will be useful to communicate 184 which TE protocols are enabled on which links via BGP-LS [RFC7752] to 185 a central controller. Typically, BGP-LS relies on the IGP to 186 distribute IGP topology and traffic engineering information so that 187 only a few BGP-LS sessions with the central controller are needed. 188 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 Traffic-engineering protocol sub-TLV is added in the TLV 22 215 [RFC5305] or TLV 222 to indicate the protocols enabled on the link. 216 The sub-TLV has flags in the value field to indicate the protocol 217 enabled on the link. The length field is variable to allow the flags 218 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 However, if the SR protocol flag is set to zero on a link but the 278 adjacency-sids are advertised for that link, applications MAY use the 279 adjacency-sid for other purposes, for example OAM. 281 The ability for a receiving router to determine whether or not the 282 sending router is capable of sending the TE protocol sub-TLV is also 283 used for backward compatibility as described in Section 4. 285 An implementation that supports the TE protocol sub-TLV SHOULD be 286 able to advertise TE sub-TLVs without enabling RSVP-TE signalling on 287 the link. 289 4. Backward compatibility 291 Routers running older software that do not understand the new 292 Traffic-Engineering protocol sub-TLV will continue to interpret the 293 presence of some sub-TLVs in TLV 22 or the presence of TLV 138 as 294 meaning that RSVP is enabled a link. A network operator may not want 295 to or be able to upgrade all routers in the domain at the same time. 296 There are two backward compatibility scenarios to consider depending 297 on whether the router that doesn't understand the new TE protocol 298 sub-TLV is an RSVP-TE ingress router or an RSVP-TE transit router. 300 4.1. Scenario with upgraded RSVP-TE transit router but RSVP-TE ingress 301 router not upgraded 303 An upgraded RSVP-TE transit router is able to explicitly indicate 304 that RSVP is not enabled on a link by advertising the TE protocol 305 sub-TLV with the RSVP flag set to zero. However, an RSVP-TE ingress 306 router that has not been upgraded to understand the new TE protocol 307 sub-TLV will not understand that RSVP-TE is not enabled on the link, 308 and may include the link on a path computed for RSVP-TE. When the 309 network tries to signal an explicit path LSP using RSVP-TE through 310 that link, it will fail. In order to avoid this scenario, an 311 operator can use the mechanism described below. 313 For this scenario, the basic idea is to use the existing 314 administrative group link attribute as a means of preventing existing 315 RSVP implementations from using a link. The network operator defines 316 an administrative group to mean that RSVP is not enabled on a link. 317 We call this admin group the RSVP-not-enabled admin group. If the 318 operator needs to advertise a TE sub-TLV (maximum link bandwidth, for 319 example) on a link, but doesn't want to enable RSVP on that link, 320 then the operator also advertises the RSVP-not-enabled admin group on 321 that link. The operator can then use existing mechanisms to exclude 322 links advertising the RSVP-not-enabled admin group from the 323 constrained shortest path first (CSPF) computation used by RSVP. 324 This will prevent RSVP implementations from attempting to signal 325 RSVP-TE LSPs across links that do not have RSVP enabled. Once the 326 entire network domain is upgraded to understand the TE protocol sub- 327 TLV in this draft, the configuration involving the RSVP-not-enabled 328 admin group is no longer needed for this network. 330 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP-TE transit 331 router not upgraded 333 The other scenario to consider is when the RSVP-TE ingress router has 334 been upgraded to understand the TE protocol sub-TLV, but the RSVP-TE 335 transit router has not. In this case, the transit router has not 336 been upgraded, so it is not yet capable of sending the TE protocol 337 sub-TLV. If the transit router has RSVP-TE enabled on a link, we 338 would like for the RSVP-TE ingress router to still be able to use the 339 link for RSVP-TE paths. While it is possible to describe a solution 340 for this scenario that makes use of administrative groups, we 341 describe a simpler solution below. 343 The solution for this scenario relies on the following observation. 344 If the RSVP-TE ingress router can understand that the transit router 345 is not capable of sending the TE protocol sub-TLV, then it can 346 continue inferring whether or not RSVP-TE is enabled on the transit 347 router links based on the presence of TE sub-TLVs, just as it does 348 today. 350 To accomplish this, we require an upgraded router to send the TE 351 protocol sub-TLV if it sends TLV 22, even when both the RSVP and SR 352 flags are set to zero. In other words, whenever the TE protocol sub- 353 TLV is supported, it MUST be sent, even if no TE protocols are 354 enabled on the link. see Section 3. This allows the receiving 355 router to interpret the absence of the TE-protocol sub-TLV together 356 with presence of TLV 22 to mean that the sending router has not been 357 upgraded. This allows the upgraded RSVP-TE ingress router to 358 distinguish between transit routers that have been upgraded and those 359 that haven't. When the transit router has been upgraded, then the 360 RSVP-TE ingress router uses the information in the TE protocol sub- 361 TLV. When the transit router has not been upgraded, then RSVP-TE 362 ingress router contines to infer whether or not RSVP-TE is enabled on 363 the transit router links based on the presence of TE sub-TLVs, just 364 as it does today. The solution for this scenario requires no 365 configuration on the part of network operators. 367 4.3. Need for a long term solution 369 The use of the adminstrative group link attribute to prevent an RSVP- 370 TE ingress router from computing a path using a given link is an 371 effective short term workaround to allow networks to incrementally 372 upgrade the routers to software that understands the new TE-protocol 373 sub-TLV. One might also consider a long term solution based solely 374 on the use of operator-defined adminstrative groups to communicate 375 the TE protocol enabled on a link. However, we do not consider this 376 workaround to be an effective long term solution because it relies on 377 operator configuration that would have to be maintained in the long 378 term. As discussed in Section 2, continuing to have to infer which 379 TE protocol is enabled on a link also limits our ability to 380 communicate this information unambiguously in an interoperable manner 381 for use by other applications such as central controllers. 383 5. Security Considerations 385 This document does not introduce any further security issues other 386 than those discussed in [RFC1195] and [RFC5305]. 388 6. IANA Considerations 390 This specification updates one IS-IS registry: 392 The extended IS reachability TLV Registry 394 i) Traffic-engineering Protocol sub-tlv = Suggested value 40 396 7. Acknowledgements 398 The authors thank Alia Atlas and Les Ginsberg for helpful discissions 399 on the topic of this draft. 401 8. References 403 8.1. Normative References 405 [I-D.ietf-spring-segment-routing] 406 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 407 and R. Shakir, "Segment Routing Architecture", draft-ietf- 408 spring-segment-routing-09 (work in progress), July 2016. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 416 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 417 2008, . 419 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 420 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 421 RFC 7810, DOI 10.17487/RFC7810, May 2016, 422 . 424 8.2. Informative References 426 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 427 dual environments", RFC 1195, DOI 10.17487/RFC1195, 428 December 1990, . 430 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 431 S. Ray, "North-Bound Distribution of Link-State and 432 Traffic Engineering (TE) Information Using BGP", RFC 7752, 433 DOI 10.17487/RFC7752, March 2016, 434 . 436 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 437 Horneffer, M., and P. Sarkar, "Operational Management of 438 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 439 July 2016, . 441 Authors' Addresses 443 Shraddha Hegde 444 Juniper Networks 445 Embassy Business Park 446 Bangalore, KA 560093 447 India 449 Email: shraddha@juniper.net 451 Chris Bowers 452 Juniper Networks 453 1194 N. Mathilda Ave. 454 Sunnyvale, CA 94089 455 US 457 Email: cbowers@juniper.net 459 Paul Mattes 460 Microsoft 461 One Microsoft Way 462 Redmond, WA 98052 463 US 465 Email: pamattes@microsoft.com 466 Mohan Nanduri 467 Microsoft 468 One Microsoft Way 469 Redmond, WA 98052 470 US 472 Email: mnanduri@microsoft.com 474 Spencer Giacalone 475 Microsoft 476 One Microsoft Way 477 Redmond, WA 98052 478 US 480 Email: Spencer.Giacalone@microsoft.com 482 Imtiyaz Mohammad 483 Arista Networks 484 Global Tech Park 485 Bangalore, KA 560103 486 India 488 Email: imtiyaz@arista.com