idnits 2.17.1 draft-li-ldr-bgp-request-cp-sr-te-policy-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2020) is 1508 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) == Missing Reference: 'RFC8491' is mentioned on line 115, but not defined == Missing Reference: 'IEEE.754.1985' is mentioned on line 378, but not defined == Unused Reference: 'RFC4090' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC5420' is defined on line 591, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft L. Li 4 Intended status: Standards Track Huawei 5 Expires: September 9, 2020 H. Chen 6 Futurewei 7 Y. Fan 8 Casa Systems 9 X. Liu 10 Volta Networks 11 L. Liu 12 Fujitsu 13 March 8, 2020 15 BGP Request for Candidate Paths of SR TE Policies 16 draft-li-ldr-bgp-request-cp-sr-te-policy-01 18 Abstract 20 An SR Policy is a set of candidate paths. The headend of an SR 21 Policy may learn multiple candidate paths for an SR Policy via a 22 number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 23 This document defines extensions to BGP for the headend to request 24 BGP speaker (controller) for advertising the candidate paths. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 9, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Overview of BGP Request for SR-TE Paths . . . . . . . . . . . 3 69 4. BGP Request UPDATE Message . . . . . . . . . . . . . . . . . 4 70 4.1. Extention of SR Policy NLRI . . . . . . . . . . . . . . . 4 71 4.2. New SR Policy Sub-TLVs . . . . . . . . . . . . . . . . . 5 72 4.2.1. SR Path Attributes Sub-TLV . . . . . . . . . . . . . 5 73 4.2.2. Synchronization Sub-TLV . . . . . . . . . . . . . . . 6 74 4.2.3. Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 8 75 4.2.4. Include Route Sub-TLV . . . . . . . . . . . . . . . . 9 76 4.2.5. Load Balance Sub-TLV . . . . . . . . . . . . . . . . 10 77 4.2.6. Request Parameter Sub-TLV . . . . . . . . . . . . . . 10 78 5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 8.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 An SR Policy defined in [I-D.ietf-spring-segment-routing-policy] is a 89 set of candidate paths. The headend of an SR Policy may be informed 90 by various means including: Configuration, PCEP [RFC8281] or BGP 91 [I-D.ietf-idr-segment-routing-te-policy]. All these mechanisms are 92 Controller initiated, but in some situations the headend may want to 93 pull a set of candidate paths from Controller rather than receive all 94 information passively. Actually PCEP can use request and reply 95 messages defined in [RFC5440] to match this requirement, but the 96 mechanism is not clear when controller advertises candidate paths via 97 BGP. 99 This document defines a way to request controller (BGP speaker) to 100 advertise candidate paths via BGP update messages. This makes BGP 101 have the mechanism with request and reply similar to PCEP. 103 2. Terminology 105 RP: Request Parameters 107 LSPA: LSP Attributes 109 SVEC: Synchronization VECtor 111 IRO: Include Route Object 113 ERO: Explicit Route Object 115 MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491] 117 NAI: Node or Adjacency Identifier 119 PCC: Path Computation Client 121 PCE: Path Computation Element 123 PCEP: Path Computation Element Communication Protocol 125 SID: Segment Identifier 127 SR: Segment Routing 129 SR-TE: Segment Routing Traffic Engineering 131 3. Overview of BGP Request for SR-TE Paths 133 [I-D.ietf-idr-segment-routing-te-policy] defines the extensions to 134 BGP for a headend to receive candidate paths in a BGP UPDATE message 135 from a controller (BGP speaker). In some situations a headend just 136 wants to get these candidate paths when some special event occurs 137 (for example, when it receives a customer route (VPN route) with a 138 special color or special BGP attribute). This document defines the 139 mechanism in which the headend requests the controller to advertise 140 the expected SR policy with the candidate paths when this special 141 situation occurs. 143 At first, the headend decides to get a new candidate path from the 144 controller based on some trigger event. This trigger mechanism is 145 out of scope of this document. 147 Then, the headend creates a new BGP request UPDATE message (defined 148 below in this document) and sends it to the controller. The message 149 contains the constraints/attributes of SR-TE paths such as affinity, 150 metric, SRLG, and so on. This special request UPDATE message is 151 called request message or request for short. It SHOULD NOT be used 152 for BGP best path selection. 154 After receiving the request message, the controller will calculate 155 one or a set of paths (i.e., segment lists) according to the request 156 from the headend and advertise the SR Policy with the paths computed 157 to the headend using [I-D.ietf-idr-segment-routing-te-policy]. How 158 to calculate the paths is out of scope of this document. 160 4. BGP Request UPDATE Message 162 A BGP request UPDATE message is based on the update message defined 163 in [I-D.ietf-idr-segment-routing-te-policy] with some extensions 164 described below. 166 4.1. Extention of SR Policy NLRI 168 The SR Policy NLRI defined in 169 [I-D.ietf-idr-segment-routing-te-policy] has the following format: 171 +------------------+ 172 | NLRI Length | 1 octet 173 +------------------+ 174 | Distinguisher | 4 octets 175 +------------------+ 176 | Policy Color | 4 octets 177 +------------------+ 178 | Endpoint | 4 or 16 octets 179 +------------------+ 181 where: 183 o NLRI Length: 1 octet of length expressed in bits as defined in 184 [RFC4760]. 186 o Distinguisher: 4-octet value uniquely identifying the policy in 187 the context of tuple. The distinguisher has no 188 semantic value and is solely used by the SR Policy originator to 189 make unique (from an NLRI perspective) multiple occurrences of the 190 same SR Policy. 192 o Policy Color: 4-octet value identifying (with the endpoint) the 193 policy. The color is used to match the color of the destination 194 prefixes to steer traffic into the SR Policy 195 [I-D.ietf-spring-segment-routing-policy] 197 o Endpoint: identifies the endpoint of a policy. The Endpoint may 198 represent a single node or a set of nodes (e.g., an anycast 199 address). The Endpoint is an IPv4 (4-octet) address or an IPv6 200 (16-octet) address according to the AFI of the NLRI. 202 NLRI Length, Policy Color, Endpoint field remains unchanged, while 203 the Distinguisher field will be set to FF:FF:FF:FF to indicate that 204 the UPDATE message with this NLRI is a request message to the 205 controller. 207 4.2. New SR Policy Sub-TLVs 209 The content of the SR Policy is encoded in the Tunnel Encapsulation 210 Attribute TLV of type 23 defined in [I-D.ietf-idr-tunnel-encaps] 211 containing a new Tunnel Type TLV of type 15. The SR Policy Encoding 212 structure is as follows: 214 SR Policy SAFI NLRI: 215 Attributes: 216 Tunnel Encaps Attribute (23) 217 Tunnel Type (15): SR Policy 218 220 Preference, Binding SID, Priority, Policy Name, ENLP, Segment List, 221 Weight and Segment Sub-TLVs are all defined in 222 [I-D.ietf-idr-segment-routing-te-policy] for a SR Policy to be 223 advertised to a headend. 225 Additional 6 new Sub-TLVs are defined below for the request 226 mechanism. They are SR Path Attributes, Synchronization, Metric, 227 Include Route, Load Balance, and Request Parameters Sub-TLVs. 229 4.2.1. SR Path Attributes Sub-TLV 231 A SR Path Attributes Sub-TLV contains the attributes of the SR paths 232 requested, which are similar to an LSP Attributes Object defined in 233 [RFC5440] and [RFC3209]. 235 It is optional and specifies various attributes or constraints of the 236 paths requested. Its format is shown below. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length | Flags | Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Exclude-any | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Include-any | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Include-all | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 ~ Optional sub-TLVs ~ 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 where: 254 o Type: TBD1 256 o Length: specifies the length of the value field not including Type 257 and Length fields. 259 o Flags (8 bits): No flag is currently defined. Undefined flags 260 MUST be set to zero on transmission and be ignored on receipt. 262 o Reserved (8 bits): This field MUST be set to zero on transmission 263 and be ignored on receipt. 265 o Exclude-any: A 32-bit vector representing a set of attribute 266 filters associated with a path any of which renders a link 267 unacceptable. 269 o Include-any: A 32-bit vector representing a set of attribute 270 filters associated with a path any of which renders a link 271 acceptable (with respect to this test). A null set (all bits set 272 to zero) automatically passes. 274 o Include-all: A 32-bit vector representing a set of attribute 275 filters associated with a path all of which must be present for a 276 link to be acceptable (with respect to this test). A null set 277 (all bits set to zero) automatically passes. 279 o Optional sub-TLVs: No optional sub-TLV is currently defined. 281 4.2.2. Synchronization Sub-TLV 283 A Synchronization Sub-TLV allows a headend to request the 284 synchronization of a set of M dependent or independent SR path 285 requests. This TLV is similar to the SVEC Object defined in 286 [RFC5440]. It is optional and has the following format. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | Flags |S|N|L| 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Request-ID No1 | 294 : : 295 | Request-ID NoM | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 where: 300 o Type: TBD2 302 o Length: specifies the length of the value field not including Type 303 and Length fields. 305 o Flags (16 bits): Defines the potential dependency among a set of 306 SR paths (i.e., segment lists). Three flags are defined as 307 follows: 309 * L (Link diverse) bit: when set, it indicates that the computed 310 SR paths (i.e., segment lists) MUST NOT have any link in 311 common. 313 * N (Node diverse) bit: when set, it indicates that the computed 314 SR paths (i.e., segment lists) MUST NOT have any node in 315 common. 317 * S (SRLG diverse) bit: when set, it indicates that the computed 318 SR paths (i.e., segment lists) MUST NOT share any SRLG (Shared 319 Risk Link Group). 321 o Request-ID No1, ..., NoM: each of which uniquely identifies one of 322 M SR path requests. 324 In case of M synchronized independent path requests, the bits L, N, 325 and S are set to zero. 327 Unassigned flags MUST be set to zero on transmission and MUST be 328 ignored on receipt. 330 4.2.3. Metric Sub-TLV 332 A Metric Sub-TLV carries the same content as a Metric Object defined 333 in [RFC5440] and [I-D.ietf-pce-segment-routing]. It has following 334 format: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | Flags |C|B| T | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Metric-Value (4 octets) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 o Type: TBD3. 346 o Length: specifies the length of the value field not including Type 347 and Length fields. 349 o Flags (8 bits): Two flags are currently defined: 351 * B (Bound - 1 bit): When set, the metric-value indicates a bound 352 (a maximum) for the path metric that must not be exceeded for 353 the headend to consider the computed path as acceptable. The 354 path metric must be less than or equal to the value specified 355 in the metric-value field. When the B flag is cleared, the 356 metric-value field is not used to reflect a bound constraint. 358 * C (Computed Metric - 1 bit): When set, it indicates that the 359 controller MUST provide the computed path metric value (should 360 a path satisfying the constraints be found) in the 361 advertisement message for the corresponding metric. 363 * Unassigned flags MUST be set to zero on transmission and MUST 364 be ignored on receipt. 366 o T (Type - 8 bits): Specifies the metric type. Four metric types 367 are currently defined: 369 * T=1: IGP metric 371 * T=2: TE metric 373 * T=3: Hop Counts 375 * T=11: Maximum SID Depth of the requested path 377 o Metric-Value (32 bits): It is a metric value encoded in 32 bits 378 IEEE floating point format (see [IEEE.754.1985]). 380 4.2.4. Include Route Sub-TLV 382 The Include Route Sub-TLV is optional and can be used to specify that 383 the computed candidate path MUST traverse a set of specified network 384 elements. The Include Route Sub-TLV carries the same content as IRO 385 Object defined in[RFC5440], [RFC3209] and SR-ERO defined in 386 [I-D.ietf-pce-segment-routing] 388 The Include Route Sub-TLV has following format: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length | NT | Flags |F|S|C|M| 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 ~ SID (optional) ~ 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 ~ NAI (variable, optional) ~ 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Where: 402 o Type: TBD4. 404 o Length: It specifies the length of the value field not including 405 Type and Length fields. 407 o NAI Type (NT): It indicates the type and format of the NAI 408 contained, if any is present. If the F bit is set to zero, then 409 the NT field has no meaning and MUST be ignored by the receiver. 410 This document describes the following NT values: 412 * NT=0: The NAI is absent. 414 * NT=1: The NAI is an IPv4 node ID. 416 * NT=2: The NAI is an IPv6 node ID. 418 * NT=3: The NAI is an IPv4 adjacency. 420 * NT=4: The NAI is an IPv6 adjacency with global IPv6 addresses. 422 * NT=5: The NAI is an unnumbered adjacency with IPv4 node IDs. 424 * NT=6: The NAI is an IPv6 adjacency with link-local IPv6 425 addresses. 427 o SID and NAI are the same as SR-ERO defined in 428 [I-D.ietf-pce-segment-routing] 430 4.2.5. Load Balance Sub-TLV 432 A Load Balance Sub-TLV specifies how many SR paths (i.e., segment 433 lists) should be computed for a path request. It has following 434 format: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | Flag | Max-Slist | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 ~ Optional sub-TLVs ~ 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Where: 446 o Type: TBD5. 448 o Length: It specifies the length of the value field not including 449 Type and Length fields. 451 o Flags (8 bits): No flag is currently defined. The Flags field 452 MUST be set to zero on transmission and MUST be ignored on 453 receipt. 455 o Max-Slist (8 bits): It indicates the maximum number of SR paths 456 (i.e., segment lists) to be computed for the request. The load is 457 distributed among these SR paths. 459 o Optional sub-TLVs: No Optional sub-TLV is currently defined. 461 4.2.6. Request Parameter Sub-TLV 463 A Request Parameter (RP) Sub-TLV specifies the request identifier and 464 other parameters for a path request. It has the format below. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Length | Flags |O|B|R| 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Request-ID | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 ~ Optional sub-TLVs ~ 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Where: 478 o Type: TBD6. 480 o Length: It specifies the length of the value field not including 481 Type and Length fields. 483 o Flags (16 bits): Three flag bits are currently defined as follows: 485 * R (Reoptimization - 1 bit): when set, it indicates that the SR 486 path request message is for the reoptimization of an existing 487 SR path, which is represented by a segment list Sub-TLV in the 488 message. 490 * B (Bi-directional - 1 bit): when set, it indicates that the SR 491 path request relates to bi-directional paths that has the same 492 traffic engineering requirements including fate sharing, TE 493 links, and other requirements (such as latency and jitter) in 494 each direction. 496 * O (strict/loose - 1 bit): when set, it indicates that a loose 497 path is acceptable. Otherwise (i.e., when cleared), it 498 indicates that a path exclusively made of strict hops is 499 required. 501 5. IANA 503 Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute 504 Sub-TLVs", IANA is requested to assign new Sub-TLV values for SR Path 505 Request as follows: 507 +------------+-----------------------------+-------------------+ 508 | Type Value | Sub-TLV Name | Reference | 509 +------------+-----------------------------+-------------------+ 510 | TBD1 | SR Path Attributes Sub-TLV | This document | 511 +------------+-----------------------------+-------------------+ 512 | TBD2 | Synchronization Sub-TLV | This document | 513 +------------+-----------------------------+-------------------+ 514 | TBD3 | Metric Sub-TLV | This document | 515 +------------+-----------------------------+-------------------+ 516 | TBD4 | Include Route Sub-TLV | This document | 517 +------------+-----------------------------+-------------------+ 518 | TBD5 | Load Balance Sub-TLV | This document | 519 +------------+-----------------------------+-------------------+ 520 | TBD6 | Request Parameters Sub-TLV | This document | 521 +------------+-----------------------------+-------------------+ 523 6. Contributors 525 TBD 527 7. Acknowledgments 529 TBD 531 8. References 533 8.1. Normative References 535 [I-D.ietf-idr-segment-routing-te-policy] 536 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 537 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 538 Routing Policies in BGP", draft-ietf-idr-segment-routing- 539 te-policy-08 (work in progress), November 2019. 541 [I-D.ietf-spring-segment-routing-policy] 542 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 543 P. Mattes, "Segment Routing Policy Architecture", draft- 544 ietf-spring-segment-routing-policy-06 (work in progress), 545 December 2019. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, 549 DOI 10.17487/RFC2119, March 1997, 550 . 552 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 553 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 554 DOI 10.17487/RFC5440, March 2009, 555 . 557 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 558 Computation Element Communication Protocol (PCEP) 559 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 560 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 561 . 563 8.2. Informative References 565 [I-D.ietf-idr-tunnel-encaps] 566 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 567 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 568 (work in progress), December 2019. 570 [I-D.ietf-pce-segment-routing] 571 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 572 and J. Hardwick, "PCEP Extensions for Segment Routing", 573 draft-ietf-pce-segment-routing-16 (work in progress), 574 March 2019. 576 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 577 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 578 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 579 . 581 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 582 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 583 DOI 10.17487/RFC4090, May 2005, 584 . 586 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 587 "Multiprotocol Extensions for BGP-4", RFC 4760, 588 DOI 10.17487/RFC4760, January 2007, 589 . 591 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 592 Ayyangarps, "Encoding of Attributes for MPLS LSP 593 Establishment Using Resource Reservation Protocol Traffic 594 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 595 February 2009, . 597 Authors' Addresses 599 Zhenbin Li 600 Huawei 601 156 Beiqing Road 602 Beijing, 100095 603 P.R. China 605 Email: lizhenbin@huawei.com 607 Lei Li 608 Huawei 609 156 Beiqing Road 610 Beijing, 100095 611 P.R. China 613 Email: lily.lilei@huawei.com 615 Huaimo Chen 616 Futurewei 617 Boston, MA 618 USA 620 Email: Huaimo.chen@futurewei.com 622 Yanhe Fan 623 Casa Systems 624 USA 626 Email: yfan@casa-systems.com 628 Xufeng Liu 629 Volta Networks 630 McLean, VA 631 USA 633 Email: xufeng.liu.ietf@gmail.com 635 Lei Liu 636 Fujitsu 637 USA 639 Email: liulei.kddi@gmail.com