idnits 2.17.1 draft-ietf-idr-te-lsp-distribution-09.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 (June 29, 2018) is 2128 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 (-22) exists of draft-ietf-spring-segment-routing-policy-01 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft 4 Intended status: Standards Track K. Talaulikar 5 Expires: December 31, 2018 Cisco Systems, Inc. 6 J. Dong, Ed. 7 M. Chen 8 Huawei Technologies 9 H. Gredler 10 RtBrick Inc. 11 J. Tantsura 12 Nuage Networks 13 June 29, 2018 15 Distribution of Traffic Engineering (TE) Policies and State using BGP-LS 16 draft-ietf-idr-te-lsp-distribution-09 18 Abstract 20 This document describes a mechanism to collect the Traffic 21 Engineering and Policy information that is locally available in a 22 node and advertise it into BGP-LS updates. Such information can be 23 used by external components for path computation, re-optimization, 24 service placement, network visualization, etc. 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 December 31, 2018. 49 Copyright Notice 51 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Carrying TE Policy Information in BGP . . . . . . . . . . . . 5 68 3. TE Policy NLRI . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. TE Policy Descriptors . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Tunnel Identifier (Tunnel ID) . . . . . . . . . . . . . . 7 71 4.2. LSP Identifier (LSP ID) . . . . . . . . . . . . . . . . . 7 72 4.3. IPv4/IPv6 Tunnel Head-End Address . . . . . . . . . . . . 8 73 4.4. IPv4/IPv6 Tunnel Tail-End Address . . . . . . . . . . . . 8 74 4.5. SR Policy Candidate Path Descriptor . . . . . . . . . . . 9 75 4.6. Local MPLS Cross Connect . . . . . . . . . . . . . . . . 11 76 4.6.1. MPLS Cross Connect Interface . . . . . . . . . . . . 12 77 4.6.2. MPLS Cross Connect FEC . . . . . . . . . . . . . . . 13 78 5. MPLS-TE Policy State TLV . . . . . . . . . . . . . . . . . . 14 79 5.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . 15 80 5.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16 81 6. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 17 82 6.1. SR Binding SID . . . . . . . . . . . . . . . . . . . . . 17 83 6.2. SR Candidate Path State . . . . . . . . . . . . . . . . . 19 84 6.3. SR Candidate Path Name . . . . . . . . . . . . . . . . . 21 85 6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 21 86 6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 23 87 6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 24 88 6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 24 89 6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 25 90 6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 27 91 6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 29 92 6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31 93 6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 37 94 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 39 95 8. Manageability Considerations . . . . . . . . . . . . . . . . 40 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 97 9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 40 98 9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 40 99 9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 41 100 9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 41 101 9.5. BGP-LS TE State Path Origin . . . . . . . . . . . . . . . 42 102 9.6. BGP-LS TE State Dataplane . . . . . . . . . . . . . . . . 42 103 9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 43 104 9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 43 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 44 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 107 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44 108 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 109 13.1. Normative References . . . . . . . . . . . . . . . . . . 44 110 13.2. Informative References . . . . . . . . . . . . . . . . . 46 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 113 1. Introduction 115 In many network environments, traffic engineering policies are 116 instantiated into various forms: 118 o MPLS Traffic Engineering Label Switched Paths (TE-LSPs). 120 o IP based tunnels (IP in IP, GRE, etc). 122 o Segment Routing Policies (SR Policy) as defined in 123 [I-D.ietf-spring-segment-routing-policy] 125 o Local MPLS cross-connect configuration 127 All this information can be grouped into the same term: TE Policies. 128 In the rest of this document we refer to TE Policies as the set of 129 information related to the various instantiation of polices: MPLS TE 130 LSPs, IP tunnels (IPv4 or IPv6), SR Policies, etc. 132 TE Polices are generally instantiated at the head-end and are based 133 on either local configuration or controller based programming of the 134 node using various APIs and protocols, e.g., PCEP or BGP. 136 In many network environments, the configuration and state of each TE 137 Policy that is available in the network is required by a controller 138 which allows the network operator to optimize several functions and 139 operations through the use of a controller aware of both topology and 140 state information. 142 One example of a controller is the stateful Path Computation Element 143 (PCE) [RFC8231], which could provide benefits in path reoptimization. 144 While some extensions are proposed in Path Computation Element 145 Communication Protocol (PCEP) for the Path Computation Clients (PCCs) 146 to report the LSP states to the PCE, this mechanism may not be 147 applicable in a management-based PCE architecture as specified in 148 section 5.5 of [RFC4655]. As illustrated in the figure below, the 149 PCC is not an LSR in the routing domain, thus the head-end nodes of 150 the TE-LSPs may not implement the PCEP protocol. In this case a 151 general mechanism to collect the TE-LSP states from the ingress LERs 152 is needed. This document proposes an TE Policy state collection 153 mechanism complementary to the mechanism defined in [RFC8231]. 155 ----------- 156 | ----- | 157 Service | | TED |<-+-----------> 158 Request | ----- | TED synchronization 159 | | | | mechanism (for example, 160 v | | | routing protocol) 161 ------------- Request/ | v | 162 | | Response| ----- | 163 | NMS |<--------+> | PCE | | 164 | | | ----- | 165 ------------- ----------- 166 Service | 167 Request | 168 v 169 ---------- Signaling ---------- 170 | Head-End | Protocol | Adjacent | 171 | Node |<---------->| Node | 172 ---------- ---------- 174 Figure 1. Management-Based PCE Usage 176 In networks with composite PCE nodes as specified in section 5.1 of 177 [RFC4655], PCE is implemented on several routers in the network, and 178 the PCCs in the network can use the mechanism described in [RFC8231] 179 to report the TE Policy information to the PCE nodes. An external 180 component may also need to collect the TE Policy information from all 181 the PCEs in the network to obtain a global view of the LSP state in 182 the network. 184 In multi-area or multi-AS scenarios, each area or AS can have a child 185 PCE to collect the TE Policies in its own domain, in addition, a 186 parent PCE needs to collect TE Policy information from multiple child 187 PCEs to obtain a global view of LSPs inside and across the domains 188 involved. 190 In another network scenario, a centralized controller is used for 191 service placement. Obtaining the TE Policy state information is 192 quite important for making appropriate service placement decisions 193 with the purpose to both meet the application's requirements and 194 utilize network resources efficiently. 196 The Network Management System (NMS) may need to provide global 197 visibility of the TE Policies in the network as part of the network 198 visualization function. 200 BGP has been extended to distribute link-state and traffic 201 engineering information to external components [RFC7752]. Using the 202 same protocol to collect Traffic Engineering Policy and state 203 information is desirable for these external components since this 204 avoids introducing multiple protocols for network information 205 collection. This document describes a mechanism to distribute 206 traffic engineering policy information (MPLS, SR, IPv4 and IPv6) to 207 external components using BGP-LS. 209 2. Carrying TE Policy Information in BGP 211 TE Policy information is advertised in BGP UPDATE messages using the 212 MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link- 213 State NLRI" defined in [RFC7752] is extended to carry the TE Policy 214 information. BGP speakers that wish to exchange TE Policy 215 information MUST use the BGP Multiprotocol Extensions Capability Code 216 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 217 [RFC4760]. New TLVs carried in the Link_State Attribute defined in 218 [RFC7752] are also defined in order to carry the attributes of a TE 219 Policy in the subsequent sections. 221 The format of "Link-State NLRI" is defined in [RFC7752] as follows: 223 0 1 2 3 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | NLRI Type | Total NLRI Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 // Link-State NLRI (variable) // 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 A new "NLRI Type" is defined for TE Policy Information as following: 235 o NLRI Type: TE Policy NLRI (value TBD see IANA Considerations 236 Section 9.1). 238 The format of this new NLRI type is defined in Section 3 below. 240 3. TE Policy NLRI 242 This document defines the new TE Policy NLRI-Type and its format as 243 shown in the following figure: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+ 248 | Protocol-ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Identifier | 251 | (64 bits) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 // Headend (Node Descriptors) // 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 // TE Policy Descriptors (variable) // 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 where: 260 o Protocol-ID field specifies the component that owns the TE Policy 261 state in the advertising node. The following new Protocol-IDs are 262 defined (values TBD see IANA Considerations Section 9.2) and apply 263 to the TE Policy NLRI: 265 +-------------+----------------------------------+ 266 | Protocol-ID | NLRI information source protocol | 267 +-------------+----------------------------------+ 268 | TBD | RSVP-TE | 269 | TBD | Segment Routing | 270 +-------------+----------------------------------+ 272 o "Identifier" is an 8 octet value as defined in [RFC7752]. 274 o "Headend" consists of a Node Descriptor defined in [RFC7752]. 276 o "TE Policy Descriptors" consists of (values TBD see IANA 277 Considerations Section 9.3): 279 +-----------+----------------------------------+ 280 | Codepoint | Descriptor TLVs | 281 +-----------+----------------------------------+ 282 | TBD | Tunnel ID | 283 | TBD | LSP ID | 284 | TBD | IPv4/6 Tunnel Head-end address | 285 | TBD | IPv4/6 Tunnel Tail-end address | 286 | TBD | SR Policy Candidate Path | 287 | TBD | Local MPLS Cross Connect | 288 +-----------+----------------------------------+ 290 4. TE Policy Descriptors 292 This sections defines the TE Policy Descriptors TLVs which are used 293 to describe the TE Policy being advertised by using the new BGP-LS TE 294 Policy NLRI type defined in Section 3. 296 4.1. Tunnel Identifier (Tunnel ID) 298 The Tunnel Identifier TLV contains the Tunnel ID defined in [RFC3209] 299 and is used for RSVP-TE protocol TE Policies. It has the following 300 format: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Tunnel ID | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 where: 312 o Type: TBD (see IANA Considerations Section 9.3) 314 o Length: 2 octets. 316 o Tunnel ID: 2 octets as defined in [RFC3209]. 318 4.2. LSP Identifier (LSP ID) 320 The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and 321 is used for RSVP-TE protocol TE Policies. It has the following 322 format: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | LSP ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 where: 334 o Type: TBD (see IANA Considerations Section 9.3) 336 o Length: 2 octets. 338 o LSP ID: 2 octets as defined in [RFC3209]. 340 4.3. IPv4/IPv6 Tunnel Head-End Address 342 The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head- 343 End Address defined in [RFC3209] and is used for RSVP-TE protocol TE 344 Policies. It has following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 // IPv4/IPv6 Tunnel Head-End Address (variable) // 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 where: 356 o Type: TBD (see IANA Considerations Section 9.3) 358 o Length: 4 or 16 octets. 360 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4 361 address, its length is 4 (octets). 363 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6 364 address, its length is 16 (octets). 366 4.4. IPv4/IPv6 Tunnel Tail-End Address 368 The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel Tail- 369 End Address defined in [RFC3209] and is used for RSVP-TE protocol TE 370 Policies. It has following format: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 // IPv4/IPv6 Tunnel Tail-End Address (variable) // 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 where: 382 o Type: TBD (see IANA Considerations Section 9.3) 384 o Length: 4 or 16 octets. 386 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4 387 address, its length is 4 (octets). 389 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6 390 address, its length is 16 (octets). 392 4.5. SR Policy Candidate Path Descriptor 394 The SR Policy Candidate Path Descriptor TLV identifies a Segment 395 Routing Policy candidate path (CP) as defined in 396 [I-D.ietf-spring-segment-routing-policy] and has the following 397 format: 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |Protocol-origin| Flags | RESERVED | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Endpoint (4 or 16 octets) // 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Policy Color (4 octets) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Originator AS Number (4 octets) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Originator Address (4 or 16 octets) // 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Discriminator (4 octets) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 where: 419 o Type: TBD (see IANA Considerations Section 9.3) 420 o Length: variable (valid values are 24, 36 or 48 octets) 422 o Protocol-Origin : 1 octet field which identifies the protocol or 423 component which is responsible for the instantiation of this path. 424 Following protocol-origin codepoints are defined in this document. 426 +------------+---------------------------------------------------------+ 427 | Code Point | Protocol Origin | 428 +------------+---------------------------------------------------------+ 429 | 1 | PCEP | 430 | 2 | BGP SR Policy | 431 | 3 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) | 432 +------------+---------------------------------------------------------+ 434 o Flags: 1 octet field with following bit positions defined. Other 435 bits SHOULD be cleared by originator and MUST be ignored by 436 receiver. 438 0 1 2 3 4 5 6 7 439 +-+-+-+-+-+-+-+-+ 440 |E|O| | 441 +-+-+-+-+-+-+-+-+ 443 where: 445 * E-Flag : Indicates the encoding of endpoint as IPv6 address 446 when SET and IPv4 address when CLEAR 448 * O-Flag : Indicates the encoding of originator address as IPv6 449 address when SET and IPv4 address when CLEAR 451 o Reserved : 2 octets which SHOULD be set to 0 by originator and 452 MUST be ignored by receiver. 454 o Endpoint : 4 or 16 octets (as indicated by the flags) containing 455 the address of the endpoint of the SR Policy 457 o Color : 4 octets that indicates the color of the SR Policy 459 o Originator ASN : 4 octets to carry the 4 byte encoding of the ASN 460 of the originator. Refer [I-D.ietf-spring-segment-routing-policy] 461 Sec 2.4 for details. 463 o Originator Address : 4 or 16 octets (as indicated by the flags) to 464 carry the address of the originator. Refer 465 [I-D.ietf-spring-segment-routing-policy] Sec 2.4 for details. 467 o Discriminator : 4 octets to carry the discrimator of the path. 468 Refer [I-D.ietf-spring-segment-routing-policy] Sec 2.5 for 469 details. 471 4.6. Local MPLS Cross Connect 473 The Local MPLS Cross Connect TLV identifies a local MPLS state in the 474 form of incoming label and interface followed by an outgoing label 475 and interface. Outgoing interface may appear multiple times (for 476 multicast states). It is used with Protocol ID set to "Static 477 Configuration" value 5 as defined in [RFC7752]. 479 The Local MPLS Cross Connect TLV has the following format: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Incoming label (4 octets) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Outgoing label (4 octets) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 // Sub-TLVs (variable) // 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 where: 495 o Type: TBD (see IANA Considerations Section 9.3) 497 o Length: variable. 499 o Incoming and Outgoing labels: 4 octets each. 501 o Sub-TLVs: following Sub-TLVs are defined: 503 * Interface Sub-TLV 505 * Forwarding Equivalent Class (FEC) 507 The Local MPLS Cross Connect TLV: 509 MUST have an incoming label. 511 MUST have an outgoing label. 513 MAY contain an Interface Sub-TLV having the I-flag set. 515 MUST contain at least one Interface Sub-TLV having the I-flag 516 unset. 518 MAY contain multiple Interface Sub-TLV having the I-flag unset. 519 This is the case of a multicast MPLS cross connect. 521 MAY contain a FEC Sub-TLV. 523 The following sub-TLVs are defined for the Local MPLS Cross Connect 524 TLV (values TBD see IANA Considerations Section 9.3): 526 +-----------+----------------------------------+ 527 | Codepoint | Descriptor TLV | 528 +-----------+----------------------------------+ 529 | TBD | MPLS Cross Connect Interface | 530 | TBD | MPLS Cross Connect FEC | 531 +-----------+----------------------------------+ 533 These are defined in the following sub-sections. 535 4.6.1. MPLS Cross Connect Interface 537 The MPLS Cross Connect Interface sub-TLV is optional and contains the 538 identifier of the interface (incoming or outgoing) in the form of an 539 IPv4 address or an IPv6 address. 541 The MPLS Cross Connect Interface sub-TLV has the following format: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 +-+-+-+-+-+-+-+-+ 550 | Flags | 551 +-+-+-+-+-+-+-+-+ 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Local Interface Identifier (4 octets) | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 // Interface Address (4 or 16 octets) // 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 where: 561 o Type: TBD (see IANA Considerations Section 9.3) 562 o Length: 9 or 21. 564 o Flags: 1 octet of flags defined as follows: 566 0 1 2 3 4 5 6 7 567 +-+-+-+-+-+-+-+-+ 568 |I| | 569 +-+-+-+-+-+-+-+-+ 571 where: 573 * I-Flag is the Interface flag. When set, the Interface Sub-TLV 574 describes an incoming interface. If the I-flag is not set, 575 then the Interface Sub-TLV describes an outgoing interface. 577 o Local Interface Identifier: a 4 octet identifier. 579 o Interface address: a 4 octet IPv4 address or a 16 octet IPv6 580 address. 582 4.6.2. MPLS Cross Connect FEC 584 The MPLS Cross Connect FEC sub-TLV is optional and contains the FEC 585 associated to the incoming label. 587 The MPLS Cross Connect FEC sub-TLV has the following format: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Flags | Masklength | Prefix (variable) // 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 // Prefix (variable) // 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 where: 601 o Type: TBD (see IANA Considerations Section 9.3) 603 o Length: variable. 605 o Flags: 1 octet of flags defined as follows: 607 0 1 2 3 4 5 6 7 608 +-+-+-+-+-+-+-+-+ 609 |4| | 610 +-+-+-+-+-+-+-+-+ 612 where: 614 * 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes 615 an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV 616 describes an IPv6 FEC. 618 o Mask Length: 1 octet of prefix length. 620 o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the " 621 Mask Length" field. 623 5. MPLS-TE Policy State TLV 625 A new TLV called "MPLS-TE Policy State TLV", is used to describe the 626 characteristics of the MPLS-TE Policy and it is carried in the 627 optional non-transitive BGP Attribute "LINK_STATE Attribute" defined 628 in [RFC7752]. These MPLS-TE Policy characteristics include the 629 characteristics and attributes of the policy, it's dataplane, 630 explicit path, Quality of Service (QoS) parameters, route 631 information, the protection mechanisms, etc. 633 The MPLS-TE Policy State TLV has the following format: 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type | Length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Path-origin | Dataplane | RESERVED | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 // MPLS-TE Policy State Objects (variable) // 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 where: 649 MPLS-TE Policy State TLV 651 o Type: TBD (see IANA Considerations Section 9.3) 653 o Length: the total length of the MPLS-TE Policy State TLV not 654 including Type and Length fields. 656 o Path-origin: identifies the component (or protocol) from which the 657 contained object originated. This allows for objects defined in 658 different components to be collected while avoiding the possible 659 codepoint collisions among these components. Following path- 660 origin codepoints are defined in this document. 662 +----------+------------------+ 663 | Code | Path | 664 | Point | Origin | 665 +----------+------------------+ 666 | 1 | RSVP-TE | 667 | 2 | PCEP | 668 | 3 | Local/Static | 669 +----------+------------------+ 671 o Dataplane: describes to which dataplane the policy is applied to. 672 The following dataplane values are defined in this document: 674 +----------+------------------+ 675 | Code | Dataplane | 676 | Point | | 677 +----------+------------------+ 678 | 1 | MPLS-IPv4 | 679 | 2 | MPLS-IPv6 | 680 +----------+------------------+ 682 o RESERVED: 16-bit field. SHOULD be set to 0 on transmission and 683 MUST be ignored on receipt. 685 o TE Policy State Objects: Rather than replicating all these objects 686 in this document, the semantics and encodings of the objects as 687 defined in RSVP-TE and PCEP are reused. 689 The state information is carried in the "MPLS-TE Policy State 690 Objects" with the following format as described in the sub-sections 691 below. 693 5.1. RSVP Objects 695 RSVP-TE objects are encoded in the "MPLS-TE Policy State Objects" 696 field of the MPLS-TE Policy State TLV and consists of MPLS TE LSP 697 objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than 698 replicating all MPLS TE LSP related objects in this document, the 699 semantics and encodings of the MPLS TE LSP objects are re-used. 700 These MPLS TE LSP objects are carried in the MPLS-TE Policy State 701 TLV. 703 When carrying RSVP-TE objects, the "Path-Origin" field is set to 704 "RSVP-TE". 706 The following RSVP-TE Objects are defined: 708 o SENDER_TSPEC and FLOW_SPEC [RFC2205] 710 o SESSION_ATTRIBUTE [RFC3209] 712 o EXPLICIT_ROUTE Object (ERO) [RFC3209] 714 o ROUTE_RECORD Object (RRO) [RFC3209] 716 o FAST_REROUTE Object [RFC4090] 718 o DETOUR Object [RFC4090] 720 o EXCLUDE_ROUTE Object (XRO) [RFC4874] 722 o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873] 724 o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873] 726 o LSP_ATTRIBUTES Object [RFC5420] 728 o LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 730 o PROTECTION Object [RFC3473][RFC4872][RFC4873] 732 o ASSOCIATION Object [RFC4872] 734 o PRIMARY_PATH_ROUTE Object [RFC4872] 736 o ADMIN_STATUS Object [RFC3473] 738 o LABEL_REQUEST Object [RFC3209][RFC3473] 740 For the MPLS TE LSP Objects listed above, the corresponding sub- 741 objects are also applicable to this mechanism. Note that this list 742 is not exhaustive, other MPLS TE LSP objects which reflect specific 743 characteristics of the MPLS TE LSP can also be carried in the LSP 744 state TLV. 746 5.2. PCEP Objects 748 PCEP objects are encoded in the "MPLS-TE Policy State Objects" field 749 of the MPLS-TE Policy State TLV and consists of PCEP objects defined 750 in [RFC5440]. Rather than replicating all MPLS TE LSP related 751 objects in this document, the semantics and encodings of the MPLS TE 752 LSP objects are re-used. These MPLS TE LSP objects are carried in 753 the MPLS-TE Policy State TLV. 755 When carrying PCEP objects, the "Path-Origin" field is set to "PCEP". 757 The following PCEP Objects are defined: 759 o METRIC Object [RFC5440] 761 o BANDWIDTH Object [RFC5440] 763 For the MPLS TE LSP Objects listed above, the corresponding sub- 764 objects are also applicable to this mechanism. Note that this list 765 is not exhaustive, other MPLS TE LSP objects which reflect specific 766 characteristics of the MPLS TE LSP can also be carried in the TE 767 Policy State TLV. 769 6. SR Policy State TLVs 771 Segment Routing Policy (SR Policy) architecture is specified in 772 [I-D.ietf-spring-segment-routing-policy]. A SR Policy can comprise 773 of one or more candidate paths (CP) of which at a given time one and 774 only one may be active (i.e. installed in forwarding and usable for 775 steering of traffic). Each CP in turn may have one or more SID-List 776 of which one or more may be active; when multiple are active then 777 traffic is load balanced over them. 779 This section defines the various TLVs which enable the headend to 780 report the state of an SR Policy, its CP(s), SID-List(s) and their 781 status. These TLVs are carried in the optional non-transitive BGP 782 Attribute "LINK_STATE Attribute" defined in [RFC7752] and enable the 783 same consistent form of reporting for SR Policy state irrespective of 784 the Protocol-Origin used to provision the policy. Detailed procedure 785 is described in Section 7 . 787 6.1. SR Binding SID 789 The SR Binding SID (BSID) TLV provides the BSID and its attributes 790 for the SR Policy CP. The TLV MAY also optionally contain the 791 Provisioned BSID value for reporting when explicitly provisioned. 793 The TLV has the following format: 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type | Length | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | BSID Flags | RESERVED | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Binding SID (4 or 16 octets) // 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Provisioned Binding SID (optional, 4 or 16 octets) // 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 where: 809 o Type: TBD (see IANA Considerations Section 9.3) 811 o Length: variable (valid values are 12, 16, 24 or 40 octets) 813 o BSID Flags: 2 octet field that indicates attribute and status of 814 the Binding SID (BSID) associated with this CP. The following bit 815 positions are defined and the semantics are described in detail in 816 [I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be 817 cleared by originator and MUST be ignored by receiver. 819 0 1 820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 |D|B|U|S|L|F| | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 where: 827 * D-Flag : Indicates the dataplane for the BSIDs and if they are 828 16 octet SRv6 SID when SET and are 4 octet SR/MPLS label value 829 when CLEAR. 831 * B-Flag : Indicates the allocation of the value in the BSID 832 field when SET and indicates that BSID is not allocated when 833 CLEAR. 835 * U-Flag : Indicates the provisioned BSID value is unavailable 836 when SET. 838 * S-Flag : Indicates the BSID value in use is specified or 839 provisioned value when SET and dynamically allocated value when 840 CLEAR. 842 * L-Flag : Indicates the BSID value is from the Segment Routing 843 Local Block (SRLB) of the headend node when SET and is from the 844 local label pool when CLEAR 846 * F-Flag : Indicates the BSID value is one allocated from dynamic 847 range due to fallback (e.g. when specified BSID is unavailable) 848 when SET. 850 o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be 851 ignored by receiver. 853 o Binding SID: It indicates the operational or allocated BSID value 854 for the CP based on the status flags. 856 o Provisioned BSID: Optional field used to report the explicitly 857 provisioned BSID value as indicated by the S-Flag being SET. 859 The BSID fields above are 4 octet carrying the MPLS Label or 16 860 octets carrying the SRv6 SID based on the BSID D-flag. When carrying 861 the MPLS Label, as shown in the figure below, the TC, S and TTL 862 (total of 12 bits) are RESERVED and SHOULD be set to 0 by originator 863 and MUST be ignored by the receiver. 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Label | TC |S| TTL | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 6.2. SR Candidate Path State 873 The SR Candidate Path (CP) State TLV provides the operational status 874 and attributes of the SR Policy at the CP level. The TLV has the 875 following format: 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Type | Length | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Priority | RESERVED | Flags | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Preference (4 octets) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 where: 889 o Type: TBD (see IANA Considerations Section 9.3) 891 o Length: 12 octets 893 o Priority : 1 octet value which indicates the priority of the CP 895 o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be 896 ignored by receiver. 898 o Flags: 2 octet field that indicates attribute and status of the 899 CP. The following bit positions are defined and the semantics are 900 described in detail in [I-D.ietf-spring-segment-routing-policy]. 901 Other bits SHOULD be cleared by originator and MUST be ignored by 902 receiver. 904 0 1 905 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 |S|A|B|E|V|O|D|C|I|T| | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 where: 912 * S-Flag : Indicates the CP is in administrative shut state when 913 SET 915 * A-Flag : Indicates the CP is the active path (i.e. one 916 provisioned in the forwarding plane) for the SR Policy when SET 918 * B-Flag : Indicates the CP is the backup path (i.e. one 919 identified for path protection of the active path) for the SR 920 Policy when SET 922 * E-Flag : Indicates that the CP has been evaluated for validity 923 (e.g. headend may evaluate CPs based on their preferences) when 924 SET 926 * V-Flag : Indicates the CP has at least one valid SID-List when 927 SET 929 * O-Flag : Indicates the CP was instantiated by the headend due 930 to an on-demand-nexthop trigger based on local template when 931 SET 933 * D-Flag : Indicates the CP was delegated for computation to a 934 PCE/controller when SET 936 * C-Flag : Indicates the CP was provisioned by a PCE/controller 937 when SET 939 * I-Flag : Indicates the CP will perform the "drop upon invalid" 940 behavior when no other active path is available for this SR 941 Policy and this path is the one with best preference amongst 942 the available CPs. 944 * T-Flag : Indicates the CP has been marked as eligible for use 945 as Transit Policy on the headend when SET 947 o Preference : 4 octet value which indicates the preference of the 948 CP 950 6.3. SR Candidate Path Name 952 The SR Candidate Path Name TLV is an optional TLV that is used to 953 carry the symbolic name associated with the candidate path. The TLV 954 has the following format: 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type | Length | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Candidate Path Symbolic Name (variable) // 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 where: 966 o Type: TBD (see IANA Considerations Section 9.3) 968 o Length: variable 970 o CP Name : Symbolic name for the CP. It is a string of printable 971 ASCII characters without a NULL terminator. 973 6.4. SR Candidate Path Constraints 975 The SR Candidate Path Constraints TLV is an optional TLV that is used 976 to report the contraints associated with the candidate path. The 977 constraints are generally applied to a dynamic candidate path which 978 is computed by the headend. The constraints may also be applied to 979 an explicit path where the headend is expected to validate that the 980 path expresses satisfies the specified constraints and the path is to 981 be invalidated by the headend when the constraints are no longer met 982 (e.g. due to topology changes). 984 The TLV has the following format: 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Type | Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Flags | Algorithm | RESERVED | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | sub-TLVs (variable) // 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 where: 998 o Type: TBD (see IANA Considerations Section 9.3) 1000 o Length: variable 1002 o Flags: 2 octet field that indicates the constraints that are being 1003 applied to the CP. The following bit positions are defined and 1004 the other bits SHOULD be cleared by originator and MUST be ignored 1005 by receiver. 1007 0 1 1008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 |D|P|U|A| | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 where: 1015 * A-Flag : Indicates that the CP needs to use SRv6 dataplane when 1016 SET and SR/MPLS dataplane when CLEAR 1018 * P-Flag : Indicates that the CP needs to use only protected SIDs 1019 when SET 1021 * U-Flag : Indicates that the CP needs to use only unprotected 1022 SIDs when SET 1024 * A-Flag : Indicates that the CP needs to use the SIDs belonging 1025 to the specified SR Algorithm only when SET 1027 o Algorithm : Indicates the algorithm that is preferred to be used 1028 when the path is setup. When the A-flag is SET then the path is 1029 strictly using the specified algorithm SIDs only. 1031 o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be 1032 ignored by receiver. 1034 o sub-TLVs: optional sub-TLVs MAY be included in this TLV to 1035 describe other constraints. 1037 The following constraint sub-TLVs are defined for the SR CP 1038 Constraints TLV. 1040 6.4.1. SR Affinity Constraint 1042 The SR Affinity Constraint sub-TLV is an optional sub-TLV that is 1043 used to carry the affinity constraints [RFC2702] associated with the 1044 candidate path. The affinity is expressed in terms of Extended Admin 1045 Group (EAG) as defined in [RFC7308]. The TLV has the following 1046 format: 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Type | Length | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Excl-Any-Size | Incl-Any-Size | Incl-All-Size | RESERVED | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Exclude-Any EAG (optional, variable) // 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Include-Any EAG (optional, variable) // 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Include-All EAG (optional, variable) // 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 where: 1064 o Type: TBD (see IANA Considerations Section 9.3) 1066 o Length: variable, dependent on the size of the Extended Admin 1067 Group. MUST be a multiple of 4 octets. 1069 o Exclude-Any-Size : one octet to indicate the size of Exclude-Any 1070 EAG bitmask size in multiples of 4 octets. (e.g. value 0 1071 indicates the Exclude-Any EAG field is skipped, value 1 indicates 1072 that 4 octets of Exclude-Any EAG is included) 1074 o Include-Any-Size : one octet to indicate the size of Include-Any 1075 EAG bitmask size in multiples of 4 octets. (e.g. value 0 1076 indicates the Include-Any EAG field is skipped, value 1 indicates 1077 that 4 octets of Include-Any EAG is included) 1079 o Include-All-Size : one octet to indicate the size of Include-All 1080 EAG bitmask size in multiples of 4 octets. (e.g. value 0 1081 indicates the Include-All EAG field is skipped, value 1 indicates 1082 that 4 octets of Include-All EAG is included) 1084 o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be 1085 ignored by receiver. 1087 o Exclude-Any EAG : the bitmask used to represent the affinities to 1088 be excluded from the path. 1090 o Include-Any EAG : the bitmask used to represent the affinities to 1091 be included in the path. 1093 o Include-All EAG : the bitmask used to represent the all affinities 1094 to be included in the path. 1096 6.4.2. SR SRLG Constraint 1098 The SR SRLG Constraint sub-TLV is an optional sub-TLV that is used to 1099 carry the Shared Risk Link Group (SRLG) values [RFC4202] that are to 1100 be excluded from the candidate path. The TLV has the following 1101 format: 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Type | Length | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | SRLG Values (variable, multiples of 4 octets) // 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 where: 1113 o Type: TBD (see IANA Considerations Section 9.3) 1115 o Length: variable, dependent on the number of SRLGs encoded. MUST 1116 be a multiple of 4 octets. 1118 o SRLG Values : One or more SRLG values (each of 4 octets). 1120 6.4.3. SR Bandwidth Constraint 1122 The SR Bandwidth Constraint sub-TLV is an optional sub-TLV that is 1123 used to indicate the desired bandwidth availability that needs to be 1124 ensured for the candidate path. The TLV has the following format: 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Type | Length | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Bandwidth | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 where: 1136 o Type: TBD (see IANA Considerations Section 9.3) 1138 o Length: 8 octects 1140 o Bandwidth : 4 octets which specify the desired bandwidth in unit 1141 of bytes per second in IEEE floating point format. 1143 6.4.4. SR Disjoint Group Constraint 1145 The SR Disjoint Group Constraint sub-TLV is an optional sub-TLV that 1146 is used to carry the disjointness constraint associated with the 1147 candidate path. The disjointness between two SR Policy Candidate 1148 Paths is expressed by associating them with the same disjoint group 1149 identifier and then specifying the type of disjointness required 1150 between their paths. The computation is expected to achieve the 1151 highest level of disjointness requested and when that is not possible 1152 then fallback to a lesser level progressively based on the levels 1153 indicated. 1155 The TLV has the following format: 1157 0 1 2 3 1158 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Type | Length | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Request-Flags | Status-Flags | RESERVED | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Disjoint Group Identifier | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 where: 1169 o Type: TBD (see IANA Considerations Section 9.3) 1171 o Length: 12 octets 1172 o Request Flags : one octet to indicate the level of disjointness 1173 requested as specified in the form of flags. The following flags 1174 are defined and the other bits SHOULD be cleared by originator and 1175 MUST be ignored by receiver. 1177 0 1 2 3 4 5 6 7 1178 +-+-+-+-+-+-+-+-+ 1179 |S|N|L|F|I| | 1180 +-+-+-+-+-+-+-+-+ 1182 where: 1184 * S-Flag : Indicates that SRLG disjointness is requested 1186 * N-Flag : Indicates that node disjointness is requested when 1188 * L-Flag : Indicates that link disjointness is requested when 1190 * F-Flag : Indicates that the computation may fallback to a lower 1191 level of disjointness amongst the ones requested when all 1192 cannot be achieved 1194 * I-Flag : Indicates that the computation may fallback to the 1195 default best path (e.g. IGP path) in case of none of the 1196 desired disjointness can be achieved. 1198 o Status Flags : one octet to indicate the level of disjointness 1199 that has been achieved by the computation as specified in the form 1200 of flags. The following flags are defined and the other bits 1201 SHOULD be cleared by originator and MUST be ignored by receiver. 1203 0 1 2 3 4 5 6 7 1204 +-+-+-+-+-+-+-+-+ 1205 |S|N|L|F|I|X| | 1206 +-+-+-+-+-+-+-+-+ 1208 where: 1210 * S-Flag : Indicates that SRLG disjointness is achieved 1212 * N-Flag : Indicates that node disjointness is achieved 1214 * L-Flag : Indicates that link disjointness is achieved 1216 * F-Flag : Indicates that the computation has fallen back to a 1217 lower level of disjointness that requested. 1219 * I-Flag : Indicates that the computation has fallen back to the 1220 best path (e.g. IGP path) and disjointness has not been 1221 achieved 1223 * X-Flag : Indicates that the disjointness constraint could not 1224 be achieved and hence path has been invalidated 1226 o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be 1227 ignored by receiver. 1229 o Disjointness Group Identifier : 4 octet value that is the group 1230 identifier for a set of disjoint paths 1232 6.5. SR Segment List 1234 The SR Segment List TLV is used to report the SID-List(s) of a 1235 candidate path. The TLV has following format: 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Type | Length | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Flags | Algorithm | RESERVED | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Weight (4 octets) | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | sub-TLVs (variable) // 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 where: 1251 o Type: TBD (see IANA Considerations Section 9.3) 1253 o Length: variable 1255 o Flags: 1 octet field that indicates attribute and status of the 1256 SID-List.The following bit positions are defined and the semantics 1257 are described in detail in 1258 [I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be 1259 cleared by originator and MUST be ignored by receiver. 1261 0 1 1262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 |D|E|C|V|R|C|A| | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 where: 1269 * D-Flag : Indicates the SID-List is comprised of SRv6 SIDs when 1270 SET and indicates it is comprised of SR/MPLS labels when CLEAR. 1272 * E-Flag : Indicates that SID-List is an explicit path when SET 1273 and indicates dynamic path when CLEAR. 1275 * C-Flag : Indicates that SID-List has been computed for a 1276 dynamic path when SET. It is always reported as SET for 1277 explicit paths. 1279 * V-Flag : Indicates the SID-List has passed verification or its 1280 verification was not required when SET and failed verification 1281 when CLEAR. 1283 * R-Flag : Indicates that the first Segment has been resolved 1284 when SET and failed resolution when CLEAR. 1286 * C-Flag : Indicates that the computation for the dynamic path 1287 failed when SET and succeeded (or not required in case of 1288 explicit path) when CLEAR 1290 * A-Flag : Indicates that all the SIDs in the SID-List belong to 1291 the specified algorithm when SET. 1293 o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be 1294 ignored by receiver. 1296 o Algorithm: 1 octet that indicates the algorithm of the SIDs used 1297 in the SID-List when the A-flag is SET. 1299 o Weight: 4 octet field that indicates the weight associated with 1300 the SID-List for weighted load-balancing 1302 o Sub-TLVs : variable and contains the ordered set of Segments and 1303 any other optional attributes associated with the specific SID- 1304 List. 1306 The SR Segment sub-TLV (defined in Section 6.6) is the only currently 1307 defined sub-TLV for use with the SR Segment List TLV and it MUST be 1308 included as an ordered set of sub-TLVs within the SR Segment List TLV 1309 when the SID-List is not empty. A SID-List may be empty in certain 1310 cases (e.g. for a dynamic path) where the headend has not yet 1311 performed the computation and hence not derived the segments required 1312 for the path; in such cases, the SR Segment List TLV SHOULD NOT 1313 include any SR Segment sub-TLVs. 1315 6.6. SR Segment 1317 The SR Segment sub-TLV describes a single segment in a SID-List. One 1318 or more instances of this sub-TLV in an ordered manner constitute a 1319 SID-List for a SR Policy candidate path. It is a sub-TLV of the SR 1320 Segment List TLV and has following format: 1322 0 1 2 3 1323 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 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Type | Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Segment Type | RESERVED | Flags | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | SID (4 or 16 octets) // 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 // SID Descriptor (variable) // 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 // Sub-TLVs (variable) // 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 where: 1338 o Type: TBD (see IANA Considerations Section 9.3) 1340 o Length: variable 1342 o Segment Type : 1 octet which indicates the type of segment (refer 1343 Section 6.6.1 for details) 1345 o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be 1346 ignored by receiver. 1348 o Flags: 2 octet field that indicates attribute and status of the 1349 Segment and its SID. The following bit positions are defined and 1350 the semantics are described in detail in 1351 [I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be 1352 cleared by originator and MUST be ignored by receiver. 1354 0 1 1355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 |S|E|V|R|A| | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 where: 1362 * S-Flag : Indicates the presence of SID value in the SID field 1363 when SET and that no value is indicated when CLEAR. 1365 * E-Flag : Indicates the SID value is explicitly provisioned 1366 value (locally on headend or via controller/PCE) when SET and 1367 is a dynamically resolved value by headend when CLEAR 1369 * V-Flag : Indicates the SID has passed verification or did not 1370 require verification when SET and failed verification when 1371 CLEAR. 1373 * R-Flag : Indicates the SID has been resolved or did not require 1374 resolution (e.g. because it is not the first SID) when SET and 1375 failed resolution when CLEAR. 1377 * A-Flag : Indicates that the Algorithm indicated in the Segment 1378 descriptor is valid when SET. When CLEAR, it indicates that 1379 the headend is unable to determine the algorithm of the SID. 1381 o SID : 4 octet carrying the MPLS Label or 16 octets carrying the 1382 SRv6 SID based on the F-flag. When carrying the MPLS Label, as 1383 shown in the figure below, the TC, S and TTL (total of 12 bits) 1384 are RESERVED and SHOULD be set to 0 by originator and MUST be 1385 ignored by the receiver. 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Label | TC |S| TTL | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 o SID Descriptor : variable size SID descriptor based on the type of 1394 segment (refer Section 6.6.1 for details) 1396 o Sub-Sub-TLVs : variable and contains any other optional attributes 1397 associated with the specific SID-List. 1399 Currently no Sub-Sub-TLV of the SR Segment sub-TLV is defined. 1401 6.6.1. Segment Descriptors 1403 [I-D.ietf-spring-segment-routing-policy] section 4 defines multiple 1404 types of segments and their description. This section defines the 1405 encoding of the Segment Descriptors for each of those Segment types 1406 to be used in the Segment sub-TLV describes previously in 1407 Section 6.6. 1409 The following types are currently defined (suggested values, to be 1410 assigned by IANA): 1412 +-------+--------------------------------------------------------------+ 1413 | Type | Segment Description | 1414 +-------+--------------------------------------------------------------+ 1415 | 0 | Invalid | 1416 | 1 | SR-MPLS Label | 1417 | 2 | SRv6 SID as IPv6 address | 1418 | 3 | SR-MPLS Prefix SID as IPv4 Node Address | 1419 | 4 | SR-MPLS Prefix SID as IPv6 Node Global Address | 1420 | 5 | SR-MPLS Adjacency SID as IPv4 Node Address & Local | 1421 | | Interface ID | 1422 | 6 | SR-MPLS Adjacency SID as IPv4 Local & Remote Interface | 1423 | | Addresses | 1424 | 7 | SR-MPLS Adjacency SID as pair of IPv6 Global Address & | 1425 | | Interface ID for Local & Remote nodes | 1426 | 8 | SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for | 1427 | | the Local & Remote Interface | 1428 | 9 | SRv6 END SID as IPv6 Node Global Address | 1429 | 10 | SRv6 END.X SID as pair of IPv6 Global Address & Interface ID | 1430 | | for Local & Remote nodes | 1431 | 11 | SRv6 END.X SID as pair of IPv6 Global Addresses for the | 1432 | | Local & Remote Interface | 1433 +-------+--------------------------------------------------------------+ 1435 6.6.1.1. Type 1: SR-MPLS Label 1437 The Segment is SR-MPLS type and is specified simply as the label. 1438 The format of its Segment Descriptor is as follows: 1440 0 1 2 3 1441 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 1442 +-+-+-+-+-+-+-+-+ 1443 | Algorithm | 1444 +-+-+-+-+-+-+-+-+ 1446 Where: 1448 o Algorithm: 1 octet value that indicates the algorithm used for 1449 picking the SID. This is valid only when the A-flag has been SET 1450 in the Segment TLV. 1452 6.6.1.2. Type 2: SRv6 SID 1454 The Segment is SRv6 type and is specified simply as the SRv6 SID 1455 address. The format of its Segment Descriptor is as follows: 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+ 1460 | Algorithm | 1461 +-+-+-+-+-+-+-+-+ 1463 Where: 1465 o Algorithm: 1 octet value that indicates the algorithm used for 1466 picking the SID. This is valid only when the A-flag has been SET 1467 in the Segment TLV. 1469 6.6.1.3. Type 3: SR-MPLS Prefix SID for IPv4 1471 The Segment is SR-MPLS Prefix SID type and is specified as an IPv4 1472 node address. The format of its Segment Descriptor is as follows: 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+ 1477 | Algorithm | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | IPv4 Node Address (4 octets) | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 Where: 1484 o Algorithm: 1 octet value that indicates the algorithm used for 1485 picking the SID 1487 o IPv4 Node Address: 4 octet value which carries the IPv4 address 1488 associated with the node 1490 6.6.1.4. Type 4: SR-MPLS Prefix SID for IPv6 1492 The Segment is SR-MPLS Prefix SID type and is specified as an IPv6 1493 global address. The format of its Segment Descriptor is as follows: 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+ 1498 | Algorithm | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | IPv6 Node Global Address (16 octets) | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 Where: 1505 o Algorithm: 1 octet value that indicates the algorithm used for 1506 picking the SID 1508 o IPv6 Node Global Address: 16 octet value which carries the IPv6 1509 global address associated with the node 1511 6.6.1.5. Type 5: SR-MPLS Adjacency SID for IPv4 with Interface ID 1513 The Segment is SR-MPLS Adjacency SID type and is specified as an IPv4 1514 node address along with the local interface ID on that node. The 1515 format of its Segment Descriptor is as follows: 1517 0 1 2 3 1518 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 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | IPv4 Node Address (4 octets) | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Local Interface ID (4 octets) | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 Where: 1527 o IPv4 Node Address: 4 octet value which carries the IPv4 address 1528 associated with the node 1530 o Local Interface ID : 4 octet value which carries the local 1531 interface ID of the node identified by the Node Address 1533 6.6.1.6. Type 6: SR-MPLS Adjacency SID for IPv4 with Interface Address 1535 The Segment is SR-MPLS Adjacency SID type and is specified as a pair 1536 of IPv4 local and remote addresses. The format of its Segment 1537 Descriptor is as follows: 1539 0 1 2 3 1540 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 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | IPv4 Local Address (4 octets) | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | IPv4 Remote Address (4 octets) | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 Where: 1549 o IPv4 Local Address: 4 octet value which carries the local IPv4 1550 address associated with the node 1552 o IPv4 Remote Address: 4 octet value which carries the remote IPv4 1553 address associated with the node's neighbor. This is optional and 1554 MAY be set to 0 when not used (e.g. when identifying point-to- 1555 point links). 1557 6.6.1.7. Type 7: SR-MPLS Adjacency SID for IPv6 with interface ID 1559 The Segment is SR-MPLS Adjacency SID type and is specified as a pair 1560 of IPv6 global address and interface ID for local and remote nodes. 1561 The format of its Segment Descriptor is as follows: 1563 0 1 2 3 1564 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 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | IPv6 Local Node Global Address (16 octets) | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Local Node Interface ID (4 octets) | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | IPv6 Remote Node Global Address (16 octets) | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Remote Node Interface ID (4 octets) | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Where: 1577 o IPv6 Local Node Global Address: 16 octet value which carries the 1578 IPv6 global address associated with the local node 1580 o Local Node Interface ID : 4 octet value which carries the 1581 interface ID of the local node identified by the Local Node 1582 Address 1584 o IPv6 Remote Node Global Address: 16 octet value which carries the 1585 IPv6 global address associated with the remote node. This is 1586 optional and MAY be set to 0 when not used (e.g. when identifying 1587 point-to-point links). 1589 o Remote Node Interface ID : 4 octet value which carries the 1590 interface ID of the remote node identified by the Remote Node 1591 Address. This is optional and MAY be set to 0 when not used (e.g. 1592 when identifying point-to-point links). 1594 6.6.1.8. Type 8: SR-MPLS Adjacency SID for IPv6 with interface address 1596 The Segment is SR-MPLS Adjacency SID type and is specified as a pair 1597 of IPv6 Global addresses for local and remote interface addresses. 1598 The format of its Segment Descriptor is as follows: 1600 0 1 2 3 1601 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 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Global IPv6 Local Interface Address (16 octets) | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Global IPv6 Remote Interface Address (16 octets) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 Where: 1610 o IPv6 Local Address: 16 octet value which carries the local IPv6 1611 address associated with the node 1613 o IPv6 Remote Address: 16 octet value which carries the remote IPv6 1614 address associated with the node's neighbor 1616 6.6.1.9. Type 9: SRv6 END SID as IPv6 Node Address 1618 The Segment is SRv6 END SID type and is specified as an IPv6 global 1619 address. The format of its Segment Descriptor is as follows: 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+ 1624 | Algorithm | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | IPv6 Node Global Address (16 octets) | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 Where: 1631 o Algorithm: 1 octet value that indicates the algorithm used for 1632 picking the SID 1634 o IPv6 Node Global Address: 16 octet value which carries the IPv6 1635 global address associated with the node 1637 6.6.1.10. Type 10: SRv6 END.X SID as interface ID 1639 The Segment is SRv6 END.X SID type and is specified as a pair of IPv6 1640 global address and interface ID for local and remote nodes. The 1641 format of its Segment Descriptor is as follows: 1643 0 1 2 3 1644 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 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | IPv6 Local Node Global Address (16 octets) | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 | Local Node Interface ID (4 octets) | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | IPv6 Remote Node Global Address (16 octets) | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Remote Node Interface ID (4 octets) | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 Where: 1657 o IPv6 Local Node Global Address: 16 octet value which carries the 1658 IPv6 global address associated with the local node 1660 o Local Node Interface ID : 4 octet value which carries the 1661 interface ID of the local node identified by the Local Node 1662 Address 1664 o IPv6 Remote Node Global Address: 16 octet value which carries the 1665 IPv6 global address associated with the remote node. This is 1666 optional and MAY be set to 0 when not used (e.g. when identifying 1667 point-to-point links). 1669 o Remote Node Interface ID : 4 octet value which carries the 1670 interface ID of the remote node identified by the Remote Node 1671 Address. This is optional and MAY be set to 0 when not used (e.g. 1672 when identifying point-to-point links). 1674 6.6.1.11. Type 11: SRv6 END.X SID as interface address 1676 The Segment is SRv6 END.X SID type and is specified as a pair of IPv6 1677 Global addresses for local and remote interface addresses. The 1678 format of its Segment Descriptor is as follows: 1680 0 1 2 3 1681 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 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Global IPv6 Local Interface Address (16 octets) | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Global IPv6 Remote Interface Address (16 octets) | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 Where: 1690 o IPv6 Local Address: 16 octet value which carries the local IPv6 1691 address associated with the node 1693 o IPv6 Remote Address: 16 octet value which carries the remote IPv6 1694 address associated with the node's neighbor 1696 6.7. SR Segment List Metric 1698 The SR Segment List Metric sub-TLV describes the metric used for 1699 computation of the SID-List. It is used to report the type of metric 1700 used in the computation of a dynamic path either on the headend or 1701 when the path computation is delegated to a PCE/controller. When the 1702 path computation is done on the headend, it is also used to report 1703 the calculated metric for the path. 1705 It is a sub-TLV of the SR Segment List TLV and has following format: 1707 0 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Type | Length | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Metric Type | Flags | RESERVED | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Metric Margin | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Metric Bound | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Metric Value | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 where: 1723 o Type: TBD (see IANA Considerations Section 9.3) 1725 o Length: variable 1726 o Metric Type : 1 octet field which identifies the type of metric 1727 used for path computation. Following metric type codepoints are 1728 defined in this document. 1730 +------------+-----------------------------------------+ 1731 | Code Point | Metric Type | 1732 +------------+-----------------------------------------+ 1733 | 0 | IGP Metric | 1734 | 1 | Min Unidirectional Link Delay [RFC7471] | 1735 | 2 | TE Metric [RFC3630] | 1736 +------------+-----------------------------------------+ 1738 o Flags: 1 octet field that indicates the validity of the metric 1739 fields and their semantics. The following bit positions are 1740 defined and the other bits SHOULD be cleared by originator and 1741 MUST be ignored by receiver. 1743 0 1 2 3 4 5 6 7 1744 +-+-+-+-+-+-+-+-+ 1745 |M|A|B|V| | 1746 +-+-+-+-+-+-+-+-+ 1748 where: 1750 * M-Flag : Indicates that the metric margin allowed for path 1751 computation is specified when SET 1753 * A-Flag : Indicates that the metric margin is specified as an 1754 absolute value when SET and is expressed as a percentage of the 1755 minimum metric when CLEAR. 1757 * B-Flag : Indicates that the metric bound allowed for the path 1758 is specified when SET. 1760 * V-Flag : Indicates that the metric value computed is being 1761 reported when SET. 1763 o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be 1764 ignored by receiver. 1766 o Metric Margin : 4 octets which indicate the metric margin value 1767 when M-flag is SET. The metric margin is specified as either an 1768 absolute value or as a percentage of the minimum computed path 1769 metric based on the A-flag. The metric margin loosens the 1770 criteria for minimum metric path calculation up to the specified 1771 metric to accomodate for other factors such as bandwidth 1772 availability, minimal SID stack depth and maximizing of ECMP for 1773 the SR path computed. 1775 o Metric Bound : 4 octects which indicate the maximum metric value 1776 that is allowed when B-flag is SET. If the computed path metric 1777 crosses the specified bound value then the path is considered as 1778 invalid. 1780 o Metric Value : 4 octets which indicate the metric value of the 1781 computed path when V-flag is SET. This value is available and 1782 reported when the computation is successful and a valid path is 1783 available. 1785 7. Procedures 1787 The BGP-LS advertisements for the TE Policy NLRI are originated by 1788 the headend node for the TE Policies that are instantiated on its 1789 local node. 1791 For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as 1792 specified in Section 4.1, Section 4.2, Section 4.3 and Section 4.4 1793 are used. Then the TE LSP state is encoded in the BGP-LS Attribute 1794 field as MPLS-TE Policy State TLV as described in Section 5. The 1795 RSVP-TE objects that reflect the state of the LSP are included as 1796 defined in Section 5.1. When the TE LSP is setup with the help of 1797 PCEP signaling then another MPLS-TE Policy State TLV SHOULD be used 1798 to to encode the related PCEP objects corresponding to the LSP as 1799 defined in Section 5.2. 1801 For SR Policies, the NLRI descriptor TLV as specified in Section 4.5 1802 is used. An SR Policy candidate path (CP) may be instantiated on the 1803 headend node via a local configuration, PCEP or BGP SR Policy 1804 signaling and this is indicated via the SR Protocol Origin. Then the 1805 SR Policy Candidate Path's attribute and state is encoded in the BGP- 1806 LS Attribute field as SR Policy State TLVs and sub-TLVs as described 1807 in Section 6. The SR Candidate Path State TLV as defined in 1808 Section 6.2 is included to report the state of the CP. The SR BSID 1809 TLV as defined in Section 6.1 is included to report the BSID of the 1810 CP when one is either provisioned or allocated by the headend. The 1811 constraints for the SR Policy Candidate Path are reported using the 1812 SR Candidate Path Constraints TLV as described in Section 6.4.The SR 1813 Segment List TLV is included for each of the SID-List(s) associated 1814 with the CP. Each SR Segment List TLV in turn includes SR Segment 1815 sub-TLV(s) to report the segment(s) and their status. The SR Segment 1816 List Metric sub-TLV is used to report the metric values and 1817 constraints for the specific SID List. 1819 When the SR Policy CP is setup with the help of PCEP signaling then 1820 another MPLS-TE Policy State TLV MAY be used to to encode the related 1821 PCEP objects corresponding to the LSP as defined in Section 5.2 1822 specifically to report information and status that is not covered by 1823 the defined TLVs under Section 6. In the event of a conflict of 1824 information, the receiver MUST prefer the information originated via 1825 TLVs defined in Section 6 over the PCEP objects reported via the TE 1826 Policy State TLV. 1828 8. Manageability Considerations 1830 The Existing BGP operational and management procedures apply to this 1831 document. No new procedures are defined in this document. The 1832 considerations as specified in [RFC7752] apply to this document. 1834 In general, it is assumed that the TE Policy head-end nodes are 1835 responsible for the distribution of TE Policy state information, 1836 while other nodes, e.g. the nodes in the path of a policy, MAY report 1837 the TE Policy information (if available) when needed. For example, 1838 the border routers in the inter-domain case will also distribute LSP 1839 state information since the ingress node may not have the complete 1840 information for the end-to-end path. 1842 9. IANA Considerations 1844 This document requires new IANA assigned codepoints. 1846 9.1. BGP-LS NLRI-Types 1848 IANA maintains a registry called "Border Gateway Protocol - Link 1849 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI- 1850 Types". 1852 The following codepoints is suggested (to be assigned by IANA): 1854 +------+----------------------------+---------------+ 1855 | Type | NLRI Type | Reference | 1856 +------+----------------------------+---------------+ 1857 | 5 | TE Policy NLRI type | this document | 1858 +------+----------------------------+---------------+ 1860 9.2. BGP-LS Protocol-IDs 1862 IANA maintains a registry called "Border Gateway Protocol - Link 1863 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS 1864 Protocol-IDs". 1866 The following Protocol-ID codepoints are suggested (to be assigned by 1867 IANA): 1869 +-------------+----------------------------------+---------------+ 1870 | Protocol-ID | NLRI information source protocol | Reference | 1871 +-------------+----------------------------------+---------------+ 1872 | 8 | RSVP-TE | this document | 1873 | 9 | Segment Routing | this document | 1874 +-------------+----------------------------------+---------------+ 1876 9.3. BGP-LS TLVs 1878 IANA maintains a registry called "Border Gateway Protocol - Link 1879 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 1880 Link Descriptor and Link Attribute TLVs". 1882 The following TLV codepoints are suggested (to be assigned by IANA): 1884 +----------+----------------------------------------+---------------+ 1885 | TLV Code | Description | Value defined | 1886 | Point | | in | 1887 +----------+----------------------------------------+---------------+ 1888 | TBD | Tunnel ID TLV | this document | 1889 | TBD | LSP ID TLV | this document | 1890 | TBD | IPv4/6 Tunnel Head-end address TLV | this document | 1891 | TBD | IPv4/6 Tunnel Tail-end address TLV | this document | 1892 | TBD | SR Policy CP Descriptor TLV | this document | 1893 | TBD | MPLS Local Cross Connect TLV | this document | 1894 | TBD | MPLS Cross Connect Interface TLV | this document | 1895 | TBD | MPLS Cross Connect FEC TLV | this document | 1896 | TBD | MPLS-TE Policy State TLV | this document | 1897 | TBD | SR BSID TLV | this document | 1898 | TBD | SR CP State TLV | this document | 1899 | TBD | SR CP Name TLV | this document | 1900 | TBD | SR CP Constraints TLV | this document | 1901 | TBD | SR Segment List TLV | this document | 1902 | TBD | SR Segment sub-TLV | this document | 1903 | TBD | SR Segment List Metric sub-TLV | this document | 1904 | TBD | SR Affinity Constraint sub-TLV | this document | 1905 | TBD | SR SRLG Constraint sub-TLV | this document | 1906 | TBD | SR Bandwidth Constraint sub-TLV | this document | 1907 | TBD | SR Disjoint Group Constraint sub-TLV | this document | 1908 +----------+----------------------------------------+---------------+ 1910 9.4. BGP-LS SR Policy Protocol Origin 1912 This document requests IANA to maintain a new sub-registry under 1913 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1914 registry is called "SR Policy Protocol Origin" and contains the 1915 codepoints allocated to the "Protocol Origin" field defined in 1916 Section 4.5. The registry contains the following codepoints 1917 (suggested values, to be assigned by IANA): 1919 +------------+---------------------------------------------------------+ 1920 | Code Point | Protocol Origin | 1921 +------------+---------------------------------------------------------+ 1922 | 1 | PCEP | 1923 | 2 | BGP SR Policy | 1924 | 3 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) | 1925 +------------+---------------------------------------------------------+ 1927 9.5. BGP-LS TE State Path Origin 1929 This document requests IANA to maintain a new sub-registry under 1930 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1931 registry is called "TE State Path Origin" and contains the codepoints 1932 allocated to the "Path Origin" field defined in Section 5. The 1933 registry contains the following codepoints (suggested values, to be 1934 assigned by IANA): 1936 +----------+------------------+ 1937 | Code | Path | 1938 | Point | Origin | 1939 +----------+------------------+ 1940 | 1 | RSVP-TE | 1941 | 2 | PCEP | 1942 | 3 | Local/Static | 1943 +----------+------------------+ 1945 9.6. BGP-LS TE State Dataplane 1947 This document requests IANA to maintain a new sub-registry under 1948 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1949 registry is called "TE State Dataplane" and contains the codepoints 1950 allocated to the "dataplane" field defined in Section 5. The 1951 registry contains the following codepoints (suggested values, to be 1952 assigned by IANA): 1954 +----------+------------------+ 1955 | Code | Dataplane | 1956 | Point | | 1957 +----------+------------------+ 1958 | 1 | MPLS-IPv4 | 1959 | 2 | MPLS-IPv6 | 1960 +----------+------------------+ 1962 9.7. BGP-LS SR Segment Descriptors 1964 This document requests IANA to maintain a new sub-registry under 1965 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1966 registry is called "SR Segment Descriptor Types" and contains the 1967 codepoints allocated to the "Segment Type" field defined in 1968 Section 6.6 and described in Section 6.6.1. The registry contains 1969 the following codepoints (suggested values, to be assigned by IANA): 1971 +-------+--------------------------------------------------------------+ 1972 | Code | Segment Description | 1973 | Point | | 1974 +-------+--------------------------------------------------------------+ 1975 | 0 | Invalid | 1976 | 1 | SR-MPLS Label | 1977 | 2 | SRv6 SID as IPv6 address | 1978 | 3 | SR-MPLS Prefix SID as IPv4 Node Address | 1979 | 4 | SR-MPLS Prefix SID as IPv6 Node Global Address | 1980 | 5 | SR-MPLS Adjacency SID as IPv4 Node Address & Local | 1981 | | Interface ID | 1982 | 6 | SR-MPLS Adjacency SID as IPv4 Local & Remote Interface | 1983 | | Addresses | 1984 | 7 | SR-MPLS Adjacency SID as pair of IPv6 Global Address & | 1985 | | Interface ID for Local & Remote nodes | 1986 | 8 | SR-MPLS Adjacency SID as pair of IPv6 Global Addresses for | 1987 | | the Local & Remote Interface | 1988 | 9 | SRv6 END SID as IPv6 Node Global Address | 1989 | 10 | SRv6 END.X SID as pair of IPv6 Global Address & Interface ID | 1990 | | for Local & Remote nodes | 1991 | 11 | SRv6 END.X SID as pair of IPv6 Global Addresses for the | 1992 | | Local & Remote Interface | 1993 +-------+--------------------------------------------------------------+ 1995 9.8. BGP-LS Metric Type 1997 This document requests IANA to maintain a new sub-registry under 1998 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1999 registry is called "Metric Type" and contains the codepoints 2000 allocated to the "metric type" field defined in Section 6.7. The 2001 registry contains the following codepoints (suggested values, to be 2002 assigned by IANA): 2004 +------------+-----------------------------------------+ 2005 | Code Point | Metric Type | 2006 +------------+-----------------------------------------+ 2007 | 0 | IGP Metric | 2008 | 1 | Min Unidirectional Link Delay [RFC7471] | 2009 | 2 | TE Metric [RFC3630] | 2010 +------------+-----------------------------------------+ 2012 10. Security Considerations 2014 Procedures and protocol extensions defined in this document do not 2015 affect the BGP security model. See [RFC6952] for details. 2017 11. Acknowledgements 2019 The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz 2020 Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah, 2021 and Dhanendra Jain for their review and valuable comments. 2023 12. Contributors 2025 The following people have substantially contributed to the editing of 2026 this document: 2028 Clarence Filsfils 2029 Cisco Systems 2030 Email: cfilsfil@cisco.com 2032 13. References 2034 13.1. Normative References 2036 [I-D.ietf-spring-segment-routing-policy] 2037 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 2038 bogdanov@google.com, b., and P. Mattes, "Segment Routing 2039 Policy Architecture", draft-ietf-spring-segment-routing- 2040 policy-01 (work in progress), June 2018. 2042 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2043 Requirement Levels", BCP 14, RFC 2119, 2044 DOI 10.17487/RFC2119, March 1997, 2045 . 2047 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2048 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2049 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2050 September 1997, . 2052 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2053 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2054 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2055 . 2057 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 2058 Switching (GMPLS) Signaling Resource ReserVation Protocol- 2059 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 2060 DOI 10.17487/RFC3473, January 2003, 2061 . 2063 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 2064 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2065 DOI 10.17487/RFC4090, May 2005, 2066 . 2068 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2069 "Multiprotocol Extensions for BGP-4", RFC 4760, 2070 DOI 10.17487/RFC4760, January 2007, 2071 . 2073 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 2074 Ed., "RSVP-TE Extensions in Support of End-to-End 2075 Generalized Multi-Protocol Label Switching (GMPLS) 2076 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 2077 . 2079 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 2080 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 2081 May 2007, . 2083 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 2084 Extension to Resource ReserVation Protocol-Traffic 2085 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 2086 April 2007, . 2088 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 2089 Ayyangarps, "Encoding of Attributes for MPLS LSP 2090 Establishment Using Resource Reservation Protocol Traffic 2091 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 2092 February 2009, . 2094 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2095 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2096 DOI 10.17487/RFC5440, March 2009, 2097 . 2099 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 2100 S. Ray, "North-Bound Distribution of Link-State and 2101 Traffic Engineering (TE) Information Using BGP", RFC 7752, 2102 DOI 10.17487/RFC7752, March 2016, 2103 . 2105 13.2. Informative References 2107 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2108 McManus, "Requirements for Traffic Engineering Over MPLS", 2109 RFC 2702, DOI 10.17487/RFC2702, September 1999, 2110 . 2112 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2113 (TE) Extensions to OSPF Version 2", RFC 3630, 2114 DOI 10.17487/RFC3630, September 2003, 2115 . 2117 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 2118 in Support of Generalized Multi-Protocol Label Switching 2119 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 2120 . 2122 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2123 Element (PCE)-Based Architecture", RFC 4655, 2124 DOI 10.17487/RFC4655, August 2006, 2125 . 2127 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 2128 BGP, LDP, PCEP, and MSDP Issues According to the Keying 2129 and Authentication for Routing Protocols (KARP) Design 2130 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 2131 . 2133 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 2134 Traffic Engineering (MPLS-TE)", RFC 7308, 2135 DOI 10.17487/RFC7308, July 2014, 2136 . 2138 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 2139 Previdi, "OSPF Traffic Engineering (TE) Metric 2140 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 2141 . 2143 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 2144 Computation Element Communication Protocol (PCEP) 2145 Extensions for Stateful PCE", RFC 8231, 2146 DOI 10.17487/RFC8231, September 2017, 2147 . 2149 Authors' Addresses 2151 Stefano Previdi (editor) 2153 Email: stefano@previdi.net 2155 Ketan Talaulikar 2156 Cisco Systems, Inc. 2158 Email: ketant@cisco.com 2160 Jie Dong (editor) 2161 Huawei Technologies 2162 Huawei Campus, No. 156 Beiqing Rd. 2163 Beijing 100095 2164 China 2166 Email: jie.dong@huawei.com 2168 Mach(Guoyi) Chen 2169 Huawei Technologies 2170 Huawei Campus, No. 156 Beiqing Rd. 2171 Beijing 100095 2172 China 2174 Email: mach.chen@huawei.com 2176 Hannes Gredler 2177 RtBrick Inc. 2179 Email: hannes@rtbrick.com 2181 Jeff Tantsura 2182 Nuage Networks 2184 Email: jefftant.ietf@gmail.com