idnits 2.17.1 draft-hegde-ospf-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 == Line 67 has weird spacing: '...transit route...' == Line 69 has weird spacing: '...ingress route...' -- The document date (October 31, 2016) is 2731 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 informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF WG S. Hegde 3 Internet-Draft C. Bowers 4 Intended status: Standards Track Juniper Networks 5 Expires: May 4, 2017 October 31, 2016 7 Advertising TE protocols in OSPF 8 draft-hegde-ospf-advertising-te-protocols-00 10 Abstract 12 This document defines a mechanism to indicate which traffic 13 engineering protocols are enabled on a link in OSPF. It does so by 14 introducing a new Traffic-Engineering Protocol sub-TLV for the Link 15 TLV in the OSPFv2 TE Opaque LSA. This document also describes 16 mechanisms to address backward compatibility issues for routers that 17 have not yet been upgraded to software that understands this new sub- 18 TLV. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Explicit and unambiguous indication of TE protocol . . . 3 63 2.2. Limit increases in link state advertisements . . . . . . 4 64 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Traffic-engineering protocol sub-TLV . . . . . . . . . . 4 66 4. Backward compatibility . . . . . . . . . . . . . . . . . . . 6 67 4.1. Scenario with upgraded RSVP-TE transit router but RSVP- 68 TE ingress router not upgraded . . . . . . . . . . . . . 6 69 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP- 70 TE transit router not upgraded . . . . . . . . . . . . . 7 71 4.3. Need for a long term solution . . . . . . . . . . . . . . 8 72 4.4. Interaction with the Extended Link Opaque LSA . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 7.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 OSPF extensions for traffic engineering are specified in [RFC3630]. 83 [RFC3630] defines several link attributes such as administrative 84 group, maximum link bandwidth, and shared risk link groups (SRLGs) 85 which can be used by traffic engineering applications. Additional 86 link attributes for traffic engineering have subsequently been 87 defined in other documents as well. Most recently [RFC7471] defined 88 link attributes for delay, loss, and measured bandwidth utilization. 89 All of the TE link attributes specified in [RFC3630] and [RFC7471] 90 are carried in sub-TLVs in the Link TLV of the TE Opaque LSA. 92 The primary consumers of these traffic engineering link attributes 93 have been RSVP-based applications that use the advertised link 94 attributes to compute paths which will subsequently be signalled 95 using RSVP-TE. However, these traffic engineering link attributes 96 have also been used by other applications, such as IP/LDP fast- 97 reroute using loop-free alternates as described in [RFC7916]. In the 98 future, it is likely that traffic engineering applications based on 99 Segment Routing [I-D.ietf-spring-segment-routing] will also use these 100 link attributes. 102 Existing OSPF standards do not provide a mechanism to explicitly 103 indicate whether or not RSVP has been enabled on a link. In general, 104 implementations have used the presence of the Link TLV in the TE 105 Opaque LSA to infer that RSVP is enabled on a link. 107 This document defines a standard way to indicate whether or not RSVP, 108 segment routing, or another future protocol is enabled on a link. In 109 this way, implementations will not have to infer whether or not RSVP 110 is enabled based on the presence of different sub-TLVs, but can use 111 the explicit indication. When network operators want to use a non- 112 RSVP traffic engineering application (such as IP/LDP FRR or segment 113 routing), they will be able to advertise traffic engineer sub-TLVs 114 and explicitly indicate what traffic engineering protocols are 115 enabled on a link. 117 2. Motivation 119 The motivation of this document is to provide a mechanism to 120 advertise TE attributes for current and future applications without 121 ambiguity. The following objectives help to accomplish this in a 122 range of deployment scenarios. 124 1. Advertise TE attributes for the link for variety of applications. 126 2. Allow the solution to be backward compatible so that nodes that 127 do not understand the new advertisement do not cause issues for 128 existing RSVP deployment. 130 3. Allow the solution to be extensible for any new applications that 131 need to look at TE attributes. 133 4. Allow the TE protocol enabled on a link to be communicated 134 unambiguously. 136 5. The solution should try to limit any increases to the quantity 137 and size of link state advertisements. 139 2.1. Explicit and unambiguous indication of TE protocol 141 Communicating unambiguously which TE protocol is enabled on a link is 142 important to be able to share this information with other consumers 143 through other protocols, aside from just the IGP. For example, for a 144 network running both RSVP-TE and SR, it will be useful to communicate 145 which TE protocols are enabled on which links via BGP-LS [RFC7752] to 146 a central controller. Typically, BGP-LS relies on the IGP to 147 distribute IGP topology and traffic engineering information so that 148 only a few BGP-LS sessions with the central controller are needed. 149 In order for a router running a BGP-LS session to a central 150 controller to correctly communicate what TE protocols are enabled on 151 the links in the IGP domain, that information first needs to be 152 communicated unambiguously within the IGP itself. 154 2.2. Limit increases in link state advertisements 156 Over the years, the size of the networks running OSPF has grown both 157 in terms of the total number of nodes as well as the number of links 158 interconnecting those nodes. OSPF has proven to be quite scalable. 159 With the advent of cloud scale computing, we expect the demands 160 placed on OSPF by network operators to continue to grow as networks 161 become larger and more richly interconnected. If we expect OSPF to 162 continue to scale to meet this challenge, then as we evolve OSPF, we 163 should be careful to limit the increases in both the quantity and 164 size of link state advertisements to the amount necessary to solve 165 the problem at hand. The solution described in this draft attempts 166 to do that. 168 3. Solution 170 3.1. Traffic-engineering protocol sub-TLV 172 A new Traffic-Engineering Protocol sub-TLV is added to the Link TLV 173 in the OSPFv2 TE Opaque LSA. The Traffic-Engineering Protocol sub- 174 TLV indicates the protocols enabled on the link. The sub-TLV has 175 flags in the value field to indicate the protocol enabled on the 176 link. The length field is variable to allow the flags field to grow 177 for future requirements. 179 Type : TBD suggested value 40 180 Length: Variable 181 Value : 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Flags | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1: Traffic-Engineering Protocol sub-TLV 190 Type : TBA (suggested value 40) 192 Length: variable (in bytes) 194 Value: The value field consists of bits indicating the protocols 195 enabled on the link. This document defines the two protocol values 196 below. 198 +----------+-------------------------------+ 199 | Value | Protocol Name | 200 +----------+-------------------------------+ 201 |0x01 | RSVP | 202 +----------+-------------------------------+ 203 |0x02 | Segment Routing | 204 +----------+-------------------------------+ 206 Figure 2: Flags for the protocols 208 The RSVP flag is set to one to indicate that RSVP-TE is enabled on a 209 link. The RSVP flag is set to zero to indicate that RSVP-TE is not 210 enabled on a link. 212 The Segment Routing flag is set to one to indicate that Segment 213 Routing is enabled on a link. The Segment Routing flag is set to 214 zero to indicate that Segment Routing is not enabled on a link. 216 All undefined flags MUST be set to zero on transmit and ignored on 217 receipt. 219 An implementation that supports the TE Protocol sub-TLV and sends the 220 Link TLV MUST advertise the TE protocol sub-TLV in the Link TLV, even 221 when both the RSVP and SR flags are set to zero. In other words, 222 whenever the TE protocol sub-TLV is supported, it MUST be sent, even 223 if no TE protocols are enabled on the link. This allows a receiving 224 router to determine whether or not the sending router is capable of 225 sending the TE Protocol sub-TLV. 227 A router supporting the TE protocol sub-TLV which receives an 228 advertisement for a link containing the Link TLV with the TE protocol 229 sub-TLV present SHOULD respect the values of the flags in the TE 230 protocol sub-TLV. The receiving router SHOULD only consider links 231 with a given TE protocol enabled for inclusion in a path using that 232 TE protocol. Conversely, links for which the TE protocol sub-TLV is 233 present, but for which the TE protocol flag is not set to one, SHOULD 234 NOT be included in any TE CSPF computations on the receiving router 235 for the protocol in question. 237 However, if the SR protocol flag is set to zero on a link but the 238 adjacency-sids are advertised for that link, applications MAY use the 239 adjacency-sid for other purposes, for example OAM. 241 The ability for a receiving router to determine whether or not the 242 sending router is capable of sending the TE protocol sub-TLV is also 243 used for backward compatibility as described in Section 4. 245 An implementation that supports the TE protocol sub-TLV SHOULD be 246 able to advertise TE attribute sub-TLVs without enabling RSVP-TE 247 signalling on the link. 249 4. Backward compatibility 251 Routers running older software that do not understand the new 252 Traffic-Engineering protocol sub-TLV will continue to interpret the 253 presence of the Link TLV in the TE Opaque LSA to mean that RSVP is 254 enabled a link. A network operator may not want to or be able to 255 upgrade all routers in the domain at the same time. There are two 256 backward compatibility scenarios to consider depending on whether the 257 router that doesn't understand the new TE protocol sub-TLV is an 258 RSVP-TE ingress router or an RSVP-TE transit router. 260 4.1. Scenario with upgraded RSVP-TE transit router but RSVP-TE ingress 261 router not upgraded 263 An upgraded RSVP-TE transit router is able to explicitly indicate 264 that RSVP is not enabled on a link by advertising the TE protocol 265 sub-TLV with the RSVP flag set to zero. However, an RSVP-TE ingress 266 router that has not been upgraded to understand the new TE protocol 267 sub-TLV will not understand that RSVP-TE is not enabled on the link, 268 and may include the link on a path computed for RSVP-TE. When the 269 network tries to signal an explicit path LSP using RSVP-TE through 270 that link, it will fail. In order to avoid this scenario, an 271 operator can use the mechanism described below. 273 For this scenario, the basic idea is to use the existing 274 administrative group link attribute as a means of preventing existing 275 RSVP implementations from using a link. The network operator defines 276 an administrative group to mean that RSVP is not enabled on a link. 277 We refer to this admin group the RSVP-not-enabled admin group. If 278 the operator needs to advertise a TE sub-TLV (maximum link bandwidth, 279 for example) on a link, but doesn't want to enable RSVP on that link, 280 then the operator also advertises the RSVP-not-enabled admin group on 281 that link. The operator can then use existing mechanisms to exclude 282 links advertising the RSVP-not-enabled admin group from the 283 constrained shortest path first (CSPF) computation used by RSVP. 284 This will prevent RSVP implementations from attempting to signal 285 RSVP-TE LSPs across links that do not have RSVP enabled. Once the 286 entire network domain is upgraded to understand the TE protocol sub- 287 TLV in this draft, the configuration involving the RSVP-not-enabled 288 admin group is no longer needed for this network. 290 To be clear, the RSVP-not-enabled admin group is an arbitrary admin 291 group chosen by a network operator for this purpose. It is not a 292 value that would need to be standardized. 294 4.2. Scenario with upgraded RSVP-TE ingress router but RSVP-TE transit 295 router not upgraded 297 The other scenario to consider is when the RSVP-TE ingress router has 298 been upgraded to understand the TE protocol sub-TLV, but the RSVP-TE 299 transit router has not. In this case, the transit router has not 300 been upgraded, so it is not yet capable of sending the TE protocol 301 sub-TLV. If the transit router has RSVP-TE enabled on a link, we 302 would like for the RSVP-TE ingress router to still be able to use the 303 link for RSVP-TE paths. While it is possible to describe a solution 304 for this scenario that makes use of administrative groups, we 305 describe a simpler solution below. 307 The solution for this scenario relies on the following observation. 308 If the RSVP-TE ingress router can understand that the transit router 309 is not capable of sending the TE protocol sub-TLV, then it can 310 continue inferring whether or not RSVP-TE is enabled on the transit 311 router links based on the presence of the Link TLV in the TE Opaque 312 LSA, just as it does today. 314 To accomplish this, we require an upgraded router to send the TE 315 protocol sub-TLV if it sends the OSPF TE Link TLV, even when both the 316 RSVP and SR flags are set to zero. In other words, whenever the TE 317 protocol sub-TLV is supported, it MUST be sent, even if no TE 318 protocols are enabled on the link. see Section 3. This allows the 319 receiving router to interpret the absence of the TE-protocol sub-TLV 320 in the OSPF TE Link TLV to mean that the sending router has not been 321 upgraded. This allows the upgraded RSVP-TE ingress router to 322 distinguish between transit routers that have been upgraded and those 323 that haven't. When the transit router has been upgraded, then the 324 RSVP-TE ingress router uses the information in the TE protocol sub- 325 TLV. When the transit router has not been upgraded, then RSVP-TE 326 ingress router contines to infer whether or not RSVP-TE is enabled on 327 the transit router links based on the presence of TE sub-TLVs, just 328 as it does today. The solution for this scenario requires no 329 configuration on the part of network operators. 331 4.3. Need for a long term solution 333 The use of the adminstrative group link attribute to prevent an RSVP- 334 TE ingress router from computing a path using a given link is an 335 effective short term workaround to allow networks to incrementally 336 upgrade the routers to software that understands the new TE-protocol 337 sub-TLV. One might also consider a long term solution based solely 338 on the use of operator-defined adminstrative groups to communicate 339 the TE protocol enabled on a link. However, we do not consider this 340 workaround to be an effective long term solution because it relies on 341 operator configuration that would have to be maintained in the long 342 term. As discussed in Section 2, continuing to have to infer which 343 TE protocol is enabled on a link would also limit our ability to 344 communicate this information unambiguously in an interoperable manner 345 for use by other applications such as central controllers. 347 4.4. Interaction with the Extended Link Opaque LSA 349 The Extended Link TLV and the Extended Link Opaque LSA were 350 introduced in [RFC7684] with the initial purpose of associating 351 Adjacency SIDs with links for segment routing. A pure segment 352 routing deployment that does not make use of any of the traffic 353 engineering attributes carried in the Link TLV in the TE Opaque LSA 354 does not need to advertise the Link TLV in the TE Opaque LSA. It 355 only needs to advertise Extended Link TLV in the Extended Link Opaque 356 LSA for the link. If the operator wants to make use of any traffic 357 engineering attributes defined for the Link TLV in the TE Opaque LSA, 358 then the routers in the network need to advertise the Link TLV in the 359 TE Opaque LSA to carry the TE attributes as well the Extended Link 360 TLV in the Extended Link Opaque LSA to carry the Adjacency SIDs. 362 5. Security Considerations 364 This document does not introduce any further security issues other 365 than those discussed in [RFC3630]. 367 6. IANA Considerations 369 This specification updates one OSPF registry: 371 The Types for sub-TLVs of the TE Link TLV Registry 373 i) Traffic-engineering Protocol sub-tlv = Suggested value 35 375 7. References 377 7.1. Normative References 379 [I-D.ietf-spring-segment-routing] 380 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 381 and R. Shakir, "Segment Routing Architecture", draft-ietf- 382 spring-segment-routing-09 (work in progress), July 2016. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 390 (TE) Extensions to OSPF Version 2", RFC 3630, 391 DOI 10.17487/RFC3630, September 2003, 392 . 394 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 395 Previdi, "OSPF Traffic Engineering (TE) Metric 396 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 397 . 399 7.2. Informative References 401 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 402 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 403 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 404 2015, . 406 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 407 S. Ray, "North-Bound Distribution of Link-State and 408 Traffic Engineering (TE) Information Using BGP", RFC 7752, 409 DOI 10.17487/RFC7752, March 2016, 410 . 412 [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., 413 Horneffer, M., and P. Sarkar, "Operational Management of 414 Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, 415 July 2016, . 417 Authors' Addresses 418 Shraddha Hegde 419 Juniper Networks 420 Embassy Business Park 421 Bangalore, KA 560093 422 India 424 Email: shraddha@juniper.net 426 Chris Bowers 427 Juniper Networks 428 1194 N. Mathilda Ave. 429 Sunnyvale, CA 94089 430 US 432 Email: cbowers@juniper.net