idnits 2.17.1 draft-li-idr-mpls-path-programming-04.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 (October 30, 2016) is 2734 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) == Unused Reference: 'RFC3032' is defined on line 555, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.hao-idr-flowspec-redirect-tunnel' == Outdated reference: A later version (-08) exists of draft-ietf-idr-custom-decision-07 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-02 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Zhuang 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 3, 2017 S. Lu 6 Tencent 7 October 30, 2016 9 BGP Extensions for Service-Oriented MPLS Path Programming (MPP) 10 draft-li-idr-mpls-path-programming-04 12 Abstract 14 Service-oriented MPLS programming (SoMPP) is to provide customized 15 service process based on flexible label combinations. BGP will play 16 an important role for MPLS path programming to download programmed 17 MPLS path and map the service path to the transport path. This 18 document defines BGP extensions to support service-oriented MPLS path 19 programming. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Architecture and Usecases of SoMPP . . . . . . . . . . . . . 3 64 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Usecases . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2.1. Deterministic ECMP . . . . . . . . . . . . . . . . . 4 67 3.2.2. Centralized Mapping of Service to Tunnels . . . . . . 5 68 4. Advertising Label Stacks in BGP . . . . . . . . . . . . . . . 5 69 4.1. Download of MPLS Path . . . . . . . . . . . . . . . . . . 7 70 4.2. Mapping Traffic to MPLS Path . . . . . . . . . . . . . . 7 71 5. Download of Mapping of Service Path to Transport Path . . . . 7 72 5.1. Specify Tunnel Type . . . . . . . . . . . . . . . . . . . 7 73 5.2. Specify Specific Tunnel . . . . . . . . . . . . . . . . . 8 74 6. Route Flag Extended Community . . . . . . . . . . . . . . . . 9 75 7. Destination Node Attribute . . . . . . . . . . . . . . . . . 10 76 8. Capability Negotiation . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 12.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The label stack capability of MPLS would have been utilized well to 88 implement flexible path programming to satisfy all kinds of service 89 requirements. But in the distributed environment, the flexible 90 programming capability is difficult to implement and always confined 91 to reachability. As the introducing of central control in the 92 network, the flexible MPLS programming capability becomes possible 93 owing to two factors: 1. It becomes easier to allocate label for 94 more purposes than reachability; 2. It is easy to calculate the MPLS 95 path in a global network view. Moreover, the MPLS path programming 96 capability can be utilized to satisfy more requirements of service 97 bearing in the service layer which is defined as Service-oriented 98 MPLS path programming. BGP will play an important role for MPLS path 99 programming to download programmed MPLS path and map the service path 100 to the transport path. This document defines BGP extensions to 101 support Service-oriented MPLS path programming. 103 2. Terminology 105 BGP: Border Gateway Protocol 107 EVPN: Ethernet VPN 109 L2VPN: Layer 2 VPN 111 L3VPN: Layer 3 VPN 113 MPP: MPLS Path Programming 115 MVPN: Multicast VPN 117 RR: Route Reflector 119 SR-Path: Segment Routing Path 121 NLRI: Network Layer Reachability Information 123 3. Architecture and Usecases of SoMPP 125 3.1. Architecture 127 The architecture of BGP-based MPLS path programming is shown in the 128 Figure 1. Central control plays an important role in MPLS path 129 programming. It can extend the MPLS path programming capability 130 easily. The central controller can calculate path in a global 131 network view and implement the MPLS path programming to satisfy 132 different requirements of services. The result of MPLS path 133 programming can be advertised from the central controller to the 134 client nodes through BGP extensions to the ingress PEs. When client 135 nodes receives the result of MPLS path programming, it will install 136 the MPLS forwarding entry for the specified BGP prefix to implement 137 the service process. 139 +-------------------+ 140 | Central | 141 | Controller | 142 |----------|(Path Calculation |--------| 143 | | /Path Programming)| | 144 | +-------------------+ | 145 | | 146 MPLS Path MPLS Path 147 | | 148 | | 149 | | 150 +--------+ +--------+ +--------+ 151 | CLIENT | | CLIENT | | CLIENT | 152 | | ...... | | ...... | | 153 | (PE) | | (P) | | (PE) | 154 | | | | | | 155 +--------+ +--------+ +--------+ 157 Figure 1 BGP-based MPLS Path Programming 159 3.2. Usecases 161 3.2.1. Deterministic ECMP 163 Entropy Label[RFC6790] is introduced to improve the ECMP capability 164 by encapsulate the entropy label in the MPLS label stack. The 165 existing implementation is always to calculate the entropy label 166 based on the header of packets by specific hash algorithm in the 167 ingress node. That is, the entropy label is determined locally by 168 the ingress node. The method can improve the hash of packets in the 169 network for load-sharing. But since the ingress node lacks the 170 knowledge of the global traffic pattern of the network and calculates 171 the entropy label by itself it may be not able to improve the ECMP 172 capability accurately and in some cases it may deteriorate the 173 imbalance of load-sharing. 175 With the central controlled MPLS path programming, the central 176 controller can collect the global traffic pattern information of the 177 network and based on the information deterministically calculate the 178 entropy label for specific flows to help improve the load-sharing of 179 the network. Then the central controller can download the label 180 stack information with the deterministic entropy label to the ingress 181 PEs for the specific BGP prefix. The ingress node can install the 182 MPLS forwarding entry shown in the following figure to help optimize 183 the ECMP of the flow specified by the BGP prefix, then optimize the 184 ECMP of the whole network. 186 +----------+ +----------+----------+ 187 | BGP | ---> | Entropy |BGP Prefix| ---> Transport 188 | Prefix | | Label | Label | Tunnel 189 +----------+ +----------+----------+ 191 3.2.2. Centralized Mapping of Service to Tunnels 193 In the network there can be multiple tunnels to one specific 194 destination which satisfy different constraints. In the traditional 195 way, the tunnel is set up by the distributed forwarding nodes. As 196 the PCE-initiated LSP setup [I-D.ietf-pce-pce-initiated-lsp] is 197 introduced, the tunnel with different constraints can be set up in 198 the central controlled way. In order to satisfy different service 199 requirements, it is necessary to provide the capability to flexibly 200 map the service to different tunnels which constraints can satisfy 201 the required service requirement. Since the central controller has 202 enough information of the whole network view, it can be an effective 203 way to map the service (such as L3VPN and L2VPN) to the tunnel by the 204 central controller and advertise the mapping information to the 205 ingress PE of the service to guide the mapping in the forwarding 206 node. 208 There can be two types of behaviors to map service to the tunnel: 210 1. Specify the tunnel type: with the method BGP will carry the 211 tunnel type information for the BGP prefix. When the ingress PE 212 receives the information, it will use the tunnel type and the nexthop 213 address (or other specified target IP address) to search the 214 corresponding tunnels to bear the flow specified by the BGP prefix. 215 If there are more than one tunnels, the ingress PE will load share 216 the traffic across all the tunnels. 218 2. Specify the specific tunnel: For MPLS TE/SR-TE tunnel, there can 219 be multiple MPLS TE tunnels from one ingress PE to a specific 220 destination with different constraints. BGP can carry the tunnel 221 identifier information for the BGP prefix from the controller to the 222 ingress node. When the ingress PE receives the information, it will 223 use the tunnel identifier information to search the corresponding 224 tunnels to bear the flow specified by the BGP prefix. If there are 225 multiple tunnel identifiers, the ingress PE will load share the 226 traffic across all the tunnels. 228 4. Advertising Label Stacks in BGP 230 According to the service requirements, the central controller can 231 combine MPLS labels flexibly. Then it can download the service label 232 combination for specific prefix. BGP extensions are necessary to 233 advertise label stacks for the prefix in NLRI field. 235 +---------------------------+ 236 | Length (1 octet) | 237 +---------------------------+ 238 | Label (3 octets) | 239 +---------------------------+ 240 ............................. 241 +---------------------------+ 242 | Prefix (variable) | 243 +---------------------------+ 244 Figure 2: NLRI Definition in RFC3107 246 [RFC3107] defines above NLRI to advertise label binding for specific 247 prefix. The label field can carry one or more labels. Each label is 248 encoded as 3 octets, where the high-order 20 bits contain the label 249 value, and the low order bit contains "Bottom of Stack". But for the 250 other AFI/SAFIs using label binding such as IPv4 Flowspec, IPv6 251 Flowspec, VPNv4, VPNv6, EVPN, MVPN, etc., it dose not support the 252 capability to carry more labels for the specific prefix. Moreover 253 for the AFI/SAFIs which do not support label binding capability 254 originally, but may possibly adopt MPLS path programming now, there 255 is no label field in the NLRI. In order to support flexible MPLS 256 path programming, this document defines and uses a new BGP attribute 257 called the "Extended Label attribute". This is an optional 258 transitive BGP attribute. The attribute type code is (TBA by IANA), 259 the value field of this attribute is defined as follows: 261 +---------------------------+ 262 | Label 1 (3 octets) | 263 +---------------------------+ 264 | Label 2 (3 octets) | 265 +---------------------------+ 266 ............................. 267 +---------------------------+ 268 | Label n (3 octets) | 269 +---------------------------+ 270 Figure 3: Extended Label Attribute 272 The Label field carries one or more labels (that corresponds to the 273 stack of labels [[RFC3032]]). Each label is encoded as 3 octets, 274 where the high-order 20 bits contain the label value, and the low 275 order bit contains "Bottom of Stack" (as defined in [[RFC3032]]). In 276 the last label, the S bit MUST be "1"; in the other labels, the S bit 277 MUST be "0". 279 The "Extended Label attribute" can be used for various BGP address 280 families. Before using this attribute, firstly, it is necessary to 281 negotiate the capability between two nodes to support MPLS path 282 programming for a specific BGP address family. If negotiation fails, 283 a node MUST NOT send this attribute and MUST discard this attribute 284 when it receives. 286 4.1. Download of MPLS Path 288 The Central Controller for MPLS path programming could build a route 289 with Extended Label attribute and send it to the ingress routers. 291 Upon receiving such a route from the Central Controller, the ingress 292 router SHOULD select such a route as the best path. If a packet 293 comes into the ingress router and uses such a path, the ingress 294 router will encapsulate the stack of labels which is derived from the 295 Extended Label Attribute of the route into the packet and forward the 296 packet along the path. 298 4.2. Mapping Traffic to MPLS Path 300 The Extended Label attribute can be used for BGP Flowspec address 301 families. BGP advertises the Flowspec with the Extended Label 302 attribute, so the flow packets can be redirected to the MPLS Path 303 which is derived from the Extended Label Attribute. 305 5. Download of Mapping of Service Path to Transport Path 307 5.1. Specify Tunnel Type 309 [I-D.ietf-idr-tunnel-encaps] proposes the Tunnel Encapsulation 310 Attribute which can be used without BGP Encapsulation SAFI to specify 311 a set of tunnels. It defines a series of Encapsulation Sub-TLVs for 312 particular tunnel types. It also defines the Remote Endpoint 313 Attributes Sub-TLV to specify the remote tunnel endpoint address for 314 each tunnel which can be different the BGP nexthop. The Tunnel 315 Encapsulation Attributes can be reused for the MPLS path programming 316 to specify the tunnel types, the encapsulation and the remote tunnel 317 endpoint address which can determine a set of tunnels which the 318 service can map to. Now the limited MPLS tunnel types are defined 319 for the Tunnel Encapsulation Attributes. In order to support MPLS 320 path programming, the following MPLS tunnel types are to be defined: 322 Value Tunnel Type 323 ------- --------------------------------------------------- 324 TBD LDP LSP 325 TBD RSVP-TE LSP 326 TBD MPLS-based Segment Routing Best-effort Path 327 TBD MPLS-based Segment Routing Traffic Engineering Path 329 5.2. Specify Specific Tunnel 331 Besides specifying the tunnel types to determine the set of tunnels 332 which the service traffic can map to, the specific tunnels can be 333 specified directly by the tunnel identifiers when map the service 334 traffic to the path. BGP extensions is necessary that through the 335 community attribute of BGP the identifier of the transport path can 336 be carried when advertise the specific prefix. 338 In order to support the application, this document defines a new BGP 339 attribute called the "Extended Unicast Tunnel attribute". This is an 340 optional transitive BGP attribute. The attribute type code is (TBA 341 by IANA), the value field of this attribute is defined as follows: 343 +--------------------------------------------------+ 344 | First Tunnel entry (variable) | 345 +--------------------------------------------------+ 346 | Second Tunnel entry (variable) | 347 +--------------------------------------------------+ 348 | ... | 349 +--------------------------------------------------+ 350 | N-th Tunnel entry (variable) | 351 +--------------------------------------------------+ 353 The Tunnel entry is defined as follows: 355 +------------------------------------------------+ 356 | Flags (1 octet) | 357 +------------------------------------------------+ 358 | Tunnel Type (1 octets) | 359 +------------------------------------------------+ 360 | Tunnel Identifier (variable) | 361 +------------------------------------------------+ 362 | Tunnel Specific Attributes (Variable)(Optional)| 363 +------------------------------------------------+ 365 The Flags is reserved and must be set as zero. The Tunnel Type 366 identifies the type of the tunneling technology used for the unicast 367 service path. The tunnel type determines the syntax and semantics of 368 the Tunnel Identifier field. This document defines following Tunnel 369 Types: 371 + 0 - No tunnel information present 373 + 1 - RSVP-TE LSP 374 + 2 - MPLS-based Segment Routing Traffic Engineering Path 376 Tunnel Specific Attributes contains the attributes of the tunnel. 377 The field is optional. The value depends on the tunnel type. It 378 will be defined in the future versions. 380 When the Tunnel Type is set to "No tunnel information present", the 381 Tunnel attribute carries no tunnel information (no Tunnel 382 Identifier). when the type is used, the tunnel used for the service 383 path is determined by the ingress router. 385 When the Tunnel Type is set to RSVP - Traffic Engineering (RSVP-TE) 386 Label Switched Path (LSP), the Tunnel Identifier is as specified in 388 [RFC3209] If C-Type = 7, Tunnel Sender Address and Tunnel End-point 389 Address are IPv4 address in 4 octets. If C-Type = 8, Tunnel Sender 390 Address and Tunnel End-point Address are IPv6 address in 16 octets. 391 The other fields in the RSVP-TE LSP Identifier are the same as 392 specified in [RFC3209]. 394 When the Tunnel Type is set to MPLS-based Segment Routing Traffic 395 Engineering Path, the Tunnel Identifier is . If C-Type = 7, Tunnel 397 Sender Address and Tunnel End-point Address are IPv4 address in 4 398 octets. If C-Type = 8, Tunnel Sender Address and Tunnel End-point 399 Address are IPv6 address in 16 octets. The tunnel identifier is 400 similar as that of RSVP-TE LSP. 402 BGP can carry multiple Tunnel entries in one Extended Unicast Tunnel 403 attribute for specific prefix. If there are multiple tunnel entries, 404 the ingress PE can load share the traffic across all the specified 405 tunnels for the service traffic determined by the specific BGP 406 prefix, or selects the primary / Backup tunnels from the multiple 407 tunnel entries. 409 The "Redirect-to-Tunnel Action" for BGP Flowspec has been described 410 in[I-D.hao-idr-flowspec-redirect-tunnel]. This document reuses the 411 tunnel identifier and defines it in the Extended Unicast Tunnel 412 attribute which can be used for "Redirect-to-Tunnel Action". 414 6. Route Flag Extended Community 416 In order to make the MPLS path programming to take effect, the route 417 advertised by the central controller after the MPLS Path Programming 418 should be selected by the ingress PE over other routes for the same 419 BGP prefix. There are two options of BGP extensions for the purpose: 421 Option 1: A new BGP Extended Community called as the "Route Flag 422 Extended Community" can be introduced. The Type value is to be 423 assigned by IANA. 425 The Route Flag Extended Community is used to carry the flag appointed 426 by the BGP central controller. 428 The format of this extended community is defined as follows: 430 0 1 2 3 4 5 6 7 431 +-----+-----+-----+-----+-----+-----+-----+-----+ 432 | Type | Reserved |Flag | 433 +-----+-----+-----+-----+-----+-----+-----+-----+ 435 Flag = 0, Treat as normal route 436 Flag = 1, Treat as best route 438 When a router receives a BGP route with a Route Flag Extended 439 Community and the Flag set to "1", it SHOULD use the route as the 440 best route when select the route from multiple routes for a specific 441 prefix. 443 Option 2: [I-D.ietf-idr-custom-decision] defines a new Extended 444 Community, called the Cost Community, which can be used in tie 445 breaking during the best path selection process. The Cost Community 446 can be reused by the MPLS path programming to set the "Point of 447 Insertion" as 128 to make the route advertised by the central 448 controller to be chosen. 450 7. Destination Node Attribute 452 This document defines and uses a new BGP attribute called as the 453 "Destination Node attribute" which Type value is to be assigned by 454 IANA. The Destination Node attribute is an optional non-transitive 455 attribute that can be applied to any address family. 457 The Destination Node attribute is used to carry a list of node 458 addresses, which are intended to be used to determine the nodes where 459 the route with such attribute SHOULD be considered. If a node 460 receives a BGP route with a Destination Node attribute, it MUST check 461 the node address list. If one address of the list belongs to this 462 node, the route MUST be used in this node. Otherwise the route MUST 463 be ignored silently. 465 The format of this attribute is defined as follows: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | AFI | SAFI | Reserved | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 ~ ~ 473 ~ Destination Node Address List ~ 474 ~ ~ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 AFI: Address Family Identifier (16 bits). 479 SAFI: Subsequent Address Family Identifier (8 bits). 481 Reserved: One octet reserved for special flags 483 Destination Node Address List: The list of IPv4 (AFI=1) or IPv6 484 (AFI=2) address. 486 8. Capability Negotiation 488 It is necessary to negotiate the capability to support MPLS path 489 programming. The MPLS-Path-Programming Capability is a new BGP 490 capability [RFC5492]. The Capability Code for this capability is to 491 be specified by the IANA. The Capability Length field of this 492 capability is variable. The Capability Value field consists of one 493 or more of the following tuples: 495 +--------------------------------------------------+ 496 | Address Family Identifier (2 octets) | 497 +--------------------------------------------------+ 498 | Subsequent Address Family Identifier (1 octet) | 499 +--------------------------------------------------+ 500 | Send/Receive (1 octet) | 501 +--------------------------------------------------+ 503 The meaning and use of the fields are as follows: 505 Address Family Identifier (AFI): This field is the same as the one 506 used in [RFC4760]. 508 Subsequent Address Family Identifier (SAFI): This field is the same 509 as the one used in [RFC4760]. 511 Send/Receive: This field indicates whether the sender is (a) willing 512 to receive programming MPLS paths from its peer (value 1), (b) would 513 like to send programming MPLS paths to its peer (value 2), or (c) 514 both (value 3) for the . 516 9. Acknowledgments 518 The authors of this document would like to thank Lucy Yong, Susan 519 Hares, Eric Wu, Weiguo Hao, Pingan Li, Zhengqiang Li and Jie Dong for 520 their reviews and comments of this document. 522 10. IANA Considerations 524 TBD. 526 11. Security Considerations 528 The security considerations of [RFC4271] and [RFC5575] are 529 applicable. 531 12. References 533 12.1. Normative References 535 [I-D.hao-idr-flowspec-redirect-tunnel] 536 Weiguo, H., Li, Z., and L. Yong, "BGP Flow-Spec Redirect 537 to Tunnel Action", draft-hao-idr-flowspec-redirect- 538 tunnel-01 (work in progress), March 2016. 540 [I-D.ietf-idr-custom-decision] 541 Retana, A. and R. White, "BGP Custom Decision Process", 542 draft-ietf-idr-custom-decision-07 (work in progress), 543 November 2015. 545 [I-D.ietf-idr-tunnel-encaps] 546 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 547 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-02 548 (work in progress), May 2016. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 556 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 557 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 558 . 560 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 561 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 562 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 563 . 565 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 566 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 567 DOI 10.17487/RFC4271, January 2006, 568 . 570 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 571 "Multiprotocol Extensions for BGP-4", RFC 4760, 572 DOI 10.17487/RFC4760, January 2007, 573 . 575 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 576 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 577 2009, . 579 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 580 and D. McPherson, "Dissemination of Flow Specification 581 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 582 . 584 12.2. Informative References 586 [I-D.ietf-pce-pce-initiated-lsp] 587 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 588 Extensions for PCE-initiated LSP Setup in a Stateful PCE 589 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 590 progress), July 2016. 592 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 593 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 594 . 596 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 597 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 598 RFC 6790, DOI 10.17487/RFC6790, November 2012, 599 . 601 Authors' Addresses 602 Zhenbin Li 603 Huawei Technologies 604 Huawei Bld., No.156 Beiqing Rd. 605 Beijing 100095 606 China 608 Email: lizhenbin@huawei.com 610 Shunwan Zhuang 611 Huawei Technologies 612 Huawei Bld., No.156 Beiqing Rd. 613 Beijing 100095 614 China 616 Email: zhuangshunwan@huawei.com 618 Sujian Lu 619 Tencent 620 Tengyun Building,Tower A ,No. 397 Tianlin Road 621 Shanghai, Xuhui District 200233 622 China 624 Email: jasonlu@tencent.com