idnits 2.17.1 draft-sivabalan-pce-binding-label-sid-03.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 3, 2017) is 2486 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: 'RFC4206' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-17 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 Summary: 0 errors (**), 0 flaws (~~), 6 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 C. Filsfils 4 Intended status: Standards Track S. Previdi 5 Expires: January 4, 2018 Cisco Systems, Inc. 6 J. Tantsura 7 Individual 8 J. Hardwick 9 Metaswitch Networks 10 D. Dhody 11 Huawei Technologies 12 July 3, 2017 14 Carrying Binding Label/Segment-ID in PCE-based Networks. 15 draft-sivabalan-pce-binding-label-sid-03.txt 17 Abstract 19 It is possible to associate a binding label to RSVP-TE signaled 20 Traffic Engineering Label Switching Path or binding Segment-ID (SID) 21 to Segment Routed Traffic Engineering path. Such a binding label/SID 22 can be used by an upstream node for steering traffic into the 23 appropriate TE path to enforce TE policies. This document proposes 24 an approach for reporting binding label/SID to Path Computation 25 Element (PCE) for supporting PCE-based Traffic Engineering policies. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 4, 2018. 50 Copyright Notice 52 Copyright (c) 2017 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 (http://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] and 95 [I-D.ietf-ospf-segment-routing-extensions]) can be used to enforce TE 96 policy with SR-TE path. Note that if an SR-TE path is represented as 97 a forwarding-adjacency, then the corresponding adjacency SID can be 98 used as the binding SID. In such case, the path is advertised using 99 the routing protocols as described in [RFC5440]. The binding SID 100 provides an alternate mechanism without additional overhead on 101 routing protocols. 103 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 104 communication between a Path Computation Client (PCC) and a PCE or 105 between a pair of PCEs.[I-D.ietf-pce-stateful-pce] specifies 106 extension to PCEP that allows a PCC to delegate its LSPs to a PCE. 107 The PCE can then update the state of LSPs delegated to it. 108 [I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE 109 to dynamically instantiate an LSP on a PCC by sending the path and 110 characteristics of the LSP. The PCEP extension to setup and maintain 111 SR-TE paths is specified in [I-D.ietf-pce-segment-routing]. 113 Binding label/SID has local significance to the ingress node of the 114 corresponding TE path. When a stateful PCE is deployed for setting 115 up TE paths, it may be desirable to report the binding label or SID 116 to the PCE for the purpose of enforcing end-to-end TE policy. A 117 sample Data Center (DC) use-case is illustrated in the following 118 diagram. In the MPLS DC network, an SR LSP (without traffic 119 engineering) is established using a prefix SID advertised by BGP (see 120 [I-D.keyupate-idr-bgp-prefix-sid]). In IP/MPLS WAN, an SR-TE LSP is 121 setup using the PCE. The list of SIDs of the SR-TE LSP is {A, B, C, 122 D}. The gateway node 1 (which is the PCC) allocates a binding SID X 123 and reports it to the PCE. In order for the access node to steer the 124 traffic over the SR-TE LSP, the PCE passes the SID stack {Y, X} where 125 Y is the prefix SID of the gateway node-1 to the access node. In the 126 absence of the binding SID X, the PCE should pass the SID stack {Y, 127 A, B, C, D} to the access node. This example also illustrates the 128 additional benefit of using the binding SID to reduce the number of 129 SIDs imposed on the access nodes with a limited forwarding capacity. 131 SID stack 132 {Y, X} +-----+ 133 _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | 134 | +-----+ 135 | ^ 136 | | Binding 137 | .-----. | SID (X) .-----. 138 | ( ) | ( ) 139 V .--( )--. | .--( )--. 140 +------+ ( ) +-------+ ( ) +-------+ 141 |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| 142 | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | 143 +------+ ( SR path ) +-------+ ( SR-TE path ) +-------+ 144 '--( )--' Prefix '--( )--' 145 ( ) SID of ( ) 146 '-----' Node-1 '-----' 147 is Y SIDs for SR-TE LSP: 148 {A, B, C, D} 150 Figure 1: A sample Use-case of Binding SID 152 It may be possible for a PCE to request a PCC to allocate a specific 153 binding label/SID by sending an update message. If the PCC can 154 successfully allocate the specified binding value, it reports the 155 binding value to the PCE. Otherwise, the PCC sends an error message 156 to the PCE indicating the cause of the failure. 158 In this document, we introduce a new OPTIONAL TLV that a PCC can use 159 in order to report the binding label/SID associated with a TE LSP, or 160 a PCE to request a PCC to allocate a binding label/SID. This TLV is 161 intended for TE LSPs established using RSVP-TE, SR, or any other 162 future method. Also, in the case of SR-TE LSPs, the TLV can carry an 163 MPLS label (for SR-TE path with MPLS data-plane) or a binding SID 164 (e.g., IPv6 address for SR-TE paths with IPv6 data-plane). However, 165 use of this TLV for carrying non-MPLS binding SID will be described 166 in separate document(s). Binding value means either MPLS label or 167 SID throughout this document. 169 2. Terminology 171 The following terminologies are used in this document: 173 LER: Label Edge Router. 175 LSP: Label Switched Path. 177 LSR: Label Switching Router. 179 PCC: Path Computation Client. 181 PCE: Path Computation Element 183 PCEP: Path Computation Element Protocol. 185 SID: Segment Identifier. 187 SR: Segment Routing. 189 TLV: Type, Length, and Value. 191 3. Path Binding TLV 193 The new optional TLV is called "TE-PATH-BINDING TLV" whose format is 194 shown in the diagram below is defined to carry binding label or SID 195 for a TE path. This TLV is associated with the LSP object specified 196 in ([I-D.ietf-pce-stateful-pce]). The type of this TLV is to be 197 allocated by IANA. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Binding Type (BT) | Binding Value | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 ~ Binding Value (continued) (variable length) ~ 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: TE-PATH-BINDING TLV 211 TE-PATH-BINDING TLV is a generic TLV such that it is able to carry 212 MPLS label binding as well as other types of future bindings (e.g., 213 IPv6 SR path). It is formatted according to the rules specified in 214 [RFC5440]. The two octet Binding Type (BT) field identifies the type 215 of binding included in the TLV. This document specifies the 216 following BT values: 218 o BT = 0: The binding value is an MPLS label carried in the format 219 specified in [RFC5462] where only the label value is valid, and 220 other fields (TC, S, and TTL)fields MUST be considered invalid. 221 The Length MUST be set to 6. 223 o BT = 1: Similar to the case where BT is 0 except that all the 224 fields on the MPLS label entry are set on transmission. However, 225 the receiver MAY choose to override TC, S, and TTL values 226 according its local policy. 228 4. Operation 230 The binding value is allocated by PCC and reported to PCE via PCRpt 231 message. If a PCE does not recognize the TE-PATH-BINDING TLV, it 232 MUST ignore the TLV in accordance with ([RFC5440]). If a PCE 233 recognizes the TLV but does not support the TLV, it MUST send PCErr 234 with Error-Type = 2 (Capability not supported). 236 If a TE-PATH-BINDING TLV is absent in PCRpt message, PCE MUST assume 237 that the corresponding LSP does not have any binding. If there are 238 more than one TE-PATH-BINDING TLVs, only the first TLV MUST be 239 processed and the rest MUST be silently ignored. If PCE recognizes 240 an invalid binding value (e.g., label value from the reserved label 241 space when MPLS label binding is used), it MUST send the PCErr 242 message with Error-Type = 10 ("Reception of an invalid object") and 243 Error Value = TBD ("Bad label value") as specified in 244 [I-D.ietf-pce-segment-routing]. 246 If a PCE requires a PCC to allocate a specific binding value, it may 247 do so by sending a PCUpd message containing a TE-PATH-BINDING TLV. 248 If the value can be successfully allocated, the PCC reports the 249 binding value to the PCE. If the PCC considers the binding value 250 specified by the PCE invalid, it MUST send a PCErr message with 251 Error-Type = TBD ("Binding SID failure") and Error Value = TBD 252 ("Invalid SID"). If the binding value is valid, but the PCC is 253 unable to allocate the binding value, it MUST send a PCErr message 254 with Error-Type = TBD ("Binding label/SID failure") and Error Value = 255 TBD ("Unable to allocate the specified label/SID"). 257 If a PCC receives TE-PATH-BINDING TLV in any message other than 258 PCUpd, it MUST close the corresponding PCEP session with the reason 259 "Reception of a malformed PCEP message" according ([RFC5440]). 260 Similarly, if a PCE receives a TE-PATH-BINDING TLV in any message 261 other than a PCRpt or if the TE-PATH-BINDING TLV is associated with 262 any object other than LSP object, the PCE MUST close the 263 corresponding PCEP session with the reason "Reception of a malformed 264 PCEP message" according ([RFC5440]). 266 If a PCC wishes to withdraw or modify a previously reported binding 267 value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV 268 or with the TE-PATH-BINDING TLV containing the new binding value 269 respectively. 271 If a PCE wishes to modify a previously requested binding value, it 272 MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new 273 binding value. Absense of TE-PATH-BINDING TLV in PCUpd message means 274 that the PCE does not specify a binding value in which case the 275 binding value allocation is governed by the PCC's local policy. 277 If a PCC receives a valid binding value from a PCE which is different 278 than the current binding value, it MUST try to allocate the new 279 value. If the new binding value is successfully allocated, the PCC 280 MUST report the new value to the PCE. Otherwise, it MUST send a 281 PCErr message with Error-Type = TBD ("Binding label/SID failure") and 282 Error Value = TBD ("Unable to allocate the specified label/SID"). 284 In some cases, a stateful PCE can request the PCC to allocate a 285 binding value. It may do so by sending a PCUpd message containing an 286 empty TE-PATH-BINDING TLV, i.e., no binding value is specified 287 (making the length of the TLV as 2). A PCE can also make the request 288 PCC to allocate a binding at the time of initiatiation by sending a 289 PCInitiate message with an empty TE-PATH-BINDING TLV. 291 5. Security Considerations 293 No additional security measure is required. 295 6. IANA Considerations 297 6.1. TE-PATH-BINDING TLV 299 IANA is requested to allocate a new TLV type (recommended value is 300 31)for TE-PATH-BINDING TLV specified in this document. 302 This document requests that a registry is created to manage the value 303 of the Binding Type field in the TE-PATH-BINDING TLV. 305 Value Description Reference 307 0 MPLS Label This document 309 6.2. PCEP Error Type and Value 311 IANA is requested to allocate code-points in the PCEP-ERROR Object 312 Error Types and Values registry for the following new error-values: 314 Error-Type Meaning 315 ---------- ------- 316 TBD (recommended 22) Binding SID failure: 318 Error-value = TBD (recommended 1): Invalid SID 319 Error-value = TBD (recommended 2): Unable to allocate 320 binding SID 322 7. Acknowledgements 324 We like to thank Milos Fabian for his valuable comments. 326 8. Normative References 328 [I-D.ietf-isis-segment-routing-extensions] 329 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 330 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 331 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 332 segment-routing-extensions-13 (work in progress), June 333 2017. 335 [I-D.ietf-ospf-segment-routing-extensions] 336 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 337 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 338 Extensions for Segment Routing", draft-ietf-ospf-segment- 339 routing-extensions-17 (work in progress), June 2017. 341 [I-D.ietf-pce-pce-initiated-lsp] 342 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 343 Extensions for PCE-initiated LSP Setup in a Stateful PCE 344 Model", draft-ietf-pce-pce-initiated-lsp-10 (work in 345 progress), June 2017. 347 [I-D.ietf-pce-segment-routing] 348 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 349 and J. Hardwick, "PCEP Extensions for Segment Routing", 350 draft-ietf-pce-segment-routing-09 (work in progress), 351 April 2017. 353 [I-D.ietf-pce-stateful-pce] 354 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 355 Extensions for Stateful PCE", draft-ietf-pce-stateful- 356 pce-21 (work in progress), June 2017. 358 [I-D.keyupate-idr-bgp-prefix-sid] 359 Patel, K., Previdi, S., Filsfils, C., Sreekantiah, A., 360 Ray, S., and H. Gredler, "Segment Routing Prefix SID 361 extensions for BGP", draft-keyupate-idr-bgp-prefix-sid-05 362 (work in progress), July 2015. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 370 Hierarchy with Generalized Multi-Protocol Label Switching 371 (GMPLS) Traffic Engineering (TE)", RFC 4206, 372 DOI 10.17487/RFC4206, October 2005, 373 . 375 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 376 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 377 DOI 10.17487/RFC5440, March 2009, 378 . 380 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 381 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 382 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 383 2009, . 385 Authors' Addresses 387 Siva Sivabalan 388 Cisco Systems, Inc. 389 2000 Innovation Drive 390 Kanata, Ontario K2K 3E8 391 Canada 393 Email: msiva@cisco.com 395 Clarence Filsfils 396 Cisco Systems, Inc. 397 Pegasus Parc 398 De kleetlaan 6a, DIEGEM BRABANT 1831 399 BELGIUM 401 Email: cfilsfil@cisco.com 403 Stefano Previdi 404 Cisco Systems, Inc. 405 Via Del Serafico, 200 406 Rome, Rome 00142 407 Italy 409 Email: sprevidi@cisco.com 410 Jeff Tantsura 411 Individual 412 USA 414 Email: jefftant.ietf@gmail.com 416 Jonathan Hardwick 417 Metaswitch Networks 418 100 Church Street 419 Enfield, Middlesex 420 UK 422 Email: Jonathan.Hardwick@metaswitch.com 424 Dhruv Dhody 425 Huawei Technologies 426 Divyashree Techno Park, Whitefield 427 Bangalore, Karnataka 560066 428 India 430 Email: dhruv.ietf@gmail.com