idnits 2.17.1 draft-sivabalan-pce-binding-label-sid-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 (March 5, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-27) exists of draft-ietf-idr-bgp-prefix-sid-17 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Tantsura 5 Expires: September 6, 2018 Nuage Networks 6 C. Filsfils 7 S. Previdi 8 Cisco Systems, Inc. 9 J. Hardwick 10 Metaswitch Networks 11 D. Dhody 12 Huawei Technologies 13 March 5, 2018 15 Carrying Binding Label/Segment-ID in PCE-based Networks. 16 draft-sivabalan-pce-binding-label-sid-04 18 Abstract 20 It is possible to associate a binding label to RSVP-TE signaled 21 Traffic Engineering Label Switching Path or binding Segment-ID (SID) 22 to Segment Routed Traffic Engineering path. Such a binding label/SID 23 can be used by an upstream node for steering traffic into the 24 appropriate TE path to enforce TE policies. This document proposes 25 an approach for reporting binding label/SID to Path Computation 26 Element (PCE) for supporting PCE-based Traffic Engineering policies. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 6, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . . . . 7 74 6.2. PCEP Error Type and Value . . . . . . . . . . . . . . . . 7 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 A PCE can compute Traffic Engineering paths (TE paths) through a 82 network that are subject to various constraints. Currently, TE paths 83 are either set up using the RSVP-TE signaling protocol or Segment 84 Routed (SR). We refer to such paths as RSVP-TE paths and SR-TE paths 85 respectively in this document. 87 Similar to assigning label to a Forwarding Equivalence Class (FEC) 88 via Label Distribution Protocol (LDP), a binding label can be 89 assigned to a RSVP-TE LSP. If the topmost label of an incoming 90 packet is the binding label, the packet is steered onto the RSVP-TE 91 LSP. As such, any upstream node can use binding labels to steer the 92 packets that it originates to appropriate TE LSPs to enforce TE 93 policy. Similarly, a binding SID, see 94 [I-D.ietf-isis-segment-routing-extensions], 95 [I-D.ietf-idr-segment-routing-te-policy] and 97 [I-D.ietf-spring-segment-routing] can be used to enforce TE policy 98 with SR-TE path. Note that if an SR-TE path is represented as a 99 forwarding-adjacency, then the corresponding adjacency SID can be 100 used as the binding SID. In such case, the path is advertised using 101 the routing protocols as described in [RFC5440]. The binding SID 102 provides an alternate mechanism without additional overhead on 103 routing protocols. 105 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 106 communication between a Path Computation Client (PCC) and a PCE or 107 between a pair of PCEs.[I-D.ietf-pce-stateful-pce] specifies 108 extension to PCEP that allows a PCC to delegate its LSPs to a PCE. 109 The PCE can then update the state of LSPs delegated to it. 110 [I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE 111 to dynamically instantiate an LSP on a PCC by sending the path and 112 characteristics of the LSP. The PCEP extension to setup and maintain 113 SR-TE paths is specified in [I-D.ietf-pce-segment-routing]. 115 Binding label/SID has local significance to the ingress node of the 116 corresponding TE path. When a stateful PCE is deployed for setting 117 up TE paths, it may be desirable to report the binding label or SID 118 to the PCE for the purpose of enforcing end-to-end TE policy. A 119 sample Data Center (DC) use-case is illustrated in the following 120 diagram. In the MPLS DC network, an SR LSP (without traffic 121 engineering) is established using a prefix SID advertised by BGP (see 122 [I-D.ietf-idr-bgp-prefix-sid]). In IP/MPLS WAN, an SR-TE LSP is 123 setup using the PCE. The list of SIDs of the SR-TE LSP is {A, B, C, 124 D}. The gateway node 1 (which is the PCC) allocates a binding SID X 125 and reports it to the PCE. In order for the access node to steer the 126 traffic over the SR-TE LSP, the PCE passes the SID stack {Y, X} where 127 Y is the prefix SID of the gateway node-1 to the access node. In the 128 absence of the binding SID X, the PCE should pass the SID stack {Y, 129 A, B, C, D} to the access node. This example also illustrates the 130 additional benefit of using the binding SID to reduce the number of 131 SIDs imposed on the access nodes with a limited forwarding capacity. 133 SID stack 134 {Y, X} +-----+ 135 _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | 136 | +-----+ 137 | ^ 138 | | Binding 139 | .-----. | SID (X) .-----. 140 | ( ) | ( ) 141 V .--( )--. | .--( )--. 142 +------+ ( ) +-------+ ( ) +-------+ 143 |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| 144 | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | 145 +------+ ( SR path ) +-------+ ( SR-TE path ) +-------+ 146 '--( )--' Prefix '--( )--' 147 ( ) SID of ( ) 148 '-----' Node-1 '-----' 149 is Y SIDs for SR-TE LSP: 150 {A, B, C, D} 152 Figure 1: A sample Use-case of Binding SID 154 It may be possible for a PCE to request a PCC to allocate a specific 155 binding label/SID by sending an update message. If the PCC can 156 successfully allocate the specified binding value, it reports the 157 binding value to the PCE. Otherwise, the PCC sends an error message 158 to the PCE indicating the cause of the failure. 160 In this document, we introduce a new OPTIONAL TLV that a PCC can use 161 in order to report the binding label/SID associated with a TE LSP, or 162 a PCE to request a PCC to allocate a binding label/SID. This TLV is 163 intended for TE LSPs established using RSVP-TE, SR, or any other 164 future method. Also, in the case of SR-TE LSPs, the TLV can carry an 165 MPLS label (for SR-TE path with MPLS data-plane) or a binding SID 166 (e.g., IPv6 address for SR-TE paths with IPv6 data-plane). However, 167 use of this TLV for carrying non-MPLS binding SID will be described 168 in separate document(s). Binding value means either MPLS label or 169 SID throughout this document. 171 2. Terminology 173 The following terminologies are used in this document: 175 LER: Label Edge Router. 177 LSP: Label Switched Path. 179 LSR: Label Switching Router. 181 PCC: Path Computation Client. 183 PCE: Path Computation Element 185 PCEP: Path Computation Element Protocol. 187 SID: Segment Identifier. 189 SR: Segment Routing. 191 TLV: Type, Length, and Value. 193 3. Path Binding TLV 195 The new optional TLV is called "TE-PATH-BINDING TLV" whose format is 196 shown in the diagram below is defined to carry binding label or SID 197 for a TE path. This TLV is associated with the LSP object specified 198 in ([I-D.ietf-pce-stateful-pce]). The type of this TLV is to be 199 allocated by IANA. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Binding Type (BT) | Binding Value | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ~ Binding Value (continued) (variable length) ~ 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 2: TE-PATH-BINDING TLV 213 TE-PATH-BINDING TLV is a generic TLV such that it is able to carry 214 MPLS label binding as well as other types of future bindings (e.g., 215 IPv6 SR path). It is formatted according to the rules specified in 216 [RFC5440]. The two octet Binding Type (BT) field identifies the type 217 of binding included in the TLV. This document specifies the 218 following BT values: 220 o BT = 0: The binding value is an MPLS label carried in the format 221 specified in [RFC5462] where only the label value is valid, and 222 other fields (TC, S, and TTL)fields MUST be considered invalid. 223 The Length MUST be set to 6. 225 o BT = 1: Similar to the case where BT is 0 except that all the 226 fields on the MPLS label entry are set on transmission. However, 227 the receiver MAY choose to override TC, S, and TTL values 228 according its local policy. 230 4. Operation 232 The binding value is allocated by PCC and reported to PCE via PCRpt 233 message. If a PCE does not recognize the TE-PATH-BINDING TLV, it 234 MUST ignore the TLV in accordance with ([RFC5440]). If a PCE 235 recognizes the TLV but does not support the TLV, it MUST send PCErr 236 with Error-Type = 2 (Capability not supported). 238 If a TE-PATH-BINDING TLV is absent in PCRpt message, PCE MUST assume 239 that the corresponding LSP does not have any binding. If there are 240 more than one TE-PATH-BINDING TLVs, only the first TLV MUST be 241 processed and the rest MUST be silently ignored. If PCE recognizes 242 an invalid binding value (e.g., label value from the reserved label 243 space when MPLS label binding is used), it MUST send the PCErr 244 message with Error-Type = 10 ("Reception of an invalid object") and 245 Error Value = TBD ("Bad label value") as specified in 246 [I-D.ietf-pce-segment-routing]. 248 If a PCE requires a PCC to allocate a specific binding value, it may 249 do so by sending a PCUpd message containing a TE-PATH-BINDING TLV. 250 If the value can be successfully allocated, the PCC reports the 251 binding value to the PCE. If the PCC considers the binding value 252 specified by the PCE invalid, it MUST send a PCErr message with 253 Error-Type = TBD ("Binding SID failure") and Error Value = TBD 254 ("Invalid SID"). If the binding value is valid, but the PCC is 255 unable to allocate the binding value, it MUST send a PCErr message 256 with Error-Type = TBD ("Binding label/SID failure") and Error Value = 257 TBD ("Unable to allocate the specified label/SID"). 259 If a PCC receives TE-PATH-BINDING TLV in any message other than 260 PCUpd, it MUST close the corresponding PCEP session with the reason 261 "Reception of a malformed PCEP message" according ([RFC5440]). 262 Similarly, if a PCE receives a TE-PATH-BINDING TLV in any message 263 other than a PCRpt or if the TE-PATH-BINDING TLV is associated with 264 any object other than LSP object, the PCE MUST close the 265 corresponding PCEP session with the reason "Reception of a malformed 266 PCEP message" according ([RFC5440]). 268 If a PCC wishes to withdraw or modify a previously reported binding 269 value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV 270 or with the TE-PATH-BINDING TLV containing the new binding value 271 respectively. 273 If a PCE wishes to modify a previously requested binding value, it 274 MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new 275 binding value. Absense of TE-PATH-BINDING TLV in PCUpd message means 276 that the PCE does not specify a binding value in which case the 277 binding value allocation is governed by the PCC's local policy. 279 If a PCC receives a valid binding value from a PCE which is different 280 than the current binding value, it MUST try to allocate the new 281 value. If the new binding value is successfully allocated, the PCC 282 MUST report the new value to the PCE. Otherwise, it MUST send a 283 PCErr message with Error-Type = TBD ("Binding label/SID failure") and 284 Error Value = TBD ("Unable to allocate the specified label/SID"). 286 In some cases, a stateful PCE can request the PCC to allocate a 287 binding value. It may do so by sending a PCUpd message containing an 288 empty TE-PATH-BINDING TLV, i.e., no binding value is specified 289 (making the length of the TLV as 2). A PCE can also make the request 290 PCC to allocate a binding at the time of initiatiation by sending a 291 PCInitiate message with an empty TE-PATH-BINDING TLV. 293 5. Security Considerations 295 The security considerations described in ([RFC5440]) and ([RFC8281]) 296 are applicable to this specification. No additional security measure 297 is required. 299 6. IANA Considerations 301 6.1. TE-PATH-BINDING TLV 303 IANA is requested to allocate a new TLV type (recommended value is 304 31)for TE-PATH-BINDING TLV specified in this document. 306 This document requests that a registry is created to manage the value 307 of the Binding Type field in the TE-PATH-BINDING TLV. 309 Value Description Reference 311 0 MPLS Label This document 313 6.2. PCEP Error Type and Value 315 IANA is requested to allocate code-points in the PCEP-ERROR Object 316 Error Types and Values registry for the following new error-values: 318 Error-Type Meaning 319 ---------- ------- 320 TBD (recommended 22) Binding SID failure: 322 Error-value = TBD (recommended 1): Invalid SID 323 Error-value = TBD (recommended 2): Unable to allocate 324 binding SID 326 7. Acknowledgements 328 We like to thank Milos Fabian for his valuable comments. 330 8. Normative References 332 [I-D.ietf-idr-bgp-prefix-sid] 333 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 334 and H. Gredler, "Segment Routing Prefix SID extensions for 335 BGP", draft-ietf-idr-bgp-prefix-sid-17 (work in progress), 336 February 2018. 338 [I-D.ietf-idr-segment-routing-te-policy] 339 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 340 E., and S. Lin, "Advertising Segment Routing Policies in 341 BGP", draft-ietf-idr-segment-routing-te-policy-02 (work in 342 progress), March 2018. 344 [I-D.ietf-isis-segment-routing-extensions] 345 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 346 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 347 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 348 segment-routing-extensions-15 (work in progress), December 349 2017. 351 [I-D.ietf-pce-pce-initiated-lsp] 352 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 353 Extensions for PCE-initiated LSP Setup in a Stateful PCE 354 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 355 progress), October 2017. 357 [I-D.ietf-pce-segment-routing] 358 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 359 and J. Hardwick, "PCEP Extensions for Segment Routing", 360 draft-ietf-pce-segment-routing-11 (work in progress), 361 November 2017. 363 [I-D.ietf-pce-stateful-pce] 364 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 365 Extensions for Stateful PCE", draft-ietf-pce-stateful- 366 pce-21 (work in progress), June 2017. 368 [I-D.ietf-spring-segment-routing] 369 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 370 Litkowski, S., and R. Shakir, "Segment Routing 371 Architecture", draft-ietf-spring-segment-routing-15 (work 372 in progress), January 2018. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 380 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 381 DOI 10.17487/RFC5440, March 2009, 382 . 384 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 385 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 386 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 387 2009, . 389 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 390 Computation Element Communication Protocol (PCEP) 391 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 392 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 393 . 395 Authors' Addresses 397 Siva Sivabalan 398 Cisco Systems, Inc. 399 2000 Innovation Drive 400 Kanata, Ontario K2K 3E8 401 Canada 403 Email: msiva@cisco.com 405 Jeff Tantsura 406 Nuage Networks 407 755 Ravendale Drive 408 Mountain View, CA 94043 409 USA 411 Email: jefftant.ietf@gmail.com 412 Clarence Filsfils 413 Cisco Systems, Inc. 414 Pegasus Parc 415 De kleetlaan 6a, DIEGEM BRABANT 1831 416 BELGIUM 418 Email: cfilsfil@cisco.com 420 Stefano Previdi 421 Cisco Systems, Inc. 423 Email: stefano@previdi.net 425 Jonathan Hardwick 426 Metaswitch Networks 427 100 Church Street 428 Enfield, Middlesex 429 UK 431 Email: Jonathan.Hardwick@metaswitch.com 433 Dhruv Dhody 434 Huawei Technologies 435 Divyashree Techno Park, Whitefield 436 Bangalore, Karnataka 560066 437 India 439 Email: dhruv.ietf@gmail.com