idnits 2.17.1 draft-hegde-isis-advertising-te-protocols-03.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 (September 15, 2017) is 2415 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: March 19, 2018 P. Mattes 6 M. Nanduri 7 S. Giacalone 8 Microsoft 9 I. Mohammad 10 Arista Networks 11 September 15, 2017 13 Advertising TE protocols in IS-IS 14 draft-hegde-isis-advertising-te-protocols-03 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 https://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 March 19, 2018. 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 (https://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. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Explicit and unambiguous indication of TE protocol . . . 4 68 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Traffic-engineering protocol sub-TLV . . . . . . . . . . 5 70 3.2. Segment Routing flag considerations . . . . . . . . . . . 6 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 engineering sub-TLVs 153 and explicitly indicate what traffic engineering protocols are 154 enabled on a link. 156 2. Goals 158 1. The solution should allow the TE protocol enabled on a link to be 159 communicated unambiguously. 161 2. The solution should decouple the advertisement of which TE 162 protocols are enabled on a link from the advertisement of other 163 TE attributes. 165 3. The solution should be backward compatible so that nodes that do 166 not understand the new advertisement do not cause issues for 167 existing RSVP deployments. 169 4. The solution should be extensible for new protocols. 171 5. The solution should try to limit any increases to the quantity 172 and size of link state advertisements. 174 2.1. Explicit and unambiguous indication of TE protocol 176 Communicating unambiguously which TE protocol is enabled on a link is 177 important to be able to share this information with other consumers 178 through other protocols, aside from just the IGP. For example, for a 179 network running both RSVP-TE and SR, it will be useful to communicate 180 which TE protocols are enabled on which links via BGP-LS [RFC7752] to 181 a central controller. Typically, BGP-LS relies on the IGP to 182 distribute IGP topology and traffic engineering information so that 183 only a few BGP-LS sessions with the central controller are needed. 184 In order for a router running a BGP-LS session to a central 185 controller to correctly communicate what TE protocols are enabled on 186 the links in the IGP domain, that information first needs to be 187 communicated unambiguously within the IGP itself. As Figure 1 188 illustrates, that is currently not the case. 190 3. Solution 192 3.1. Traffic-engineering protocol sub-TLV 194 A new Traffic-engineering protocol sub-TLV is added in the TLV 22 195 [RFC5305] or TLV 222 to indicate the protocols enabled on the link. 196 The sub-TLV has flags in the value field to indicate the protocol 197 enabled on the link. The length field is variable to allow the flags 198 field to grow for future requirements. 200 Type : TBD suggested value 40 201 Length: Variable 202 Value : 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Flags | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: Traffic-Engineering Protocol sub-TLV 211 Type : TBA (suggested value 40) 213 Length: variable (in bytes) 215 Value: The value field consists of bits indicating the protocols 216 enabled on the link. This document defines the two protocol values 217 below. 219 +----------+-------------------------------+ 220 | Value | Protocol Name | 221 +----------+-------------------------------+ 222 |0x01 | RSVP | 223 +----------+-------------------------------+ 224 |0x02 | Segment Routing | 225 +----------+-------------------------------+ 227 Figure 3: Flags for the protocols 229 The RSVP flag is set to one to indicate that RSVP-TE is enabled on a 230 link. The RSVP flag is set to zero to indicate that RSVP-TE is not 231 enabled on a link. 233 The Segment Routing flag is set to one to indicate that Segment 234 Routing is enabled on a link. The Segment Routing flag is set to 235 zero to indicate that Segment Routing is not enabled on a link. 237 All undefined flags MUST be set to zero on transmit and ignored on 238 receipt. 240 An implementation that supports the TE protocol sub-TLV and sends TLV 241 22 MUST advertise the TE protocol sub-TLV in TLV 22 for that link, 242 even when both the RSVP and SR flags are set to zero. In other 243 words, whenever the TE protocol sub-TLV is supported, it MUST be 244 sent, even if no TE protocols are enabled on the link. This allows a 245 receiving router to determine whether or not the sending router is 246 capable of sending the TE protocol sub-TLV. 248 A router supporting the TE protocol sub-TLV which receives an 249 advertisement for a link containing TLV 22 with the TE protocol sub- 250 TLV present SHOULD respect the values of the flags in the TE protocol 251 sub-TLV. The receiving router SHOULD only consider links with a 252 given TE protocol enabled for inclusion in a path using that TE 253 protocol. Conversely, links for which the TE protocol sub-TLV is 254 present, but for which the TE protocol flag is not set to one, SHOULD 255 NOT be included in any TE CSPF computations on the receiving router 256 for the protocol in question. 258 The ability for a receiving router to determine whether or not the 259 sending router is capable of sending the TE protocol sub-TLV is also 260 used for backward compatibility as described in Section 4. 262 An implementation that supports the TE protocol sub-TLV SHOULD be 263 able to advertise TE sub-TLVs without enabling RSVP-TE signalling on 264 the link. 266 3.2. Segment Routing flag considerations 268 The Segment Routing (SR) architecture assumes that the SR topology is 269 congruent with the IGP topology. The path described by a prefix 270 segment is computed using the SPF algorithm applied to the IGP 271 topology, which is the same as the SR topology. Therefore, the 272 presence or absence of the Segment Routing flag MUST NOT be 273 interpreted as modifying the SR topology, which is always congruent 274 with the IGP topology. 276 It is however useful for a centralized application (or an ingress 277 router) to know whether or not it should expect to be able to forward 278 traffic over a given link using labels distributed via SR. If a link 279 is advertised with the TE protocol sub-TLV and the SR flag set to 280 zero, then a centralized application can assume that traffic sent 281 with a prefix segment whose path crosses that link is unlikely to be 282 forwarded across that link. With this information, a centralized 283 application can decide to use a different path for that traffic by 284 using a different label stack. 286 4. Backward compatibility 288 Routers running older software that do not understand the new 289 Traffic-Engineering protocol sub-TLV will continue to interpret the 290 presence of some sub-TLVs in TLV 22 or the presence of TLV 138 as 291 meaning that RSVP is enabled a link. A network operator may not want 292 to or be able to upgrade all routers in the domain at the same time. 293 There are two backward compatibility scenarios to consider depending 294 on whether the router that doesn't understand the new TE protocol 295 sub-TLV is an RSVP-TE ingress router or an RSVP-TE transit router. 297 4.1. Scenario with upgraded RSVP-TE transit router but RSVP-TE ingress 298 router not upgraded 300 An upgraded RSVP-TE transit router is able to explicitly indicate 301 that RSVP is not enabled on a link by advertising the TE protocol 302 sub-TLV with the RSVP flag set to zero. However, an RSVP-TE ingress 303 router that has not been upgraded to understand the new TE protocol 304 sub-TLV will not understand that RSVP-TE is not enabled on the link, 305 and may include the link on a path computed for RSVP-TE. When the 306 network tries to signal an explicit path LSP using RSVP-TE through 307 that link, it will fail. In order to avoid this scenario, an 308 operator can use the mechanism described below. 310 For this scenario, the basic idea is to use the existing 311 administrative group link attribute as a means of preventing existing 312 RSVP implementations from using a link. The network operator defines 313 an administrative group to mean that RSVP is not enabled on a link. 314 We call this admin group the RSVP-not-enabled admin group. If the 315 operator needs to advertise a TE sub-TLV (maximum link bandwidth, for 316 example) on a link, but doesn't want to enable RSVP on that link, 317 then the operator also advertises the RSVP-not-enabled admin group on 318 that link. The operator can then use existing mechanisms to exclude 319 links advertising the RSVP-not-enabled admin group from the 320 constrained shortest path first (CSPF) computation used by RSVP. 321 This will prevent RSVP implementations from attempting to signal 322 RSVP-TE LSPs across links that do not have RSVP enabled. Once the 323 entire network domain is upgraded to understand the TE protocol sub- 324 TLV in this draft, the configuration involving the RSVP-not-enabled 325 admin group is no longer needed for this network. 327 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP-TE transit 328 router not upgraded 330 The other scenario to consider is when the RSVP-TE ingress router has 331 been upgraded to understand the TE protocol sub-TLV, but the RSVP-TE 332 transit router has not. In this case, the transit router has not 333 been upgraded, so it is not yet capable of sending the TE protocol 334 sub-TLV. If the transit router has RSVP-TE enabled on a link, we 335 would like for the RSVP-TE ingress router to still be able to use the 336 link for RSVP-TE paths. While it is possible to describe a solution 337 for this scenario that makes use of administrative groups, we 338 describe a simpler solution below. 340 The solution for this scenario relies on the following observation. 341 If the RSVP-TE ingress router can understand that the transit router 342 is not capable of sending the TE protocol sub-TLV, then it can 343 continue inferring whether or not RSVP-TE is enabled on the transit 344 router links based on the presence of TE sub-TLVs, just as it does 345 today. 347 To accomplish this, we require an upgraded router to send the TE 348 protocol sub-TLV if it sends TLV 22, even when both the RSVP and SR 349 flags are set to zero. In other words, whenever the TE protocol sub- 350 TLV is supported, it MUST be sent, even if no TE protocols are 351 enabled on the link. see Section 3. This allows the receiving 352 router to interpret the absence of the TE-protocol sub-TLV together 353 with presence of TLV 22 to mean that the sending router has not been 354 upgraded. This allows the upgraded RSVP-TE ingress router to 355 distinguish between transit routers that have been upgraded and those 356 that haven't. When the transit router has been upgraded, then the 357 RSVP-TE ingress router uses the information in the TE protocol sub- 358 TLV. When the transit router has not been upgraded, then RSVP-TE 359 ingress router contines to infer whether or not RSVP-TE is enabled on 360 the transit router links based on the presence of TE sub-TLVs, just 361 as it does today. The solution for this scenario requires no 362 configuration on the part of network operators. 364 4.3. Need for a long term solution 366 The use of the adminstrative group link attribute to prevent an RSVP- 367 TE ingress router from computing a path using a given link is an 368 effective short term workaround to allow networks to incrementally 369 upgrade the routers to software that understands the new TE-protocol 370 sub-TLV. One might also consider a long term solution based solely 371 on the use of operator-defined adminstrative groups to communicate 372 the TE protocol enabled on a link. However, we do not consider this 373 workaround to be an effective long term solution because it relies on 374 operator configuration that would have to be maintained in the long 375 term. As discussed in Section 2, continuing to have to infer which 376 TE protocol is enabled on a link also limits our ability to 377 communicate this information unambiguously in an interoperable manner 378 for use by other applications such as central controllers. 380 5. Security Considerations 382 This document does not introduce any further security issues other 383 than those discussed in [RFC1195] and [RFC5305]. 385 6. IANA Considerations 387 This specification updates one IS-IS registry: 389 The extended IS reachability TLV Registry 391 i) Traffic-engineering Protocol sub-tlv = Suggested value 40 393 7. Acknowledgements 395 The authors thank Alia Atlas, Les Ginsberg, and Peter Psenak for 396 helpful discussions on the topic of this draft. 398 8. References 400 8.1. Normative References 402 [I-D.ietf-spring-segment-routing] 403 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 404 and R. Shakir, "Segment Routing Architecture", draft-ietf- 405 spring-segment-routing-09 (work in progress), July 2016. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 413 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 414 2008, . 416 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 417 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 418 RFC 7810, DOI 10.17487/RFC7810, May 2016, 419 . 421 8.2. Informative References 423 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 424 dual environments", RFC 1195, DOI 10.17487/RFC1195, 425 December 1990, . 427 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 428 S. Ray, "North-Bound Distribution of Link-State and 429 Traffic Engineering (TE) Information Using BGP", RFC 7752, 430 DOI 10.17487/RFC7752, March 2016, 431 . 433 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 434 Horneffer, M., and P. Sarkar, "Operational Management of 435 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 436 July 2016, . 438 Authors' Addresses 440 Shraddha Hegde 441 Juniper Networks 442 Embassy Business Park 443 Bangalore, KA 560093 444 India 446 Email: shraddha@juniper.net 448 Chris Bowers 449 Juniper Networks 450 1194 N. Mathilda Ave. 451 Sunnyvale, CA 94089 452 US 454 Email: cbowers@juniper.net 456 Paul Mattes 457 Microsoft 458 One Microsoft Way 459 Redmond, WA 98052 460 US 462 Email: pamattes@microsoft.com 463 Mohan Nanduri 464 Microsoft 465 One Microsoft Way 466 Redmond, WA 98052 467 US 469 Email: mnanduri@microsoft.com 471 Spencer Giacalone 472 Microsoft 473 One Microsoft Way 474 Redmond, WA 98052 475 US 477 Email: Spencer.Giacalone@microsoft.com 479 Imtiyaz Mohammad 480 Arista Networks 481 Global Tech Park 482 Bangalore, KA 560103 483 India 485 Email: imtiyaz@arista.com