idnits 2.17.1 draft-ietf-idr-te-lsp-distribution-05.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 6, 2016) is 2850 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-02 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 == Outdated reference: A later version (-07) exists of draft-previdi-idr-segment-routing-te-policy-01 Summary: 1 error (**), 0 flaws (~~), 4 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 7, 2017 M. Chen 6 Huawei Technologies 7 H. Gredler 8 RtBrick Inc. 9 J. Tantsura 10 Individual 11 July 6, 2016 13 Distribution of Traffic Engineering (TE) Policies and State using BGP-LS 14 draft-ietf-idr-te-lsp-distribution-05 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 7, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 15 73 3. Operational Considerations . . . . . . . . . . . . . . . . . 21 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 75 4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 22 76 4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 22 77 4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 22 78 4.4. BGP-LS LSP-State TLV Protocol Origin . . . . . . . . . . 23 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 83 7.2. Informative References . . . . . . . . . . . . . . . . . 25 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 86 1. Introduction 88 In many network environments, traffic engineering policies are 89 instantiated into various forms: 91 o MPLS Traffic Engineering Label Switched Paths (TE-LSPs). 93 o IP based tunnels (IP in IP, GRE, etc). 95 o Segment Routing Traffic Engineering Policies (SR TE Policy) as 96 defined in [I-D.previdi-idr-segment-routing-te-policy] 98 o Local cross-connect configuration 100 All this information can be grouped into the same term: TE Policies. 101 In the rest of this document we refer to TE Policies as the set of 102 information related to the various instantiation of polices: MPLS TE 103 LSPs, IP tunnels (IPv4 or IPv6), SR TE Policies, etc. 105 TE Polices are generally instantiated by the head-end and are based 106 on either local configuration or controller based programming of the 107 node using various protocols and APIs, e.g., PCEP or BGP. 109 In many network environments, the configuration and state of each TE 110 Policy that is available in the network is required by a controller 111 which allows the network operator to optimize several functions and 112 operations through the use of a controller aware of both topology and 113 state information. 115 One example of a controller is the stateful Path Computation Element 116 (PCE) [I-D.ietf-pce-stateful-pce], which could provide benefits in 117 path reoptimization. While some extensions are proposed in Path 118 Computation Element Communication Protocol (PCEP) for the Path 119 Computation Clients (PCCs) to report the LSP states to the PCE, this 120 mechanism may not be applicable in a management-based PCE 121 architecture as specified in section 5.5 of [RFC4655]. As 122 illustrated in the figure below, the PCC is not an LSR in the routing 123 domain, thus the head-end nodes of the TE-LSPs may not implement the 124 PCEP protocol. In this case a general mechanism to collect the TE- 125 LSP states from the ingress LERs is needed. This document proposes 126 an TE Policy state collection mechanism complementary to the 127 mechanism defined in [I-D.ietf-pce-stateful-pce]. 129 ----------- 130 | ----- | 131 Service | | TED |<-+-----------> 132 Request | ----- | TED synchronization 133 | | | | mechanism (for example, 134 v | | | routing protocol) 135 ------------- Request/ | v | 136 | | Response| ----- | 137 | NMS |<--------+> | PCE | | 138 | | | ----- | 139 ------------- ----------- 140 Service | 141 Request | 142 v 143 ---------- Signaling ---------- 144 | Head-End | Protocol | Adjacent | 145 | Node |<---------->| Node | 146 ---------- ---------- 148 Figure 1. Management-Based PCE Usage 150 In networks with composite PCE nodes as specified in section 5.1 of 151 [RFC4655], PCE is implemented on several routers in the network, and 152 the PCCs in the network can use the mechanism described in 153 [I-D.ietf-pce-stateful-pce] to report the TE Policy information to 154 the PCE nodes. An external component may also need to collect the TE 155 Policy information from all the PCEs in the network to obtain a 156 global view of the LSP state in the network. 158 In multi-area or multi-AS scenarios, each area or AS can have a child 159 PCE to collect the TE Policies in its own domain, in addition, a 160 parent PCE needs to collect TE Policy information from multiple child 161 PCEs to obtain a global view of LSPs inside and across the domains 162 involved. 164 In another network scenario, a centralized controller is used for 165 service placement. Obtaining the TE Policy state information is 166 quite important for making appropriate service placement decisions 167 with the purpose to both meet the application's requirements and 168 utilize network resources efficiently. 170 The Network Management System (NMS) may need to provide global 171 visibility of the TE Policies in the network as part of the network 172 visualization function. 174 BGP has been extended to distribute link-state and traffic 175 engineering information to external components [RFC7752]. Using the 176 same protocol to collect Traffic Engineering and Policy information 177 is desirable for these external components since this avoids 178 introducing multiple protocols for network information collection. 179 This document describes a mechanism to distribute traffic engineering 180 and policy information (MPLS, IPv4 and IPv6) to external components 181 using BGP-LS. 183 2. Carrying TE Policy Information in BGP 185 2.1. TE Policy Information 187 TE Policy information is advertised in BGP UPDATE messages using the 188 MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link- 189 State NLRI" defined in [RFC7752] is extended to carry the TE Policy 190 information. BGP speakers that wish to exchange TE Policy 191 information MUST use the BGP Multiprotocol Extensions Capability Code 192 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 193 [RFC4760]. 195 The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI 196 Type" is defined for TE Policy Information as following: 198 o NLRI Type: TE Policy NLRI (suggested codepoint value 5, to be 199 assigned by IANA). 201 [RFC7752] defines the BGP-LS NLRI as follows: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | NLRI Type | Total NLRI Length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 // Link-State NLRI (variable) // 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 This document defines a new NLRI-Type and its format: the TE Policy 214 NLRI defined in the following section. 216 2.2. TE Policy NLRI 218 The TE Policy NLRI (NLRI Type 5. Suggested value, to be assigned by 219 IANA) is shown in the following figure: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+ 224 | Protocol-ID | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Identifier | 227 | (64 bits) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 // TE Policy Descriptors (variable) // 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 where: 234 o Protocol-ID field specifies the signaling protocol of the TE 235 Policy. The following Protocol-IDs are defined (suggested values, 236 to be assigned by IANA) and apply to the TE Policy NLRI: 238 +-------------+----------------------------------+ 239 | Protocol-ID | NLRI information source protocol | 240 +-------------+----------------------------------+ 241 | 8 | RSVP-TE | 242 | 9 | Segment Routing | 243 +-------------+----------------------------------+ 245 o "Identifier" is an 8 octet value as defined in [RFC7752]. 247 o Following TE Policy Descriptors are defined: 249 +-----------+----------------------------------+ 250 | Codepoint | Descriptor TLV | 251 +-----------+----------------------------------+ 252 | 267 | Tunnel ID | 253 | 268 | LSP ID | 254 | 269 | IPv4/6 Tunnel Head-end address | 255 | 270 | IPv4/6 Tunnel Tail-end address | 256 | 271 | SR TE Policy | 257 | 272 | Local Cross Connect | 258 +-----------+----------------------------------+ 260 2.2.1. TE Policy Descriptors 262 This sections defines the TE Policy Descriptors TLVs. 264 2.2.1.1. Tunnel Identifier (Tunnel ID) 266 The Tunnel Identifier TLV contains the Tunnel ID defined in [RFC3209] 267 and has the following format: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Tunnel ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 where: 279 o Type: To be assigned by IANA (suggested value: 267) 281 o Length: 2 octets. 283 o Tunnel ID: 2 octets as defined in [RFC3209]. 285 2.2.1.2. LSP Identifier (LSP ID) 287 The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and 288 has the following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | LSP ID | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 where: 300 o Type: To be assigned by IANA (suggested value: 268) 302 o Length: 2 octets. 304 o LSP ID: 2 octets as defined in [RFC3209]. 306 2.2.1.3. IPv4/IPv6 Tunnel Head-End Address 308 The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head- 309 End Address defined in [RFC3209] and has following format: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 // IPv4/IPv6 Tunnel Head-End Address (variable) // 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 where: 321 o Type: To be assigned by IANA (suggested value: 269) 323 o Length: 4 or 16 octets. 325 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4 326 address, its length is 4 (octets). 328 When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6 329 address, its length is 16 (octets). 331 2.2.1.4. IPv4/IPv6 Tunnel Tail-End Address 333 The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel Tail- 334 End Address defined in [RFC3209] and has following format: 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 // IPv4/IPv6 Tunnel Tail-End Address (variable) // 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 where: 346 o Type: To be assigned by IANA (suggested value: 270) 348 o Length: 4 or 16 octets. 350 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4 351 address, its length is 4 (octets). 353 When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6 354 address, its length is 16 (octets). 356 2.2.1.5. SR TE Policy TLV 358 The SR TE Policy TLV identifies a SR TE Policy as defined in 359 [I-D.previdi-idr-segment-routing-te-policy] and has the following 360 format: 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Distinguisher (4 octets) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Policy Color (4 octets) | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Endpoint (4 or 16 octets) | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 where: 376 o Type: To be assigned by IANA (suggested value: 271) 378 o Length: 12 octets. 380 o Distinguisher, Policy Color and Endpoint are defined in 381 [I-D.previdi-idr-segment-routing-te-policy]. 383 2.2.1.6. MPLS Cross Connect 385 The MPLS Cross Connect TLV identifies a local MPLS state in the form 386 of incoming label and interface followed by an outgoing label and 387 interface. Outgoing interface may appear multiple times (for 388 multicast states). 390 The Local Cross Connect TLV has the following format: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Incoming label (4 octets) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Outgoing label (4 octets) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 // Sub-TLVs (variable) // 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 where: 406 o Type: To be assigned by IANA (suggested value: 271) 408 o Length: variable. 410 o Incoming and Outgoing labels: 4 octets each. 412 o Sub-TLVs: following Sub-TLVs are defined: 414 * Interface Sub-TLV 416 * Forwarding Equivalent Class (FEC) 418 The MPLS Cross Connect TLV: 420 MUST have an incoming label. 422 MUST have an outgoing label. 424 MAY contain an Interface Sub-TLV having the I-flag set. 426 MUST contain at least one Interface Sub-TLV having the I-flag 427 unset. 429 MAY contain multiple Interface Sub-TLV having the I-flag unset. 430 This is the case of a multicast MPLS cross connect. 432 MAY contain a FEC Sub-TLV. 434 2.2.1.6.1. MPLS Cross Connect Sub-TLVs 435 2.2.1.6.1.1. Interface Sub-TLV 437 The Interface sub-TLV is optional and contains the identifier of the 438 interface (incoming or outgoing) in the form of an IPv4 address or an 439 IPv6 address. 441 The Interface sub-TLV has the following format: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type | Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Flags | Interface Address (4 or 16 octets) // 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 where: 453 o Type: To be assigned by IANA (suggested value: 1) 455 o Length: 5 or 17. 457 o Flags: 1 octet of flags defined as follows: 459 0 1 2 3 4 5 6 7 460 +-+-+-+-+-+-+-+-+ 461 |I| | 462 +-+-+-+-+-+-+-+-+ 464 where: 466 * I-Flag is the Interface flag. When set, the Interface Sub-TLV 467 describes an incoming interface. If the I-flag is not set, 468 then the Interface Sub-TLV describes an outgoing interface. 470 o Interface address: a 4 octet IPv4 address or a 16 octet IPv6 471 address. 473 2.2.1.6.1.2. Forwarding Equivalent Class (FEC) Sub-TLV 475 The FEC sub-TLV is optional and contains the FEC associated to the 476 incoming label. 478 The FEC sub-TLV has the following format: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Flags | Masklength | Prefix (variable) // 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 // Prefix (variable) // 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 where: 492 o Type: To be assigned by IANA (suggested value: 2) 494 o Length: variable. 496 o Flags: 1 octet of flags defined as follows: 498 0 1 2 3 4 5 6 7 499 +-+-+-+-+-+-+-+-+ 500 |4| | 501 +-+-+-+-+-+-+-+-+ 503 where: 505 * 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes 506 an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV 507 describes an IPv6 FEC. 509 o Mask Length: 1 octet of prefix length. 511 o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the " 512 Mask Length" field. 514 2.3. TE Policy State 516 A new TLV called "TE Policy State TLV" (codepoint to be assigned by 517 IANA), is used to describe the characteristics of the TE Policy, 518 which is carried in the optional non-transitive BGP Attribute 519 "LINK_STATE Attribute" defined in [RFC7752]. These TE Policy 520 characteristics include the characteristics and attributs of the 521 policy, it's dataplane, explicit path, Quality of Service (QoS) 522 parameters, route information, the protection mechanisms, etc. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Type | Length | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 // TE Policy State Information (variable) // 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 TE Policy State TLV 536 Type: Suggested value 1158 (to be assigned by IANA) 538 TE Policy State Information: Consists of a set of objects as defined 539 in [RFC3209],[RFC3473], [RFC5440] and 540 [I-D.previdi-idr-segment-routing-te-policy]. Rather than replicating 541 all these objects in this document, the semantics and encodings of 542 the objects are reused. These objects are carried in the "TE Policy 543 State Information" with the following format. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |Protocol-Origin| Reserved | Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | | 551 // Protocol specific TE Policy objects // 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 TE Policy State Information 557 The Protocol-Origin field identifies the protocol from which the 558 contained object originated. This allows for objects defined in 559 different protocols to be collected while avoiding the possible code 560 collisions among these protocols. Three Protocol-Origins are defined 561 in this document (suggested values, to be assigned by IANA) 563 +----------+------------------+ 564 | Protocol | LSP Object | 565 | Origin | Origin | 566 +----------+------------------+ 567 | 1 | RSVP-TE | 568 | 2 | PCE | 569 | 3 | BGP SR TE Policy | 570 +----------+------------------+ 572 The 8-bit Reserved field SHOULD be set to 0 on transmission and MUST 573 be ignored on receipt. 575 The Length field is set to the Length of the value field, which is 576 the total length of the contained object. 578 The Valued field is a TE Policy object which is defined in the 579 protocol identified by the Protocol-Origin field. 581 2.3.1. RSVP Objects 583 RSVP-TE objects are encoded in the "Value" field of the LSP State TLV 584 and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209] 585 [RFC3473]. Rather than replicating all MPLS TE LSP related objects 586 in this document, the semantics and encodings of the MPLS TE LSP 587 objects are re-used. These MPLS TE LSP objects are carried in the 588 LSP State TLV. 590 When carrying RSVP-TE objects, the "Protocol-Origin" field is set to 591 "RSVP-TE" (suggested value 1, to be assigned by IANA). 593 The following RSVP-TE Objects are defined: 595 o SENDER_TSPEC and FLOW_SPEC [RFC2205] 597 o SESSION_ATTRIBUTE [RFC3209] 599 o EXPLICIT_ROUTE Object (ERO) [RFC3209] 601 o ROUTE_RECORD Object (RRO) [RFC3209] 603 o FAST_REROUTE Object [RFC4090] 605 o DETOUR Object [RFC4090] 607 o EXCLUDE_ROUTE Object (XRO) [RFC4874] 609 o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873] 611 o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873] 613 o LSP_ATTRIBUTES Object [RFC5420] 615 o LSP_REQUIRED_ATTRIBUTES Object [RFC5420] 617 o PROTECTION Object [RFC3473][RFC4872][RFC4873] 619 o ASSOCIATION Object [RFC4872] 620 o PRIMARY_PATH_ROUTE Object [RFC4872] 622 o ADMIN_STATUS Object [RFC3473] 624 o LABEL_REQUEST Object [RFC3209][RFC3473] 626 For the MPLS TE LSP Objects listed above, the corresponding sub- 627 objects are also applicable to this mechanism. Note that this list 628 is not exhaustive, other MPLS TE LSP objects which reflect specific 629 characteristics of the MPLS TE LSP can also be carried in the LSP 630 state TLV. 632 2.3.2. PCE Objects 634 PCE objects are encoded in the "Value" field of the MPLS TE LSP State 635 TLV and consists of PCE objects defined in [RFC5440]. Rather than 636 replicating all MPLS TE LSP related objects in this document, the 637 semantics and encodings of the MPLS TE LSP objects are re-used. 638 These MPLS TE LSP objects are carried in the LSP State TLV. 640 When carrying PCE objects, the "Protocol-Origin" field is set to 641 "PCE" (suggested value 2, to be assigned by IANA). 643 The following PCE Objects are defined: 645 o METRIC Object [RFC5440] 647 o BANDWIDTH Object [RFC5440] 649 For the MPLS TE LSP Objects listed above, the corresponding sub- 650 objects are also applicable to this mechanism. Note that this list 651 is not exhaustive, other MPLS TE LSP objects which reflect specific 652 characteristics of the MPLS TE LSP can also be carried in the LSP 653 state TLV. 655 2.3.3. SR TE Policy Sub-TLVs 657 Segment Routing Traffic Engineering Policy (SR TE Policy) as 658 described in [I-D.previdi-idr-segment-routing-te-policy]makes use of 659 the Tunnel Encapsulation Attribute defined in 660 [I-D.ietf-idr-tunnel-encaps] and defines following sub-TLVs: 662 o Preference 664 o Binding SID 666 o Weight 667 o Segment List 669 o Segment 671 The equivalent sub-TLVs are defined hereafter and carried in the TE 672 Policy State TLV. When carrying SR TE Policy objects, the "Protocol- 673 Origin" field is set to "BGP SR TE Policy" (suggested value 3, to be 674 assigned by IANA). 676 2.3.3.1. Preference Object 678 The Preference sub-TLV has the following format: 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | Flags | RESERVED | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Preference (4 octets) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 All fields, including type and length, are defined in 689 [I-D.previdi-idr-segment-routing-te-policy]. 691 2.3.3.2. SR TE Binding SID Sub-TLV 693 The Binding SID sub-TLV has the following format: 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | Length | Flags | RESERVED | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Binding SID (variable, optional) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 All fields, including type and length, are defined in 704 [I-D.previdi-idr-segment-routing-te-policy]. 706 [I-D.previdi-idr-segment-routing-te-policy] specifies the Binding SID 707 sub-TLV which carries an indication of which value to allocate as 708 Binding SID to the SR TE Policy. In the context of the BGP-LS 709 extensions defined in this document, the Binding SID sub-TLV to the 710 reciever of the , the Binding SID TLThe Binding SID sub-TLV contains 711 the Binding SID the originator of the BGP-LS update has allocated to 712 the corresponding SR TE Policy. 714 In the context of BGP-LS, the Binding SID sub-TLV defined in this 715 document, contains the effective value of the Binding SID that the 716 router allocated to the SR TE Policy. The router is the SR TE Policy 717 receiver (as described in 718 [I-D.previdi-idr-segment-routing-te-policy]) and it is also the 719 originator of the corresponding BGP-LS update with the extensions 720 defined in this document. 722 2.3.3.3. Weight Sub-TLV 724 The Weight sub-TLV has the following format: 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type | Length | Flags | RESERVED | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Weight | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 All fields, including type and length, are defined in 735 [I-D.previdi-idr-segment-routing-te-policy]. 737 2.3.3.4. Segment List Sub-TLV 739 The Segment List object contains sub-TLVs (which in fact are sub-sub- 740 TLVs) and has following format: 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type | Length | RESERVED | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 // sub-TLVs // 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 o All fields, including type and length, are defined in 751 [I-D.previdi-idr-segment-routing-te-policy]. 753 o Length is the total length (not including the Type and Length 754 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 756 o sub-objects: 758 * An optional single Weight sub-TLV. 760 * One or more Segment sub-TLVs. 762 The Segment List sub-TLV is mandatory. 764 Multiple occurrences of the Segment List sub-TLV MAY appear in the SR 765 TE Policy. 767 2.3.3.5. Segment Sub-TLV 769 The Segment sub-TLV describes a single segment in a segment list 770 (i.e.: a single element of the explicit path). Multiple Segment sub- 771 TLVs constitute an explicit path of the SR TE Policy. 773 [I-D.previdi-idr-segment-routing-te-policy] defines 8 different types 774 of Segment Sub-TLVs: 776 Type 1: SID only, in the form of MPLS Label 777 Type 2: SID only, in the form of IPv6 address 778 Type 3: IPv4 Node Address with optional SID 779 Type 4: IPv6 Node Address with optional SID 780 Type 5: IPv4 Address + index with optional SID 781 Type 6: IPv4 Local and Remote addresses with optional SID 782 Type 7: IPv6 Address + index with optional SID 783 Type 8: IPv6 Local and Remote addresses with optional SID 785 2.3.3.5.1. Type 1: SID only, in the form of MPLS Label 787 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 788 MPLS label. The format is as follows: 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Type | Length | Flags | RESERVED | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Label | TC |S| TTL | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Type, Length and values are defined in 799 [I-D.previdi-idr-segment-routing-te-policy]. 801 2.3.3.5.2. Type 2: SID only, in the form of IPv6 address 803 The Type-2 Segment Sub-TLV encodes a single SID in the form of an 804 IPv6 address. The format is as follows: 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type | Length | Flags | RESERVED | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 // IPv6 SID (16 octets) // 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Type, Length and values are defined in 815 [I-D.previdi-idr-segment-routing-te-policy]. 817 2.3.3.5.3. Type 3: IPv4 Node Address with optional SID 819 The Type-3 Segment Sub-TLV encodes an IPv4 node address and an 820 optional SID in the form of either an MPLS label or an IPv6 address. 821 The format is as follows: 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type | Length | Flags | RESERVED | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | IPv4 Node Address (4 octets) | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 // SID (optional, 4 or 16 octets) // 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Type, Length and values are defined in 834 [I-D.previdi-idr-segment-routing-te-policy]. 836 2.3.3.5.4. Type 4: IPv6 Node Address with optional SID 838 The Type-4 Segment Sub-TLV encodes an IPv6 node address and an 839 optional SID in the form of either an MPLS label or an IPv6 address. 840 The format is as follows: 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Type | Length | Flags | RESERVED | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 // IPv6 Node Address (16 octets) // 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 // SID (optional, 4 or 16 octets) // 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Type, Length and values are defined in 853 [I-D.previdi-idr-segment-routing-te-policy]. 855 2.3.3.5.5. Type 5: IPv4 Address + index with optional SID 857 The Type-5 Segment Sub-TLV encodes an IPv4 node address, an interface 858 index and an optional SID in the form of either an MPLS label or an 859 IPv6 address. The format is as follows: 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Type | Length | Flags | RESERVED | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | IfIndex (4 octets) | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | IPv4 Node Address (4 octets) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 // SID (optional, 4 or 16 octets) // 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Type, Length and values are defined in 874 [I-D.previdi-idr-segment-routing-te-policy]. 876 2.3.3.5.6. Type 6: IPv4 Local and Remote addresses with optional SID 878 The Type-6 Segment Sub-TLV encodes an IPv4 node address, an adjacency 879 local address, an adjacency remote address and an optional SID in the 880 form of either an MPLS label or an IPv6 address. The format is as 881 follows: 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Type | Length | Flags | RESERVED | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Local IPv4 Address (4 octets) | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Remote IPv4 Address (4 octets) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 // SID (4 or 16 octets) // 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 Type, Length and values are defined in 896 [I-D.previdi-idr-segment-routing-te-policy]. 898 2.3.3.5.7. Type 7: IPv6 Address + index with optional SID 900 The Type-7 Segment Sub-TLV encodes an IPv6 node address, an interface 901 index and an optional SID in the form of either an MPLS label or an 902 IPv6 address. The format is as follows: 904 0 1 2 3 905 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 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Type | Length | Flags | RESERVED | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | IfIndex (4 octets) | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 // IPv6 Node Address (16 octets) // 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 // SID (optional, 4 or 16 octets) // 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Type, Length and values are defined in 917 [I-D.previdi-idr-segment-routing-te-policy]. 919 2.3.3.5.8. Type 8: IPv6 Local and Remote addresses with optional SID 921 The Type-8 Segment Sub-TLV encodes an IPv6 node address, an adjacency 922 local address, an adjacency remote address and an optional SID in the 923 form of either an MPLS label or an IPv6 address. The format is as 924 follows: 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Type | Length | Flags | RESERVED | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 // Local IPv6 Address (16 octets) // 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 // Remote IPv6 Address (16 octets) // 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 // SID (4 or 16 octets) // 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Type, Length and values are defined in 939 [I-D.previdi-idr-segment-routing-te-policy]. 941 3. Operational Considerations 943 The Existing BGP operational procedures apply to this document. No 944 new operation procedures are defined in this document. The 945 operational considerations as specified in [RFC7752] apply to this 946 document. 948 In general, it is assumed that the TE Policy head-end nodes are 949 responsible for the distribution of TE Policy state information, 950 while other nodes, e.g. the nodes in the path of a policy, MAY report 951 the TE Policy information (if available) when needed. For example, 952 the border routers in the inter-domain case will also distribute LSP 953 state information since the ingress node may not have the complete 954 information for the end-to-end path. 956 4. IANA Considerations 958 This document requires new IANA assigned codepoints. 960 4.1. BGP-LS NLRI-Types 962 IANA maintains a registry called "Border Gateway Protocol - Link 963 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI- 964 Types". 966 The following codepoints is suggested (to be assigned by IANA): 968 +------+----------------------------+---------------+ 969 | Type | NLRI Type | Reference | 970 +------+----------------------------+---------------+ 971 | 5 | TE Policy NLRI type | this document | 972 +------+----------------------------+---------------+ 974 4.2. BGP-LS Protocol-IDs 976 IANA maintains a registry called "Border Gateway Protocol - Link 977 State (BGP-LS) Parameters" with a sub-registry called "BGP-LS 978 Protocol-IDs". 980 The following Protocol-ID codepoints are suggested (to be assigned by 981 IANA): 983 +-------------+----------------------------------+---------------+ 984 | Protocol-ID | NLRI information source protocol | Reference | 985 +-------------+----------------------------------+---------------+ 986 | 8 | RSVP-TE | this document | 987 | 9 | Segment Routing | this document | 988 +-------------+----------------------------------+---------------+ 990 4.3. BGP-LS Descriptors TLVs 992 IANA maintains a registry called "Border Gateway Protocol - Link 993 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 994 Link Descriptor and Link Attribute TLVs". 996 The following TLV codepoints are suggested (to be assigned by IANA): 998 +----------+--------------------------------------+---------------+ 999 | TLV Code | Description | Value defined | 1000 | Point | | in | 1001 +----------+--------------------------------------+---------------+ 1002 | 1158 | TE Policy State TLV | this document | 1003 | 267 | Tunnel ID TLV | this document | 1004 | 268 | LSP ID TLV | this document | 1005 | 269 | IPv4/6 Tunnel Head-end address TLV | this document | 1006 | 270 | IPv4/6 Tunnel Tail-end address TLV | this document | 1007 | 271 | SR TE Policy Identifier TLV | this document | 1008 +----------+--------------------------------------+---------------+ 1010 4.4. BGP-LS LSP-State TLV Protocol Origin 1012 This document requests IANA to maintain a new sub-registry under 1013 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 1014 registry is called "Protocol Origin" and contains the codepoints 1015 allocated to the "Protocol Origin" field defined in Section 2.3. The 1016 registry contains the following codepoints (suggested values, to be 1017 assigned by IANA): 1019 +----------+------------------+ 1020 | Protocol | Description | 1021 | Origin | | 1022 +----------+------------------+ 1023 | 1 | RSVP-TE | 1024 | 2 | PCE | 1025 | 3 | BGP SR TE Policy | 1026 +----------+------------------+ 1028 5. Security Considerations 1030 Procedures and protocol extensions defined in this document do not 1031 affect the BGP security model. See [RFC6952] for details. 1033 6. Acknowledgements 1035 The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz 1036 Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah, 1037 Dhanendra Jain and Clarence Filsfils for their review and valuable 1038 comments. 1040 7. References 1041 7.1. Normative References 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, 1045 DOI 10.17487/RFC2119, March 1997, 1046 . 1048 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1049 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1050 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1051 September 1997, . 1053 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1054 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1055 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1056 . 1058 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1059 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1060 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1061 DOI 10.17487/RFC3473, January 2003, 1062 . 1064 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1065 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1066 DOI 10.17487/RFC4090, May 2005, 1067 . 1069 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1070 "Multiprotocol Extensions for BGP-4", RFC 4760, 1071 DOI 10.17487/RFC4760, January 2007, 1072 . 1074 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1075 Ed., "RSVP-TE Extensions in Support of End-to-End 1076 Generalized Multi-Protocol Label Switching (GMPLS) 1077 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1078 . 1080 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1081 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1082 May 2007, . 1084 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 1085 Extension to Resource ReserVation Protocol-Traffic 1086 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 1087 April 2007, . 1089 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1090 Ayyangarps, "Encoding of Attributes for MPLS LSP 1091 Establishment Using Resource Reservation Protocol Traffic 1092 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1093 February 2009, . 1095 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1096 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1097 DOI 10.17487/RFC5440, March 2009, 1098 . 1100 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1101 S. Ray, "North-Bound Distribution of Link-State and 1102 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1103 DOI 10.17487/RFC7752, March 2016, 1104 . 1106 7.2. Informative References 1108 [I-D.ietf-idr-tunnel-encaps] 1109 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 1110 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-02 1111 (work in progress), May 2016. 1113 [I-D.ietf-pce-stateful-pce] 1114 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1115 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1116 pce-14 (work in progress), March 2016. 1118 [I-D.previdi-idr-segment-routing-te-policy] 1119 Previdi, S., Filsfils, C., Sreekantiah, A., Sivabalan, S., 1120 Mattes, P., and E. Rosen, "Advertising Segment Routing 1121 Traffic Engineering Policies in BGP", draft-previdi-idr- 1122 segment-routing-te-policy-01 (work in progress), May 2016. 1124 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1125 Element (PCE)-Based Architecture", RFC 4655, 1126 DOI 10.17487/RFC4655, August 2006, 1127 . 1129 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1130 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1131 and Authentication for Routing Protocols (KARP) Design 1132 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1133 . 1135 Authors' Addresses 1137 Stefano Previdi (editor) 1138 Cisco Systems, Inc. 1139 Via Del Serafico, 200 1140 Rome 00142 1141 Italy 1143 Email: sprevidi@cisco.com 1145 Jie Dong (editor) 1146 Huawei Technologies 1147 Huawei Campus, No. 156 Beiqing Rd. 1148 Beijing 100095 1149 China 1151 Email: jie.dong@huawei.com 1153 Mach(Guoyi) Chen 1154 Huawei Technologies 1155 Huawei Campus, No. 156 Beiqing Rd. 1156 Beijing 100095 1157 China 1159 Email: mach.chen@huawei.com 1161 Hannes Gredler 1162 RtBrick Inc. 1164 Email: hannes@rtbrick.com 1166 Jeff Tantsura 1167 Individual 1169 Email: jefftant@gmail.com