idnits 2.17.00 (12 Aug 2021) /tmp/idnits42761/draft-ietf-idr-te-lsp-distribution-07.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 (July 1, 2017) is 1785 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: draft-ietf-idr-tunnel-encaps has been published as RFC 9012 == Outdated reference: draft-ietf-pce-stateful-pce has been published as RFC 8231 Summary: 0 errors (**), 0 flaws (~~), 3 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 Cisco Systems, Inc. 4 Intended status: Standards Track J. Dong, Ed. 5 Expires: January 2, 2018 M. Chen 6 Huawei Technologies 7 H. Gredler 8 RtBrick Inc. 9 J. Tantsura 10 Individual 11 July 1, 2017 13 Distribution of Traffic Engineering (TE) Policies and State using BGP-LS 14 draft-ietf-idr-te-lsp-distribution-07 16 Abstract 18 This document describes a mechanism to collect the Traffic 19 Engineering and Policy information that is locally available in a 20 router and advertise it into BGP-LS updates. Such information can be 21 used by external components for path computation, re-optimization, 22 service placement, network visualization, etc. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 2, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Carrying TE Policy Information in BGP . . . . . . . . . . . . 5 66 2.1. TE Policy Information . . . . . . . . . . . . . . . . . . 5 67 2.2. TE Policy NLRI . . . . . . . . . . . . . . . . . . . . . 5 68 2.2.1. TE Policy Descriptors . . . . . . . . . . . . . . . . 7 69 2.3. TE Policy State . . . . . . . . . . . . . . . . . . . . . 12 70 2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 14 71 2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 15 72 2.3.3. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . 16 73 3. Operational Considerations . . . . . . . . . . . . . . . . . 22 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 75 4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 22 76 4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 23 77 4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 23 78 4.4. BGP-LS LSP-State TLV Path Origin . . . . . . . . . . . . 23 79 4.5. BGP-LS LSP-State TLV Dataplane . . . . . . . . . . . . . 24 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 85 8.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 In many network environments, traffic engineering policies are 91 instantiated into various forms: 93 o MPLS Traffic Engineering Label Switched Paths (TE-LSPs). 95 o IP based tunnels (IP in IP, GRE, etc). 97 o Segment Routing Traffic Engineering Policies (SR TE Policy) as 98 defined in [I-D.previdi-idr-segment-routing-te-policy] 100 o Local cross-connect configuration 102 All this information can be grouped into the same term: TE Policies. 103 In the rest of this document we refer to TE Policies as the set of 104 information related to the various instantiation of polices: MPLS TE 105 LSPs, IP tunnels (IPv4 or IPv6), SR TE Policies, etc. 107 TE Polices are generally instantiated by the head-end and are based 108 on either local configuration or controller based programming of the 109 node using various protocols and APIs, e.g., PCEP or BGP. 111 In many network environments, the configuration and state of each TE 112 Policy that is available in the network is required by a controller 113 which allows the network operator to optimize several functions and 114 operations through the use of a controller aware of both topology and 115 state information. 117 One example of a controller is the stateful Path Computation Element 118 (PCE) [I-D.ietf-pce-stateful-pce], which could provide benefits in 119 path reoptimization. While some extensions are proposed in Path 120 Computation Element Communication Protocol (PCEP) for the Path 121 Computation Clients (PCCs) to report the LSP states to the PCE, this 122 mechanism may not be applicable in a management-based PCE 123 architecture as specified in section 5.5 of [RFC4655]. As 124 illustrated in the figure below, the PCC is not an LSR in the routing 125 domain, thus the head-end nodes of the TE-LSPs may not implement the 126 PCEP protocol. In this case a general mechanism to collect the TE- 127 LSP states from the ingress LERs is needed. This document proposes 128 an TE Policy state collection mechanism complementary to the 129 mechanism defined in [I-D.ietf-pce-stateful-pce]. 131 ----------- 132 | ----- | 133 Service | | TED |<-+-----------> 134 Request | ----- | TED synchronization 135 | | | | mechanism (for example, 136 v | | | routing protocol) 137 ------------- Request/ | v | 138 | | Response| ----- | 139 | NMS |<--------+> | PCE | | 140 | | | ----- | 141 ------------- ----------- 142 Service | 143 Request | 144 v 145 ---------- Signaling ---------- 146 | Head-End | Protocol | Adjacent | 147 | Node |<---------->| Node | 148 ---------- ---------- 150 Figure 1. Management-Based PCE Usage 152 In networks with composite PCE nodes as specified in section 5.1 of 153 [RFC4655], PCE is implemented on several routers in the network, and 154 the PCCs in the network can use the mechanism described in 155 [I-D.ietf-pce-stateful-pce] to report the TE Policy information to 156 the PCE nodes. An external component may also need to collect the TE 157 Policy information from all the PCEs in the network to obtain a 158 global view of the LSP state in the network. 160 In multi-area or multi-AS scenarios, each area or AS can have a child 161 PCE to collect the TE Policies in its own domain, in addition, a 162 parent PCE needs to collect TE Policy information from multiple child 163 PCEs to obtain a global view of LSPs inside and across the domains 164 involved. 166 In another network scenario, a centralized controller is used for 167 service placement. Obtaining the TE Policy state information is 168 quite important for making appropriate service placement decisions 169 with the purpose to both meet the application's requirements and 170 utilize network resources efficiently. 172 The Network Management System (NMS) may need to provide global 173 visibility of the TE Policies in the network as part of the network 174 visualization function. 176 BGP has been extended to distribute link-state and traffic 177 engineering information to external components [RFC7752]. Using the 178 same protocol to collect Traffic Engineering and Policy information 179 is desirable for these external components since this avoids 180 introducing multiple protocols for network information collection. 181 This document describes a mechanism to distribute traffic engineering 182 and policy information (MPLS, IPv4 and IPv6) to external components 183 using BGP-LS. 185 2. Carrying TE Policy Information in BGP 187 2.1. TE Policy Information 189 TE Policy information is advertised in BGP UPDATE messages using the 190 MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link- 191 State NLRI" defined in [RFC7752] is extended to carry the TE Policy 192 information. BGP speakers that wish to exchange TE Policy 193 information MUST use the BGP Multiprotocol Extensions Capability Code 194 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 195 [RFC4760]. A new TLV carried in the Link_State Attribute defined in 196 [RFC7752] is also defined in order to carry the attributes of a TE 197 Policy (Section 2.3). 199 The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI 200 Type" is defined for TE Policy Information as following: 202 o NLRI Type: TE Policy NLRI (suggested codepoint value 5, to be 203 assigned by IANA). 205 [RFC7752] defines the BGP-LS NLRI as follows: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | NLRI Type | Total NLRI Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | | 213 // Link-State NLRI (variable) // 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 This document defines a new NLRI-Type and its format: the TE Policy 218 NLRI defined in the following section. 220 2.2. TE Policy NLRI 222 The TE Policy NLRI (NLRI Type 5. Suggested value, to be assigned by 223 IANA) is shown in the following figure: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+ 228 | Protocol-ID | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Identifier | 231 | (64 bits) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 // Headend (Node Descriptors) // 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 // TE Policy Descriptors (variable) // 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 where: 240 o Protocol-ID field specifies the component that owns the TE Policy 241 state in the advertising node. The following Protocol-IDs are 242 defined (suggested values, to be assigned by IANA) and apply to 243 the TE Policy NLRI: 245 +-------------+----------------------------------+ 246 | Protocol-ID | NLRI information source protocol | 247 +-------------+----------------------------------+ 248 | 8 | RSVP-TE | 249 | 9 | Segment Routing | 250 +-------------+----------------------------------+ 252 o "Identifier" is an 8 octet value as defined in [RFC7752]. 254 o "Headend" consists of a Node Descriptor defined in [RFC7752]. 256 o "TE Policy Descriptors" consists of: 258 +-----------+----------------------------------+ 259 | Codepoint | Descriptor TLV | 260 +-----------+----------------------------------+ 261 | 267 | Tunnel ID | 262 | 268 | LSP ID | 263 | 269 | IPv4/6 Tunnel Head-end address | 264 | 270 | IPv4/6 Tunnel Tail-end address | 265 | 271 | SR TE Policy | 266 | 272 | Local Cross Connect | 267 +-----------+----------------------------------+ 269 2.2.1. TE Policy Descriptors 271 This sections defines the TE Policy Descriptors TLVs. 273 2.2.1.1. Tunnel Identifier (Tunnel ID) 275 The Tunnel Identifier TLV contains the Tunnel ID defined in [RFC3209] 276 and has the following format: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Tunnel ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 where: 288 o Type: To be assigned by IANA (suggested value: 267) 290 o Length: 2 octets. 292 o Tunnel ID: 2 octets as defined in [RFC3209]. 294 2.2.1.2. LSP Identifier (LSP ID) 296 The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and 297 has the following format: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type | Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | LSP ID | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 where: 309 o Type: To be assigned by IANA (suggested value: 268) 311 o Length: 2 octets. 313 o LSP ID: 2 octets as defined in [RFC3209]. 315 2.2.1.3. IPv4/IPv6 Tunnel Head-End Address 317 The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head- 318 End Address defined in [RFC3209] and has following format: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 // IPv4/IPv6 Tunnel Head-End Address (variable) // 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 where: 330 o Type: To be assigned by IANA (suggested value: 269) 332 o Length: 4 or 16 octets. 334 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4 335 address, its length is 4 (octets). 337 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6 338 address, its length is 16 (octets). 340 2.2.1.4. IPv4/IPv6 Tunnel Tail-End Address 342 The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel Tail- 343 End Address defined in [RFC3209] and has following format: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 // IPv4/IPv6 Tunnel Tail-End Address (variable) // 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 where: 355 o Type: To be assigned by IANA (suggested value: 270) 357 o Length: 4 or 16 octets. 359 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4 360 address, its length is 4 (octets). 362 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6 363 address, its length is 16 (octets). 365 2.2.1.5. SR TE Policy TLV 367 The SR TE Policy TLV identifies a SR TE Policy as defined in 368 [I-D.previdi-idr-segment-routing-te-policy] and has the following 369 format: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Distinguisher (4 octets) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Policy Color (4 octets) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Endpoint (4 or 16 octets) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 where: 385 o Type: To be assigned by IANA (suggested value: 271) 387 o Length: 12 octets. 389 o Distinguisher, Policy Color and Endpoint are defined in 390 [I-D.previdi-idr-segment-routing-te-policy]. 392 2.2.1.6. MPLS Cross Connect 394 The MPLS Cross Connect TLV identifies a local MPLS state in the form 395 of incoming label and interface followed by an outgoing label and 396 interface. Outgoing interface may appear multiple times (for 397 multicast states). 399 The Local Cross Connect TLV has the following format: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type | Length | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Incoming label (4 octets) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Outgoing label (4 octets) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 // Sub-TLVs (variable) // 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 where: 415 o Type: To be assigned by IANA (suggested value: 271) 417 o Length: variable. 419 o Incoming and Outgoing labels: 4 octets each. 421 o Sub-TLVs: following Sub-TLVs are defined: 423 * Interface Sub-TLV 425 * Forwarding Equivalent Class (FEC) 427 The MPLS Cross Connect TLV: 429 MUST have an incoming label. 431 MUST have an outgoing label. 433 MAY contain an Interface Sub-TLV having the I-flag set. 435 MUST contain at least one Interface Sub-TLV having the I-flag 436 unset. 438 MAY contain multiple Interface Sub-TLV having the I-flag unset. 439 This is the case of a multicast MPLS cross connect. 441 MAY contain a FEC Sub-TLV. 443 2.2.1.6.1. MPLS Cross Connect Sub-TLVs 444 2.2.1.6.1.1. Interface Sub-TLV 446 The Interface sub-TLV is optional and contains the identifier of the 447 interface (incoming or outgoing) in the form of an IPv4 address or an 448 IPv6 address. 450 The Interface sub-TLV has the following format: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 +-+-+-+-+-+-+-+-+ 459 | Flags | 460 +-+-+-+-+-+-+-+-+ 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Local Interface Identifier (4 octets) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 // Interface Address (4 or 16 octets) // 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 where: 470 o Type: To be assigned by IANA (suggested value: 1) 472 o Length: 9 or 21. 474 o Flags: 1 octet of flags defined as follows: 476 0 1 2 3 4 5 6 7 477 +-+-+-+-+-+-+-+-+ 478 |I| | 479 +-+-+-+-+-+-+-+-+ 481 where: 483 * I-Flag is the Interface flag. When set, the Interface Sub-TLV 484 describes an incoming interface. If the I-flag is not set, 485 then the Interface Sub-TLV describes an outgoing interface. 487 o Local Interface Identifier: a 4 octet identifier. 489 o Interface address: a 4 octet IPv4 address or a 16 octet IPv6 490 address. 492 2.2.1.6.1.2. Forwarding Equivalent Class (FEC) Sub-TLV 494 The FEC sub-TLV is optional and contains the FEC associated to the 495 incoming label. 497 The FEC sub-TLV has the following format: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Length | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Flags | Masklength | Prefix (variable) // 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 // Prefix (variable) // 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 where: 511 o Type: To be assigned by IANA (suggested value: 2) 513 o Length: variable. 515 o Flags: 1 octet of flags defined as follows: 517 0 1 2 3 4 5 6 7 518 +-+-+-+-+-+-+-+-+ 519 |4| | 520 +-+-+-+-+-+-+-+-+ 522 where: 524 * 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes 525 an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV 526 describes an IPv6 FEC. 528 o Mask Length: 1 octet of prefix length. 530 o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the " 531 Mask Length" field. 533 2.3. TE Policy State 535 A new TLV called "TE Policy State TLV" (codepoint to be assigned by 536 IANA), is used to describe the characteristics of the TE Policy, 537 which is carried in the optional non-transitive BGP Attribute 538 "LINK_STATE Attribute" defined in [RFC7752]. These TE Policy 539 characteristics include the characteristics and attributes of the 540 policy, it's dataplane, explicit path, Quality of Service (QoS) 541 parameters, route information, the protection mechanisms, etc. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Path-origin | Dataplane | RESERVED | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 // TE Policy State Sub-TLVs (variable) // 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 where: 557 TE Policy State TLV 559 o Type: Suggested value 1158 (to be assigned by IANA) 561 o Length: the total length of the TE Policy State TLV not including 562 Type and Length fields. 564 o Path-origin: identifies the component (or protocol) from which the 565 contained object originated. This allows for objects defined in 566 different components to be collected while avoiding the possible 567 code collisions among these components. Following path-origin 568 codepoints are defined in this document (suggested values, to be 569 assigned by IANA). 571 +----------+------------------+ 572 | Code | Path | 573 | Point | Origin | 574 +----------+------------------+ 575 | 1 | RSVP-TE | 576 | 2 | PCE | 577 | 3 | BGP SR TE Policy | 578 | 4 | NETCONF | 579 | 5 | Static | 580 +----------+------------------+ 582 o Dataplane: describes to which dataplane the policy is applied to. 583 The following dataplane values are defined: 585 +----------+------------------+ 586 | Code | Dataplane | 587 | Point | | 588 +----------+------------------+ 589 | 1 | MPLS-IPv4 | 590 | 2 | MPLS-IPv6 | 591 | 3 | IPv6 | 592 +----------+------------------+ 594 o RESERVED: 16-bit field field. SHOULD be set to 0 on transmission 595 and MUST be ignored on receipt. 597 TE Policy State sub-TLVs: objects as defined in [RFC3209],[RFC3473], 598 [RFC5440] and [I-D.previdi-idr-segment-routing-te-policy]. Rather 599 than replicating all these objects in this document, the semantics 600 and encodings of the objects are reused. These objects are carried 601 in the "TE Policy State Information" with the following format. 603 2.3.1. RSVP Objects 605 RSVP-TE objects are encoded in the "Value" field of the LSP State TLV 606 and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209] 607 [RFC3473]. Rather than replicating all MPLS TE LSP related objects 608 in this document, the semantics and encodings of the MPLS TE LSP 609 objects are re-used. These MPLS TE LSP objects are carried in the 610 LSP State TLV. 612 When carrying RSVP-TE objects, the "Path-Origin" field is set to 613 "RSVP-TE". 615 The following RSVP-TE Objects are defined: 617 o SENDER_TSPEC and FLOW_SPEC [RFC2205] 619 o SESSION_ATTRIBUTE [RFC3209] 621 o EXPLICIT_ROUTE Object (ERO) [RFC3209] 623 o ROUTE_RECORD Object (RRO) [RFC3209] 625 o FAST_REROUTE Object [RFC4090] 627 o DETOUR Object [RFC4090] 629 o EXCLUDE_ROUTE Object (XRO) [RFC4874] 631 o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873] 632 o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873] 634 o LSP_ATTRIBUTES Object [RFC5420] 636 o LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 638 o PROTECTION Object [RFC3473][RFC4872][RFC4873] 640 o ASSOCIATION Object [RFC4872] 642 o PRIMARY_PATH_ROUTE Object [RFC4872] 644 o ADMIN_STATUS Object [RFC3473] 646 o LABEL_REQUEST Object [RFC3209][RFC3473] 648 For the MPLS TE LSP Objects listed above, the corresponding sub- 649 objects are also applicable to this mechanism. Note that this list 650 is not exhaustive, other MPLS TE LSP objects which reflect specific 651 characteristics of the MPLS TE LSP can also be carried in the LSP 652 state TLV. 654 2.3.2. PCE Objects 656 PCE objects are encoded in the "Value" field of the MPLS TE LSP State 657 TLV and consists of PCE objects defined in [RFC5440]. Rather than 658 replicating all MPLS TE LSP related objects in this document, the 659 semantics and encodings of the MPLS TE LSP objects are re-used. 660 These MPLS TE LSP objects are carried in the LSP State TLV. 662 When carrying PCE objects, the "Path-Origin" field is set to "PCE". 664 The following PCE Objects are defined: 666 o METRIC Object [RFC5440] 668 o BANDWIDTH Object [RFC5440] 670 For the MPLS TE LSP Objects listed above, the corresponding sub- 671 objects are also applicable to this mechanism. Note that this list 672 is not exhaustive, other MPLS TE LSP objects which reflect specific 673 characteristics of the MPLS TE LSP can also be carried in the LSP 674 state TLV. 676 2.3.3. SR TE Policy Sub-TLVs 678 Segment Routing Traffic Engineering Policy (SR TE Policy) as 679 described in [I-D.previdi-idr-segment-routing-te-policy]makes use of 680 the Tunnel Encapsulation Attribute defined in 681 [I-D.ietf-idr-tunnel-encaps] and defines following sub-TLVs: 683 o Preference 685 o Binding SID 687 o Weight 689 o Segment List 691 o Segment 693 The equivalent sub-TLVs are defined hereafter and carried in the TE 694 Policy State TLV. When carrying SR TE Policy objects, the "Path- 695 Origin" field is set to "BGP SR TE Policy". 697 2.3.3.1. Preference Object 699 The Preference sub-TLV has the following format: 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type | Length | Flags | RESERVED | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Preference (4 octets) | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 All fields, including type and length, are defined in 710 [I-D.previdi-idr-segment-routing-te-policy]. 712 2.3.3.2. SR TE Binding SID Sub-TLV 714 The Binding SID sub-TLV has the following format: 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type | Length | Flags | RESERVED | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Binding SID (variable, optional) | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 All fields, including type and length, are defined in 724 [I-D.previdi-idr-segment-routing-te-policy]. 726 [I-D.previdi-idr-segment-routing-te-policy] specifies the Binding SID 727 sub-TLV which carries an indication of which value to allocate as 728 Binding SID to the SR TE Policy. In the context of the BGP-LS 729 extensions defined in this document, the Binding SID sub-TLV to the 730 reciever of the , the Binding SID TLThe Binding SID sub-TLV contains 731 the Binding SID the originator of the BGP-LS update has allocated to 732 the corresponding SR TE Policy. 734 In the context of BGP-LS, the Binding SID sub-TLV defined in this 735 document, contains the effective value of the Binding SID that the 736 router allocated to the SR TE Policy. The router is the SR TE Policy 737 receiver (as described in 738 [I-D.previdi-idr-segment-routing-te-policy]) and it is also the 739 originator of the corresponding BGP-LS update with the extensions 740 defined in this document. 742 2.3.3.3. Weight Sub-TLV 744 The Weight sub-TLV has the following format: 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Type | Length | Flags | RESERVED | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Weight | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 All fields, including type and length, are defined in 755 [I-D.previdi-idr-segment-routing-te-policy]. 757 2.3.3.4. Segment List Sub-TLV 759 The Segment List object contains sub-TLVs (which in fact are sub-sub- 760 TLVs) and has following format: 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type | Length | RESERVED | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 // sub-TLVs // 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 o All fields, including type and length, are defined in 770 [I-D.previdi-idr-segment-routing-te-policy]. 772 o Length is the total length (not including the Type and Length 773 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 775 o sub-objects: 777 * An optional single Weight sub-TLV. 779 * One or more Segment sub-TLVs. 781 The Segment List sub-TLV is mandatory. 783 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 784 TE Policy. 786 2.3.3.5. Segment Sub-TLV 788 The Segment sub-TLV describes a single segment in a segment list 789 (i.e.: a single element of the explicit path). Multiple Segment sub- 790 TLVs constitute an explicit path of the SR TE Policy. 792 [I-D.previdi-idr-segment-routing-te-policy] defines 8 different types 793 of Segment Sub-TLVs: 795 Type 1: SID only, in the form of MPLS Label 796 Type 2: SID only, in the form of IPv6 address 797 Type 3: IPv4 Node Address with optional SID 798 Type 4: IPv6 Node Address with optional SID 799 Type 5: IPv4 Address + index with optional SID 800 Type 6: IPv4 Local and Remote addresses with optional SID 801 Type 7: IPv6 Address + index with optional SID 802 Type 8: IPv6 Local and Remote addresses with optional SID 804 2.3.3.5.1. Type 1: SID only, in the form of MPLS Label 806 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 807 MPLS label. The format is as follows: 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Type | Length | Flags | RESERVED | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Label | TC |S| TTL | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Type, Length and values are defined in 817 [I-D.previdi-idr-segment-routing-te-policy]. 819 2.3.3.5.2. Type 2: SID only, in the form of IPv6 address 821 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 822 IPv6 address. The format is as follows: 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Type | Length | Flags | RESERVED | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 // IPv6 SID (16 octets) // 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Type, Length and values are defined in 833 [I-D.previdi-idr-segment-routing-te-policy]. 835 2.3.3.5.3. Type 3: IPv4 Node Address with optional SID 837 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 838 optional SID in the form of either an MPLS label or an IPv6 address. 839 The format is as follows: 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type | Length | Flags | RESERVED | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | IPv4 Node Address (4 octets) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 // SID (optional, 4 or 16 octets) // 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Type, Length and values are defined in 852 [I-D.previdi-idr-segment-routing-te-policy]. 854 2.3.3.5.4. Type 4: IPv6 Node Address with optional SID 856 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 857 optional SID in the form of either an MPLS label or an IPv6 address. 858 The format is as follows: 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Type | Length | Flags | RESERVED | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 // IPv6 Node Address (16 octets) // 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 // SID (optional, 4 or 16 octets) // 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 Type, Length and values are defined in 871 [I-D.previdi-idr-segment-routing-te-policy]. 873 2.3.3.5.5. Type 5: IPv4 Address + index with optional SID 875 The Type-5 Segment Sub-TLV encodes an IPv4 node address, an interface 876 index and an optional SID in the form of either an MPLS label or an 877 IPv6 address. The format is as follows: 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type | Length | Flags | RESERVED | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | IfIndex (4 octets) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | IPv4 Node Address (4 octets) | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 // SID (optional, 4 or 16 octets) // 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Type, Length and values are defined in 892 [I-D.previdi-idr-segment-routing-te-policy]. 894 2.3.3.5.6. Type 6: IPv4 Local and Remote addresses with optional SID 896 The Type-6 Segment Sub-TLV encodes an IPv4 node address, an adjacency 897 local address, an adjacency remote address and an optional SID in the 898 form of either an MPLS label or an IPv6 address. The format is as 899 follows: 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Type | Length | Flags | RESERVED | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Local IPv4 Address (4 octets) | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Remote IPv4 Address (4 octets) | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 // SID (4 or 16 octets) // 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Type, Length and values are defined in 914 [I-D.previdi-idr-segment-routing-te-policy]. 916 2.3.3.5.7. Type 7: IPv6 Address + index with optional SID 918 The Type-7 Segment Sub-TLV encodes an IPv6 node address, an interface 919 index and an optional SID in the form of either an MPLS label or an 920 IPv6 address. The format is as follows: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Length | Flags | RESERVED | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | IfIndex (4 octets) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 // IPv6 Node Address (16 octets) // 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 // SID (optional, 4 or 16 octets) // 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Type, Length and values are defined in 935 [I-D.previdi-idr-segment-routing-te-policy]. 937 2.3.3.5.8. Type 8: IPv6 Local and Remote addresses with optional SID 939 The Type-8 Segment Sub-TLV encodes an IPv6 node address, an adjacency 940 local address, an adjacency remote address and an optional SID in the 941 form of either an MPLS label or an IPv6 address. The format is as 942 follows: 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | Flags | RESERVED | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 // Local IPv6 Address (16 octets) // 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 // Remote IPv6 Address (16 octets) // 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 // SID (4 or 16 octets) // 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Type, Length and values are defined in 957 [I-D.previdi-idr-segment-routing-te-policy]. 959 3. Operational Considerations 961 The Existing BGP operational procedures apply to this document. No 962 new operation procedures are defined in this document. The 963 operational considerations as specified in [RFC7752] apply to this 964 document. 966 In general, it is assumed that the TE Policy head-end nodes are 967 responsible for the distribution of TE Policy state information, 968 while other nodes, e.g. the nodes in the path of a policy, MAY report 969 the TE Policy information (if available) when needed. For example, 970 the border routers in the inter-domain case will also distribute LSP 971 state information since the ingress node may not have the complete 972 information for the end-to-end path. 974 4. IANA Considerations 976 This document requires new IANA assigned codepoints. 978 4.1. BGP-LS NLRI-Types 980 IANA maintains a registry called "Border Gateway Protocol - Link 981 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI- 982 Types". 984 The following codepoints is suggested (to be assigned by IANA): 986 +------+----------------------------+---------------+ 987 | Type | NLRI Type | Reference | 988 +------+----------------------------+---------------+ 989 | 5 | TE Policy NLRI type | this document | 990 +------+----------------------------+---------------+ 992 4.2. BGP-LS Protocol-IDs 994 IANA maintains a registry called "Border Gateway Protocol - Link 995 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS 996 Protocol-IDs". 998 The following Protocol-ID codepoints are suggested (to be assigned by 999 IANA): 1001 +-------------+----------------------------------+---------------+ 1002 | Protocol-ID | NLRI information source protocol | Reference | 1003 +-------------+----------------------------------+---------------+ 1004 | 8 | RSVP-TE | this document | 1005 | 9 | Segment Routing | this document | 1006 +-------------+----------------------------------+---------------+ 1008 4.3. BGP-LS Descriptors TLVs 1010 IANA maintains a registry called "Border Gateway Protocol - Link 1011 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 1012 Link Descriptor and Link Attribute TLVs". 1014 The following TLV codepoints are suggested (to be assigned by IANA): 1016 +----------+--------------------------------------+---------------+ 1017 | TLV Code | Description | Value defined | 1018 | Point | | in | 1019 +----------+--------------------------------------+---------------+ 1020 | 1158 | TE Policy State TLV | this document | 1021 | 267 | Tunnel ID TLV | this document | 1022 | 268 | LSP ID TLV | this document | 1023 | 269 | IPv4/6 Tunnel Head-end address TLV | this document | 1024 | 270 | IPv4/6 Tunnel Tail-end address TLV | this document | 1025 | 271 | SR TE Policy Identifier TLV | this document | 1026 +----------+--------------------------------------+---------------+ 1028 4.4. BGP-LS LSP-State TLV Path Origin 1030 This document requests IANA to maintain a new sub-registry under 1031 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1032 registry is called "Path Origin" and contains the codepoints 1033 allocated to the "Path Origin" field defined in Section 2.3. The 1034 registry contains the following codepoints (suggested values, to be 1035 assigned by IANA): 1037 +----------+------------------+ 1038 | Code | Path | 1039 | Point | Origin | 1040 +----------+------------------+ 1041 | 1 | RSVP-TE | 1042 | 2 | PCE | 1043 | 3 | BGP SR TE Policy | 1044 | 4 | NETCONF | 1045 | 5 | Static | 1046 +----------+------------------+ 1048 4.5. BGP-LS LSP-State TLV Dataplane 1050 This document requests IANA to maintain a new sub-registry under 1051 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1052 registry is called "Dataplane" and contains the codepoints allocated 1053 to the "dataplane" field defined in Section 2.3. The registry 1054 contains the following codepoints (suggested values, to be assigned 1055 by IANA): 1057 +----------+------------------+ 1058 | Code | Dataplane | 1059 | Point | | 1060 +----------+------------------+ 1061 | 1 | MPLS-IPv4 | 1062 | 2 | MPLS-IPv6 | 1063 | 3 | IPv6 | 1064 +----------+------------------+ 1066 5. Security Considerations 1068 Procedures and protocol extensions defined in this document do not 1069 affect the BGP security model. See [RFC6952] for details. 1071 6. Acknowledgements 1073 The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz 1074 Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah, 1075 and Dhanendra Jain for their review and valuable comments. 1077 7. Contributors 1079 The following people have substantially contributed to the editing of 1080 this document: 1082 Ketan Talaulikar 1083 Cisco Systems 1084 Email: ketant@cisco.com 1085 Clarence Filsfils 1086 Cisco Systems 1087 Email: cfilsfil@cisco.com 1089 8. References 1091 8.1. Normative References 1093 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, 1095 DOI 10.17487/RFC2119, March 1997, 1096 . 1098 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1099 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1100 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1101 September 1997, . 1103 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1104 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1105 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1106 . 1108 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1109 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1110 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1111 DOI 10.17487/RFC3473, January 2003, 1112 . 1114 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1115 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1116 DOI 10.17487/RFC4090, May 2005, 1117 . 1119 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1120 "Multiprotocol Extensions for BGP-4", RFC 4760, 1121 DOI 10.17487/RFC4760, January 2007, 1122 . 1124 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1125 Ed., "RSVP-TE Extensions in Support of End-to-End 1126 Generalized Multi-Protocol Label Switching (GMPLS) 1127 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1128 . 1130 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1131 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1132 May 2007, . 1134 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1135 Extension to Resource ReserVation Protocol-Traffic 1136 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 1137 April 2007, . 1139 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1140 Ayyangarps, "Encoding of Attributes for MPLS LSP 1141 Establishment Using Resource Reservation Protocol Traffic 1142 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1143 February 2009, . 1145 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1146 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1147 DOI 10.17487/RFC5440, March 2009, 1148 . 1150 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1151 S. Ray, "North-Bound Distribution of Link-State and 1152 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1153 DOI 10.17487/RFC7752, March 2016, 1154 . 1156 8.2. Informative References 1158 [I-D.ietf-idr-tunnel-encaps] 1159 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1160 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-06 1161 (work in progress), June 2017. 1163 [I-D.ietf-pce-stateful-pce] 1164 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1165 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1166 pce-21 (work in progress), June 2017. 1168 [I-D.previdi-idr-segment-routing-te-policy] 1169 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. 1170 Lin, "Advertising Segment Routing Policies in BGP", draft- 1171 previdi-idr-segment-routing-te-policy-07 (work in 1172 progress), June 2017. 1174 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1175 Element (PCE)-Based Architecture", RFC 4655, 1176 DOI 10.17487/RFC4655, August 2006, 1177 . 1179 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1180 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1181 and Authentication for Routing Protocols (KARP) Design 1182 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1183 . 1185 Authors' Addresses 1187 Stefano Previdi (editor) 1188 Cisco Systems, Inc. 1190 Email: stefano@previdi.net 1192 Jie Dong (editor) 1193 Huawei Technologies 1194 Huawei Campus, No. 156 Beiqing Rd. 1195 Beijing 100095 1196 China 1198 Email: jie.dong@huawei.com 1200 Mach(Guoyi) Chen 1201 Huawei Technologies 1202 Huawei Campus, No. 156 Beiqing Rd. 1203 Beijing 100095 1204 China 1206 Email: mach.chen@huawei.com 1208 Hannes Gredler 1209 RtBrick Inc. 1211 Email: hannes@rtbrick.com 1213 Jeff Tantsura 1214 Individual 1216 Email: jefftant@gmail.com