idnits 2.17.1 draft-barth-pce-association-bidir-01.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 12, 2017) is 2601 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 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Barth 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Gandhi 5 Expires: September 13, 2017 Cisco Systems, Inc. 6 B. Wen 7 Comcast 8 March 12, 2017 10 PCEP Extensions for Associated Bidirectional Label Switched 11 Paths (LSPs) with Stateful PCE 12 draft-barth-pce-association-bidir-01 14 Abstract 16 The Path Computation Element Communication Protocol (PCEP) provides 17 mechanisms for Path Computation Elements (PCEs) to perform path 18 computations in response to Path Computation Clients (PCCs) requests. 19 The Stateful PCE extensions allow stateful control of Multi-Protocol 20 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 21 (LSPs) using PCEP. The Resource Reservation Protocol (RSVP) is used 22 to signal the LSP in the network. 24 This document defines PCEP extensions for binding two reverse 25 unidirectional RSVP TE LSPs into an Associated Bidirectional Label 26 Switched Path (LSP) when using Stateful PCE for both PCE-Initiated 27 and PCC-Initiated LSPs. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 Copyright Notice 46 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 63 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 4 67 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 5 68 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 5 69 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 6 71 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 6 72 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 7 74 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 7 75 5.3. State Synchronization . . . . . . . . . . . . . . . . . . 8 76 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. Manageability Considerations . . . . . . . . . . . . . . . . . 8 79 7.1. Control of Function and Policy . . . . . . . . . . . . . . 8 80 7.2. Information and Data Models . . . . . . . . . . . . . . . 8 81 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 82 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 83 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 84 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 9 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 9 87 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 88 8.2.1. Flag Fields in Bidirectional LSP Association Group 89 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 10.2. Informative References . . . . . . . . . . . . . . . . . 11 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 97 1. Introduction 99 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 100 communication mechanism between a Path Computation Client (PCC) and a 101 Path Control Element (PCE), or between PCE and PCC, that enables 102 computation of Multi-Protocol Label Switching (MPLS) Traffic 103 Engineering (TE) Label Switched Paths (LSPs). 105 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 106 stateful control of MPLS TE LSPs. It describes two modes of 107 operation - Passive Stateful PCE and Active Stateful PCE. In [I- 108 D.ietf-pce-stateful-pce], the focus is on Active Stateful PCE where 109 LSPs are provisioned on the PCC and control over them is delegated to 110 a PCE. Further [I-D.ietf-pce-pce-initiated-lsp] describes the setup, 111 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 112 model. 114 [I-D.ietf-pce-association] introduces a generic mechanism to create a 115 grouping of LSPs which can then be used to define associations 116 between a set of LSPs and/or a set of attributes, for example primary 117 and secondary LSP associations, and is equally applicable to the 118 active and passive modes of a Stateful PCE [I-D.ietf-pce-stateful- 119 pce] or a stateless PCE [RFC5440]. 121 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 122 specifies that MPLS-TP MUST support associated bidirectional point- 123 to-point LSPs. [RFC7551] specifies RSVP signaling extensions for 124 binding two reverse unidirectional LSPs into an associated 125 bidirectional LSP. 127 This document specifies PCEP extensions for binding two reverse 128 unidirectional RSVP-TE LSPs into an Associated Bidirectional LSP for 129 both single-sided and double-sided initiation cases when using 130 Stateful PCE. The PCEP extensions cover the following cases: 132 o The forward or reverse LSP of an bidirectional LSP is initiated on 133 a PCC by a Stateful PCE which retains the control of the LSP. The 134 PCE is responsible for computing the path of the LSP and updating 135 the PCC with the information about the path. 137 o A PCC initiates the forward or reverse LSP of a bidirectional LSP 138 and retains the control of the LSP. The PCC computes the path and 139 updates the PCE with the information about the path (as long as it 140 controls the LSP). 142 o A PCC initiates the forward or reverse LSP of a bidirectional LSP 143 and delegates the control of the LSP to a Stateful PCE. The PCE 144 may compute the path for the LSP and update the PCC with the 145 information about the path (as long as it controls the LSP). 147 2. Conventions Used in This Document 149 2.1. Key Word Definitions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 2.2. Terminology 157 The reader is assumed to be familiar with the terminology defined in 158 [RFC5440] and [RFC7551]. 160 3. Overview 162 As shown in Figure 1, two reverse unidirectional LSPs can be 163 associated to form an associated bidirectional LSP. There are two 164 methods of initiating the bidirectional LSP association, single-sided 165 and double-sided as described in the following sections. 167 LSP1 --> LSP1 --> LSP1 --> 168 +-----+ +-----+ +-----+ +-----+ 169 | A +-----------+ B +-----------+ C |-----------+ D | 170 +-----+ +-----+ +-----+ +-----+ 171 <--LSP2 | | <-- LSP2 172 | | 173 | | 174 +-----+ +-----+ 175 + E +-----------+ F | 176 +-----+ +-----+ 177 <-- LSP2 179 Figure 1: An Example of Associated Bidirectional LSP 181 3.1. Single-sided Initiation 183 As specified in [RFC7551], in the single-sided initiation case, the 184 bidirectional tunnel is signaled only on one ingress endpoint node 185 (PCC) of a LSP tunnel. Both forward and reverse LSPs are initiated 186 by the Stateful PCE with the Association Type set to "Single-sided 187 Bidirectional LSP Association" on the originating endpoint node 188 (PCC). The originating PCC identifies the forward and reverse LSPs 189 in the TLV of the Association Objects. 191 The originating endpoint node uses the properties for the revere LSP 192 in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 193 message. The remote endpoint then creates the corresponding reverse 194 tunnel and signals the reverse LSP in response to the received RSVP 195 Path message. The two unidirectional reverse LSPs on the originating 196 endpoint node are bound together using the PCEP signaled Association 197 Objects and on the remote endpoint node by the RSVP signaled 198 Association Objects. 200 As shown in Figure 1, the forward LSP LSP1 and the reverse LSP LSP2 201 are initiated on the originating endpoint node A by the PCE. The 202 creation of reverse LSP2 on the remote endpoint node D is triggered 203 by the RSVP signaled LSP1. 205 3.2. Double-sided Initiation 207 As specified in [RFC7551], in the double-sided initiation case, the 208 bidirectional LSP is signaled by both endpoint nodes (PCCs) of the 209 tunnel. The forward and reverse LSPs for this tunnel are initiated 210 by the Stateful PCE with Association Type set to "Double-sided 211 Bidirectional LSP Association" on both ingress PCCs. The two reverse 212 unidirectional LSPs on both PCCs are bound together by using the PCEP 213 signaled Association Objects. 215 As shown in Figure 1, LSP1 is initiated on the endpoint node A and 216 LSP2 is initiated on the endpoint node D, both by the PCE. 218 3.3. Co-routed Associated Bidirectional LSP 220 In both single-sided and double-sided initiation cases, forward and 221 reverse LSPs may be co-routed as shown in Figure 2, where both 222 forward and reverse LSPs follow the same congruent path. 224 LSP3 --> LSP3 --> LSP3 --> 225 +-----+ +-----+ +-----+ +-----+ 226 | A +-----------+ B +-----------+ C |-----------+ D | 227 +-----+ +-----+ +-----+ +-----+ 228 <-- LSP4 <-- LSP4 <-- LSP4 230 Figure 2: An Example of Co-routed Associated Bidirectional LSP 232 4. Protocol Extensions 233 4.1. Association Object 235 As per [I-D.ietf-pce-association], LSPs are associated by adding them 236 to a common association group. This document defines new 237 Bidirectional LSP Association Groups to be used by the associated 238 bidirectional LSPs. A member of the Bidirectional LSP Association 239 Group can take the role of a forward or reverse LSP. The reverse LSP 240 source address MUST be the destination address of the forward LSP and 241 destination address MUST be the source address of the forward LSP 242 within a bidirectional LSP association group. 244 This document defines two new Association Types for the Association 245 Object as follows: 247 o Association Type (TBD1) = Single-sided Bidirectional LSP 248 Association Group 250 o Association Type (TBD2) = Double-sided Bidirectional LSP 251 Association Group 253 The Association ID, Association Source, optional Global Association 254 Source and optional Extended Association ID in the Bidirectional LSP 255 Association Group Object are initiated by the Stateful PCE using the 256 procedures defined in [RFC7551]. 258 4.2. Bidirectional LSP Association Group TLV 260 The Bidirectional LSP Association Group TLV is an optional TLV for 261 use with the Bidirectional LSP Association Object Type. 263 o The Bidirectional LSP Association Group TLV follows the PCEP TLV 264 format from [RFC5440]. 266 o The type (16 bits) of the TLV is TBD3, to be assigned by IANA. 268 o The length is 4 Bytes. 270 o The value comprises of a single field, the Bidirectional LSP 271 Association Flags (32 bits), where each bit represents a flag 272 option. 274 o If the Bidirectional LSP Association Group TLV is missing, it 275 means the LSP is the forward LSP. 277 o The Bidirectional LSP Association Group TLV MUST NOT be present 278 more than once. If it appears more than once, only the first 279 occurrence is processed and any others MUST be ignored. 281 The format of the Bidirectional LSP Association Group TLV is shown in 282 Figure 3: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type = TBD3 | Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Reserved |C|R|F| 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 3: Bidirectional LSP Association Group TLV format 294 Bidirectional LSP Association Flags are defined as following. 296 F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the 297 forward LSP of the bidirectional LSP. If this flag is set, the LSP 298 is a forward LSP. 300 R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the 301 reverse LSP of the bidirectional LSP. If this flag is set, the LSP 302 is a reverse LSP. 304 C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is 305 co-routed. If this flag is set, the associated bidirectional LSP 306 is co-routed. 308 The Reserved flags MUST be set to 0 when sent and ignore when 309 received. 311 When an associated bidirectional LSP is delegated to a Stateful PCE, 312 the C flag is used by the PCE to compute paths of the forward and 313 reverse LSPs those are co-routed. 315 5. PCEP Procedure 317 5.1. PCE Initiated LSPs 319 As specified in [I-D.ietf-pce-association], Association Groups can be 320 created by both PCE and PCC. 322 A PCE can create and update the forward and reverse LSPs 323 independently for both Single-sided and Double-sided bidirectional 324 LSP association groups. 326 5.2. PCC Initiated LSPs 327 A PCC can associate or remove an LSP under its control from the 328 bidirectional LSP association group. The PCC must report the change 329 in association to PCE(s) via PCRpt message. 331 5.3. State Synchronization 333 During state synchronization, a PCC MUST report all the existing 334 bidirectional LSP association groups to PCE(s). Following the state 335 synchronization, the PCE MUST remove all stale associations. 337 5.4. Error Handling 339 The reverse LSP in the bidirectional LSP association group MUST have 340 the source address matching the destination address of the forward 341 LSP and destination address matching the source address of the 342 forward LSP. If a PCE attempts to add an LSP to a bidirectional LSP 343 association group not complying to this rule, the PCC for the single- 344 sided initiation case MUST send PCErr with Error-Type= TBD4 345 (Bidirectional LSP Association Error) and Error-Value = 1 (Endpoints 346 mismatch). Similarly, if a PCC attempt to add an LSP to a 347 bidirectional LSP association group at PCE not complying to this 348 rule, the PCE for both single-sided and double-sided initiated 349 bidirectional LSPs MUST send this PCErr. 351 6. Security Considerations 353 This document introduces two new Association Types for the 354 Association Object, Double-sided Bidirectional LSP Association Group 355 and Single-sided Associated Bidirectional LSP Group. These types, by 356 themselves, introduce no additional security concerns beyond those 357 discussed in [RFC5440], [I-D.ietf-pce-stateful-pce] and [I-D.ietf- 358 pce-association]. 360 7. Manageability Considerations 362 7.1. Control of Function and Policy 364 An operator MUST be allowed to provision the bidirectional LSP 365 association parameters at PCEP peers. 367 7.2. Information and Data Models 369 A Management Information Base (MIB) module for modeling PCEP is 370 described in [RFC7420]. However, one may prefer the mechanism for 371 configuration using YANG data model [I-D.pce-pcep-yang]. These 372 SHOULD be enhanced to provide controls and indicators for support of 373 the associated bidirectional LSP feature. Support for various 374 configuration knobs as well as counters of messages sent/received 375 containing the TLVs (defined in this document) SHOULD be added. 377 7.3. Liveness Detection and Monitoring 379 Mechanisms defined in this document do not imply any new liveness 380 detection and monitoring requirements in addition to those already 381 listed in [RFC5440]. 383 7.4. Verify Correct Operations 385 Mechanisms defined in this document do not imply any new operation 386 verification requirements in addition to those already listed in 387 [RFC5440]. 389 7.5. Requirements On Other Protocols 391 Mechanisms defined in this document do not add any new requirements 392 on other protocols. 394 7.6. Impact On Network Operations 396 Mechanisms defined in this document do not have any new impact on 397 network operations. 399 8. IANA Considerations 401 8.1. Association Types 403 This document defines the following Association Types for the 404 Association Object defined [I-D.ietf-pce-association]. 406 Value Name Reference 407 -------------------------------------------------------------------- 408 TBD1 Single-sided Bidirectional LSP Association Group [This I.D.] 409 TBD2 Double-sided Bidirectional LSP Association Group [This I.D.] 411 8.2. Bidirectional LSP Association Group TLV 413 This document defines a new TLV for carrying additional LSP 414 information for the Bidirectional LSP Association Group TLV as 415 following: 417 TLV-Type Name Reference 418 --------------------------------------------------------------- 419 TBD3 Bidirectional LSP Association Group TLV [This I.D.] 421 8.2.1. Flag Fields in Bidirectional LSP Association Group TLV 423 This document requests that a new sub-registry, named "Bidirectional 424 LSP Association Group TLV Flag Field", is created within the "Path 425 Computation Element Protocol (PCEP) Numbers" registry to manage the 426 Flag field in the Bidirectional LSP Association Group TLV. 428 New values are to be assigned by Standards Action [RFC5226]. Each 429 bit should be tracked with the following qualities: 431 o Bit number (counting from bit 0 as the most significant bit) 433 o Capability description 435 o Defining RFC 437 The following values are defined in this document for the Flag field. 439 Bit Description Reference 440 ------------------------------------------------- 441 31 F - Forward LSP [This I.D.] 442 30 R - Reverse LSP [This I.D.] 443 29 C - Co-routed LSP [This I.D.] 445 8.3. PCEP Errors 447 This document defines new Error-Type and Error-Value related to 448 bidirectional LSP association as following. 450 Error-Type Description Reference 451 --------------------------------------------------------------- 452 TBD4 Bidirectional LSP Association Error [This I.D.] 454 Error-value=1: Endpoints mismatch [This I.D.] 456 9. Acknowledgments 458 TBA. 460 10. References 462 10.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 468 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 469 May 2008. 471 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 472 Element (PCE) Communication Protocol (PCEP)", RFC 5440. 474 [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE 475 Extensions for Associated Bidirectional LSPs", RFC 7551, 476 May 2015. 478 [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., 479 Ananthakrishnan, H., Zhang, X., and Y. Tanaka, "PCEP 480 Extensions for Establishing Relationships Between Sets of 481 LSPs", draft-ietf-pce-association-group (work in 482 progress). 484 [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and 485 R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf- 486 pce-stateful-pce (work in progress). 488 10.2. Informative References 490 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 491 Sprecher, N., and S. Ueno, "Requirements of an MPLS 492 Transport Profile", RFC 5654, September 2009. 494 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 495 Hardwick, "Path Computation Element Communication Protocol 496 (PCEP) Management Information Base (MIB) Module", RFC 497 7420, December 2014. 499 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 500 S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 501 Setup in a Stateful PCE Model", draft-ietf-pce-pce- 502 initiated-lsp (work in progress). 504 [I-D.pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 505 Tantsura, "A YANG Data Model for Path Computation Element 506 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 507 (work in progress). 509 Authors' Addresses 511 Colby Barth 512 Juniper Networks 514 EMail: cbarth@juniper.net 516 Rakesh Gandhi 517 Cisco Systems, Inc. 519 EMail: rgandhi@cisco.com 521 Bin Wen 522 Comcast 524 EMail: Bin_Wen@cable.comcast.com