idnits 2.17.1 draft-ketant-idr-bgp-ls-app-specific-attr-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 -- The document date (February 22, 2019) is 1862 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 (-19) exists of draft-ietf-isis-te-app-05 == Outdated reference: A later version (-16) exists of draft-ietf-ospf-te-link-attr-reuse-06 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-19) exists of draft-ietf-idr-eag-distribution-08 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing K. Talaulikar 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: August 26, 2019 J. Tantsura 6 Apstra 7 February 22, 2019 9 Application Specific Attributes Advertisement with BGP Link-State 10 draft-ketant-idr-bgp-ls-app-specific-attr-01 12 Abstract 14 Various link attributes have been defined in link-state routing 15 protocols like OSPF and IS-IS in the context of the MPLS Traffic 16 Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have 17 been defined to distribute these attributes along with other topology 18 information from these link-state routing protocols. Many of these 19 link attributes can be used for applications other than MPLS TE or 20 GMPLS. 22 Extensions to link-state routing protocols have been defined for such 23 link attributes which enable distribution of their application 24 specific values. This document defines extensions to BGP-LS address- 25 family to enable advertisement of these application specific 26 attributes as a part of the topology information from the network. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 26, 2019. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Application Specific Link Attributes TLV . . . . . . . . . . 3 72 3. Application Specific Link Attributes . . . . . . . . . . . . 5 73 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Manageability Considerations . . . . . . . . . . . . . . . . 10 77 7.1. Operational Considerations . . . . . . . . . . . . . . . 10 78 7.2. Management Considerations . . . . . . . . . . . . . . . . 10 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 10.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 Various link attributes have been defined in link-state routing 89 protocols (viz. IS-IS [RFC1195], OSPFv2 [RFC2328] and OSPFv3 90 [RFC5340] ) in the context of the MPLS traffic engineering and GMPLS. 91 All these attributes are distributed by these protocols using TLVs 92 that were originally defined for traditional MPLS Traffic Engineering 93 (i.e. using RSVP-TE [RFC3209]) or GMPLS [RFC4202] applications. 95 In recent years new applications have been introduced which have use 96 cases for many of the link attributes historically used by RSVP-TE 97 and GMPLS. Such applications include Segment Routing (SR) [RFC8402] 98 and Loop Free Alternates (LFA) [RFC5286]. This has introduced 99 ambiguity in that if a deployment includes a mix of RSVP-TE support 100 and SR support (for example) it is not possible to unambiguously 101 indicate which advertisements are to be used by RSVP-TE and which 102 advertisements are to be used by SR. If the topologies are fully 103 congruent this may not be an issue, but any incongruence leads to 104 ambiguity. An additional issue arises in cases where both 105 applications are supported on a link but the link attribute values 106 associated with each application differ. Current advertisements do 107 not support advertising application specific values for the same 108 attribute on a specific link. IGP Flexible Algorithm 109 [I-D.ietf-lsr-flex-algo] is one such application use-case that MAY 110 use application specific link attributes. 112 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] define 113 extensions for OSPF and IS-IS respectively which address these 114 issues. Also, as evolution of use cases for link attributes can be 115 expected to continue in the years to come, these documents define a 116 solution which is easily extensible to the introduction of new 117 applications and new use cases. 119 BGP Link-State extensions [RFC7752] have been specified to enable 120 distribution of the link-state topology information from the IGPs to 121 an application like a controller or Path Computation Engine (PCE) via 122 BGP. The controller/PCE gets the end to end topology information 123 across IGP domains so it can perform path computations for use-cases 124 like end to end traffic engineering (TE) using RSVP-TE or SR based 125 mechanisms. A similar challenge to what was describe above is hence 126 also faced by such centralized computation entities. 128 There is thus a need for BGP-LS extensions to also report link 129 attributes on a per application basis on the same lines as introduced 130 in the link-state routing protocols. This document defines these 131 BGP-LS extensions and also covers the backward compatibility issues 132 related to existing BGP-LS deployments. 134 2. Application Specific Link Attributes TLV 136 The BGP-LS [RFC7752] specifies the Link NLRI for advertisement of 137 links and their attributes using the BGP-LS Attribute. The 138 Application Specific Link Attributes (ASLA) TLV is a new optional 139 top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It 140 is defined such that it may act as a container for certain existing 141 and future link attributes that require to be defined in an 142 application specific scope. 144 The format of this TLV is as follows and is similar to the 145 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in 146 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] 147 respectively. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | SABML | UDABML | Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Standard Application Bit-Mask (variable) // 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | User Defined Application Bit-Mask (variable) // 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Link Attribute sub-TLVs // 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: Application Specific Link Attributes TLV 165 where: 167 o Type: TBD (see IANA Considerations Section 6) 169 o Length: variable. 171 o SABML : 1 octet value carrying the Standard Application Bit-Mask 172 Length in multiples of 4 octets. If the Standard Application Bit- 173 Mask is not present, the SABML MUST be set to 0. 175 o UDABML : 1 octet value carrying the User Defined Application Bit- 176 Mask Length in multiples of 4 octets. If the User Defined 177 Application Bit-Mask is not present, the UDABML MUST be set to 0. 179 o Standard Application Bit-Mask : variable size in multiple of 4 180 octets and optional set of bits, where each bit represents a 181 single standard application. The bits are defined in the IANA 182 "IGP Parameters" registries under the "Link Attribute 183 Applications" registry [I-D.ietf-isis-te-app]. 185 o User Defined Application Bit-Mask : variable size in multiple of 4 186 octets and optional set of bits, where each bit represents a 187 single user defined application. The bits are not managed or 188 assigned by IANA or any other standards body and are left to 189 implementation specifics. 191 o sub-TLVs : BGP-LS Attribute TLVs corresponding to the Link NLRI 192 that are application specific (as specified in Section 3) are 193 included as sub-TLVs of the ASLA TLV 195 An ASLA TLV with both the SABML and UDABML set to 0 (i.e. without any 196 application specific bitmasks) indicate that the link attribute sub- 197 TLVs that it encloses are applicable for all applications. 199 The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 200 Attribute associated with the Link NLRI of the node that originates 201 the underlying IGP link attribute TLVs/sub-TLVs. The procedures for 202 originating link attributes in the ASLA TLV from underlying IGPs is 203 specified in Section 4. 205 When the node is not running any of the IGPs but running a protocol 206 like BGP, then the link attributes for the node's local links MAY be 207 originated as part of the BGP-LS Attribute using the ASLA TLV and its 208 sub-TLVs within the Link NLRI corresponding to the local node. 210 3. Application Specific Link Attributes 212 Several BGP-LS Attribute TLVs corresponding to the Link NLRI are 213 defined in BGP-LS and more may be added in the future. The following 214 types of link attributes are required to be considered as application 215 specific. 217 o those that have different values for different applications (e.g. 218 a different TE metric value used for RSVP-TE than for SR TE) 220 o those that are applicable to multiple applications but need to be 221 used only by specific application (e.g. certain SRLG values are 222 configured on a node for LFA but the same do not need to be used 223 for RSVP-TE) 225 The following table lists the currently defined BGP-LS Attributes 226 TLVs corresponding to Link NLRI which have application specific 227 semantics. They were originally defined with semantics for RSVP-TE 228 and GMPLS applications. 230 +----------+----------------------+---------------------------------+ 231 | TLV Code | Description | Reference Document | 232 | Point | | | 233 +----------+----------------------+---------------------------------+ 234 | 1088 | Administrative group | [RFC7752] | 235 | | (color) | | 236 | 1090 | Max Reservable | [RFC7752] | 237 | | Bandwidth | | 238 | 1091 | Unreserved Bandwidth | [RFC7752] | 239 | 1092 | TE Metric | [RFC7752] | 240 | 1096 | SRLG | [RFC7752] | 241 | 1114 | Unidirectional link | [I-D.ietf-idr-te-pm-bgp] | 242 | | delay | | 243 | 1115 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 244 | | Unidirectional link | | 245 | | delay | | 246 | 1116 | Unidirectional link | [I-D.ietf-idr-te-pm-bgp] | 247 | | delay variation | | 248 | 1117 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 249 | | packet loss | | 250 | 1118 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 251 | | residual bandwidth | | 252 | 1119 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 253 | | available bandwidth | | 254 | 1120 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 255 | | bandwidth | | 256 | | utilization | | 257 | 1173 | Extended | [I-D.ietf-idr-eag-distribution] | 258 | | Administrative group | | 259 | | (color) | | 260 +----------+----------------------+---------------------------------+ 262 Table 1: BGP-LS Attribute TLVs also used as sub-TLVs of ASLA TLV 264 All the BGP-LS Attribute TLVs defined in the table above are 265 RECOMMENDED to be continued to be used at the top-level in the BGP-LS 266 Attribute for carrying attributes specific to RSVP-TE/GMPLS 267 application without the use of the ASLA TLV. 269 When a new link attribute is introduced, it may be thought of as 270 being specific to only a single application. However, down the line, 271 it may be also shared by other applications and/or require 272 application specific values. In such cases, it is RECOMMENDED to err 273 on the side of caution and define such attributes as application 274 specific to ensure flexibility in the future. 276 BGP-LS Attribute TLVs corresponding to Link NLRI that are defined in 277 the future MUST specify if they are application specific and hence 278 are REQUIRED to be encoded within an ASLA TLV. 280 Only application specific link attributes need to be advertised 281 within the ASLA TLV. Link attributes which do not have application 282 specific semantics SHOULD NOT be advertised within the ASLA TLV. 283 Receivers SHOULD ignore any non-application specific attribute sub- 284 TLVs within the ASLA TLV. 286 4. Procedures 288 The procedures described in this section apply to networks where all 289 BGP-LS originators and consumers support this specification. The 290 backward compatibility aspects and operations in deployments where 291 there are some BGP-LS originators or consumers that do not support 292 this specification is described further in Section 5. 294 The BGP-LS originator learns of the association of an application 295 specific attribute to one or more set of applications from either the 296 underlying IGP protocol LSA/LSPs from which it is sourcing the 297 topology information or from the local node configuration when 298 advertising attributes for the local node only. 300 The association of an application specific link attribute with a 301 specific application context when advertising attributes for the 302 local node only (e.g. when running BGP as the only routing protocol) 303 is an implementation specific matter and outside the scope of this 304 document. 306 [I-D.ietf-ospf-te-link-attr-reuse] and [I-D.ietf-isis-te-app] specify 307 the mechanisms for flooding of application specific link attributes 308 in OSPFv2/v3 and IS-IS respectively. These IGP specifications also 309 describe the backward compatibility aspects and the existing RSVP-TE/ 310 GMPLS specific TLV encoding mechanisms in respective protocols. 312 A BGP-LS originator node which is sourcing link-state information 313 from the underlying IGP determines the mechanism of flooding 314 application specific link attributes based on the following rules: 316 1. Application specific link attributes received from an IGP node 317 using existing RSVP-TE/GMPLS encodings only (i.e. without any 318 ASLA sub-TLV) MUST be encoded using the respective BGP-LS top- 319 level TLVs listed in Table 1 (i.e. not within ASLA TLV). When 320 the IGP node is also SR enabled then another copy of application 321 specific link attributes SHOULD be also encoded as ASLA sub-TLVs 322 with the SR application bit for them. Further rules do not apply 323 for such IGP nodes that do not use ASLA sub-TLVs in their 324 advertisements. 326 2. In case of IS-IS, when application specific link attributes are 327 received from a node with the L bit set in the ASLA sub-TLV then 328 the application specific link attributes are picked up from the 329 legacy ISIS TLVs/sub-TLVs and MUST be encoded within the BGP-LS 330 ASLA TLV as sub-TLVs with the application bitmask set as per the 331 IGP ASLA sub-TLV. When the ASLA sub-TLV with the L bit set also 332 has the RSVP-TE application bit set then the link attributes from 333 such an ASLA sub-TLV MUST be also encoded using the respective 334 BGP-LS top-level TLVs listed in Table 1 (i.e. not within ASLA 335 TLV). 337 3. In case of OSPFv2/v3, when application specific link attributes 338 are received from a node via TE LSAs then the application 339 specific link attributes from those LSAs MUST be encoded using 340 the respective BGP-LS TLVs listed in Table 1 (i.e. not within 341 ASLA TLV). 343 4. Application specific link attributes received from an IGP node 344 within its ASLA sub-TLV MUST be encoded in the BGP-LS ASLA TLV as 345 sub-TLVs with the application bitmask set as per the IGP 346 advertisement. 348 These rules ensure that a BGP-LS originator performs the translation 349 for all application specific link attributes from the IGP nodes into 350 the new BGP-LS ASLA TLVs irrespective of the IGP node supporting the 351 ASLA extension. Furthermore, it also ensures that BGP-LS TLVs 352 defined for RSVP-TE and GMPLS applications continue to be used for 353 those respective applications. 355 A BGP-LS consumer node always gets all application specific link 356 attributes corresponding to RSVP-TE and GMPLS applications as 357 existing top-level BGP-LS TLVs while for other applications they are 358 encoded in ASLA TLV(s) with appropriate applicable bit mask setting. 360 5. Backward Compatibility 362 When it comes to BGP-LS, the backward compatibility aspects are 363 associated with the originators (i.e. nodes) and consumers (e.g. 364 PCE, controllers, applications, etc.) of the topology information. 365 The originators of BGP-LS information need to ensure that their 366 encoding of application specific link attributes is done such that 367 consumers running BGP-LS implementations without this specification 368 support can still support existing applications like RSVP-TE and SR. 369 The consumers running BGP-LS implementations that support this 370 specification should also be able to work with BGP-LS originators 371 that do not support this specification and vice versa. 373 BGP-LS implementations have been originating link attributes and 374 consuming them without any application specific scoping. While the 375 ASLA TLV can be used without any backward compatibility 376 considerations for any new application (e.g. IGP Flexible Algorithm) 377 specific attribute advertisements, for existing applications like 378 RSVP-TE and SR some backward compatibility aspects need to be taken 379 care of. 381 This requires the introduction of a "compatibility mode" of 382 operations at originators of BGP-LS information for encoding of 383 information such that older implementations of BGP-LS consumers can 384 still support applications like RSVP-TE and SR. In addition to the 385 rules specified in Section 4, the following rules are to be followed 386 when operating in "compatibility mode" : 388 o Application specific link attribute received in IGP ASLA sub-TLVs, 389 corresponding to RSVP-TE or SR applications, MUST be also encoded 390 in their existing top level TLVs (as listed in Table 1) outside of 391 the ASLA TLV in addition to them being also advertised within the 392 ASLA TLV 394 o When the same application specific attribute, received in IGP ASLA 395 sub-TLVs, has different values for RSVP-TE and SR applications 396 then the value for RSVP-TE application SHOULD be preferred over 397 the value for SR application for advertisement as the top level 398 TLV (as listed in Table 1). An implementation MAY provide a knob 399 to reverse this preference. 401 It is RECOMMENDED that implementations operate in "compatibility 402 mode" by default. Implementations SHOULD have a knob for turning the 403 "compatibility mode" on or off. Operators MAY turn the 404 "compatibility mode" off when they are assured that all BGP-LS 405 consumers have been upgraded to support the extensions in this 406 document. 408 It is RECOMMENDED that the nodes which support this specification are 409 selected as originators of BGP-LS information when sourced from the 410 IGPs. 412 A BGP-LS consumer which does not implement this specification will 413 ignore the ASLA TLV and instead continue to use the attributes from 414 the existing top level TLVs. 416 A BGP-LS consumer which implements this specification SHOULD prefer 417 the application specific attribute value received via sub-TLVs within 418 the ASLA TLV over the value received via the top level TLVs. 420 6. IANA Considerations 422 This document requests assigning code-points from the registry "BGP- 423 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 424 TLVs" based on table below. The column "IS-IS TLV/Sub-TLV" defined 425 in the registry does not require any value and should be left empty. 427 +------------+------------------------------------------+----------+ 428 | Code Point | Description | Length | 429 +------------+------------------------------------------+----------+ 430 | TBD | Application Specific Link Attributes TLV | variable | 431 +------------+------------------------------------------+----------+ 433 7. Manageability Considerations 435 This section is structured as recommended in [RFC5706]. 437 The new protocol extensions introduced in this document augment the 438 existing IGP topology information that was distributed via [RFC7752]. 439 Procedures and protocol extensions defined in this document do not 440 affect the BGP protocol operations and management other than as 441 discussed in the Manageability Considerations section of [RFC7752]. 442 Specifically, the malformed NLRIs attribute tests in the Fault 443 Management section of [RFC7752] now encompass the new TLVs for the 444 BGP-LS NLRI in this document. 446 7.1. Operational Considerations 448 No additional operation considerations are defined in this document. 450 7.2. Management Considerations 452 No additional management considerations are defined in this document. 454 8. Security Considerations 456 The new protocol extensions introduced in this document augment the 457 existing IGP topology information that was distributed via [RFC7752]. 458 Procedures and protocol extensions defined in this document do not 459 affect the BGP security model other than as discussed in the Security 460 Considerations section of [RFC7752]. 462 9. Acknowledgements 464 The authors would like to thank Les Ginsberg for his review and 465 contributions to this work. 467 10. References 469 10.1. Normative References 471 [I-D.ietf-isis-te-app] 472 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 473 J. Drake, "IS-IS TE Attributes per application", draft- 474 ietf-isis-te-app-05 (work in progress), October 2018. 476 [I-D.ietf-ospf-te-link-attr-reuse] 477 Psenak, P., Lindem, A., Ginsberg, L., Henderickx, W., 478 Tantsura, J., Gredler, H., and J. Drake, "OSPF Link 479 Traffic Engineering (TE) Attribute Reuse", draft-ietf- 480 ospf-te-link-attr-reuse-06 (work in progress), November 481 2018. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 489 S. Ray, "North-Bound Distribution of Link-State and 490 Traffic Engineering (TE) Information Using BGP", RFC 7752, 491 DOI 10.17487/RFC7752, March 2016, 492 . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 10.2. Informative References 500 [I-D.ietf-idr-eag-distribution] 501 Wang, Z., Wu, Q., and J. Tantsura, "Distribution of MPLS- 502 TE Extended admin Group Using BGP", draft-ietf-idr-eag- 503 distribution-08 (work in progress), October 2018. 505 [I-D.ietf-idr-te-pm-bgp] 506 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 507 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 508 Performance Metric Extensions", draft-ietf-idr-te-pm- 509 bgp-18 (work in progress), December 2018. 511 [I-D.ietf-lsr-flex-algo] 512 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 513 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 514 algo-01 (work in progress), November 2018. 516 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 517 dual environments", RFC 1195, DOI 10.17487/RFC1195, 518 December 1990, . 520 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 521 DOI 10.17487/RFC2328, April 1998, 522 . 524 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 525 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 526 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 527 . 529 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 530 in Support of Generalized Multi-Protocol Label Switching 531 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 532 . 534 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 535 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 536 DOI 10.17487/RFC5286, September 2008, 537 . 539 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 540 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 541 . 543 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 544 Management of New Protocols and Protocol Extensions", 545 RFC 5706, DOI 10.17487/RFC5706, November 2009, 546 . 548 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 549 Decraene, B., Litkowski, S., and R. Shakir, "Segment 550 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 551 July 2018, . 553 Authors' Addresses 555 Ketan Talaulikar 556 Cisco Systems 558 Email: ketant@cisco.com 559 Peter Psenak 560 Cisco Systems 561 Slovakia 563 Email: ppsenak@cisco.com 565 Jeff Tantsura 566 Apstra 568 Email: jefftant.ietf@gmail.com