idnits 2.17.1 draft-leedhody-pce-vn-association-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 (June 21, 2018) is 2135 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Lee 3 Internet-Draft D. Dhody 4 Intended Status: Standards track X. Zhang 5 Expires: December 23, 2018 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 June 21, 2018 10 PCEP Extensions for Establishing Relationships Between Sets of LSPs 11 and Virtual Networks 12 draft-leedhody-pce-vn-association-05 14 Abstract 16 This document describes how to extend Path Computation Element (PCE) 17 Communication Protocol (PCEP) association mechanism introduced by the 18 PCEP Association Group specification, to further associate sets of 19 LSPs with a higher-level structure such as a virtual network (VN) 20 requested by clients or applications. This extended association 21 mechanism can be used to facilitate virtual network control using PCE 22 architecture. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 https://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 https://www.ietf.org/shadow.html 44 This Internet-Draft will expire on September 01, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................2 64 1.1. Requirements Language.....................................3 65 2. Terminology....................................................4 66 3. Operation Overview.............................................4 67 4. Extensions to PCEP.............................................4 68 5. Applicability to H-PCE architecture............................6 69 6. Security Considerations........................................7 70 7. IANA Considerations............................................7 71 7.1. Association Object Type Indicator.........................7 72 7.2. PCEP TLV Type Indicator...................................8 73 7.3. PCEP Error................................................8 74 8. References.....................................................8 75 8.1. Normative References......................................8 76 8.2. Informative References....................................9 77 Author's Addresses................................................9 79 1. Introduction 81 The Path Computation Element communication Protocol (PCEP) provides 82 mechanisms for Path Computation Elements (PCEs) to perform path 83 computations in response to Path Computation Clients' (PCCs) 84 requests. 86 [RFC8051] describes general considerations for a stateful PCE 87 deployment and examines its applicability and benefits, as well as 88 its challenges and limitations through a number of use cases. 89 [RFC8231] describes a set of extensions to PCEP to provide stateful 90 control. A stateful PCE has access to not only the information 91 carried by the network's Interior Gateway Protocol (IGP), but also 92 the set of active paths and their reserved resources for its 93 computations. The additional state allows the PCE to compute 94 constrained paths while considering individual LSPs and their 95 interactions. 97 [RFC8281] describes the setup, maintenance and teardown of PCE- 98 initiated LSPs under the stateful PCE model. 100 [I-D.ietf-pce-association-group] introduces a generic mechanism to 101 create a grouping of LSPs. This grouping can then be used to define 102 association between sets of LSPs or between a set of LSPs and a set 103 of attributes. 105 [ACTN-REQ] describes various Virtual Network (VN) operations 106 initiated by a customer/application. In this context, there is a need 107 for associating a set of LSPs with a VN "construct" to facilitate VN 108 operations in PCE architecture. This association allows the PCEs to 109 identify which LSPs belong to a certain VN. The PCE could then use 110 this association to optimize all LSPs belonging to the VN together. 111 The PCE could further take VN specific actions on the LSPs such as 112 relaxation of constraints, policy actions, setting default behavior 113 etc. 115 [I-D.ietf-pce-applicability-actn] examines the PCE and ACTN 116 architecture and describes how the PCE architecture is applicable to 117 ACTN. [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a 118 hierarchy of stateful PCEs with Parent PCE coordinating multi-domain 119 path computation function between Child PCE(s) and thus making it the 120 base for PCE applicability for ACTN. In this text child PCE would be 121 same as Provisioning Network Controller (PNC), and the parent PCE as 122 Multi-domain Service Coordinator (MDSC) [ACTN-FWK]. 124 This document specifies a PCEP extension to associate a set of LSPs 125 based on Virtual Network (VN) (or customer). A Virtual Network (VN) 126 is a customer view of the TE network. Depending on the agreement 127 between client and provider various VN operations and VN views are 128 possible as described in [ACTN-FWK]. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2. Terminology 140 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231] 141 and [ACTN-FWK].. 143 3. Operation Overview 145 As per [I-D.ietf-pce-association-group], LSPs are associated with 146 other LSPs with which they interact by adding them to a common 147 association group. 149 An association group based on VN is useful for various optimizations 150 that should be applied by considering all the LSPs in the 151 association. This includes, but not limited to - 153 o Path Computation: When computing path for a LSP, the impact of 154 this LSP, on the other LSPs belonging to the same VN is useful to 155 analyze. The aim would be optimize overall VN and all LSPs, rather 156 than a single LSP. Also, the optimization criteria such as 157 minimize the load of the most loaded link (MLL) [RFC5541] and 158 other could be applied for all the LSP belonging to the same VN, 159 identified by the VN association. 161 o Path Re-Optimization: The child PCE or the parent PCE would like 162 to use advanced path computation algorithm and optimization 163 technique that consider all the LSPs belonging to a VN/customer 164 and optimize them all together during the re-optimization. 166 This association is useful in PCEP session between parent PCE 167 (MDSC) and child PCE (PNC). 169 ****** 170 ..........*MDSC*.............................. 171 . ****** .. MPI . 172 . . . PCEP . 173 . . . PCInitiate LSPx . 174 . . . with VNAG = 10 . 175 . . . . 176 . . . . 177 . . . . 178 v v v . 179 ****** ****** ****** . 180 *PNC1* *PNC2* *PNC4* . 181 ****** ****** ****** . 182 +---------------+ +---------------+ +---------------+ . 183 |A |----| |----| C| . 184 | | | | | | . 185 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 186 +------------B13+ +---------------+ +B43------------+ . 187 / . 188 ****** / . 189 *PNC3*<............/..................... 190 ****** / 191 +---------------+/ 192 B31 B34 193 | | 194 |DOMAIN 3 B| 195 +---------------+ 197 MDSC -> Parent PCE 198 PNC -> Child PCE 199 MPI -> PCEP 201 In this draft, this grouping is used to define associations between a 202 set of LSPs and a virtual network, a new association group is defined 203 below - 205 o VN Association Group (VNAG) 207 One new Association type is defined as described in the Association 208 object - 210 o Association type = TBD1 ("VN Association") for VNAG 212 The scope and handling of VNAG identifier is similar to the generic 213 association identifier defined in [I-D.ietf-pce-association-group]. 215 Local polices on the PCE MAY define the computational and 216 optimization behavior for the LSPs in the VN. An LSP MUST belong to a 217 single VNAG. If an implementation encounters more than one VNAG, it 218 MUST consider the first occurrence and ignore the others. 220 [I-D.ietf-pce-association-group] specify the mechanism for the 221 capability advertisement of the association types supported by a PCEP 222 speaker by defining a ASSOC-Type-List TLV to be carried within an 223 OPEN object. This capability exchange for the association type 224 described in this document (i.e. VN Association Type) MUST be done 225 before using the policy association. Thus the PCEP speaker MUST 226 include the VN Association Type (TBD1) in the ASSOC-Type-List TLV 227 before using the VNAG in the PCEP messages. 229 This Association-Type is dynamic in nature and created by the Parent 230 PCE (MDSC) for the LSPs belonging to the same VN or customer. These 231 associations are conveyed via PCEP messages to the PCEP peer. 232 Operator-configured Association Range MUST NOT be set for this 233 association-type and MUST be ignored. 235 4. Extensions to PCEP 237 The format of VNAG is as per the ASSOCIATION object [I-D.ietf-pce- 238 association-group]. 240 This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one 241 new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV, 242 VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific 243 information. 245 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 247 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 248 specific behavioral information, described in [RFC7470]. 250 The format of VIRTUAL-NETWORK-TLV is as follows. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type=TBD2 | Length (variable) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 // Virtual Network Name // 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 1: The VIRTUAL-NETWORK-TLV formats 264 Type: TBD2 (to be allocated by IANA) 266 Length: Variable Length 268 Virtual Network Name (variable): an unique symbolic name for the VN. 269 It SHOULD be a string of printable ASCII characters, without a NULL 270 terminator. The VN name is a human-readable string that identifies 271 a VN. The VN name MUST remain constant throughout an LSP's lifetime, 272 which may span across multiple consecutive PCEP sessions and/or 273 PCC restarts. The VN name MAY be specified by an operator or 274 auto-generated by the PCEP speaker. 276 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 277 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 278 MUST send a PCErr message with Error-Type=6 (mandatory object 279 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 280 the session. 282 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 284 5. Applicability to H-PCE architecture 286 The ability to compute shortest constrained TE LSPs in Multiprotocol 287 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 288 multiple domains has been identified as a key motivation for PCE 289 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 290 architecture which can be used for computing end-to-end paths for 291 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 292 Paths (LSPs). Within the hierarchical PCE architecture, the parent 293 PCE is used to compute a multi-domain path based on the domain 294 connectivity information. A child PCE may be responsible for a 295 single domain or multiple domains, it is used to compute the intra- 296 domain path based on its domain topology information. 298 [I-D.ietf-pce-stateful-hpce] introduces general considerations for 299 stateful PCE(s) in hierarchical PCE architecture. In particular, the 300 behavior changes and additions to the existing stateful PCE 301 mechanisms in the context of a H-PCE architecture. 303 In Stateful H-PCE architecture, the Parent PCE receives a virtual 304 network creation request by its client over its Northbound API. This 305 VN is uniquely identified by an Association ID in VNAG as well as the 306 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 307 network in a single domain or across multiple domains. 309 As the Parent PCE computes the optimum E2E paths for each tunnel in 310 VN, it MUST associate each LSP with the VN to which it belongs. 311 Parent PCE sends a PCInitiate Message with this association 312 information in the VNAG Object (See Section 4 for details). This in 313 effect binds an LSP that is to be instantiated at the child PCE with 314 the VN. 316 Whenever changes occur with the instantiated LSP in a domain network, 317 the domain child PCE reports the changes using a PCRpt Message in 318 which the VNAG Object indicates the relationship between the LSP and 319 the VN. 321 Whenever an update occurs with VNs in the Parent PCE (via the 322 client's request), the parent PCE sends an PCUpd Message to inform 323 each affected child PCE of this change. 325 The Child PCE could then use this association to optimize all LSPs 326 belonging to the same VN association together. The Child PCE could 327 further take VN specific actions on the LSPs such as relaxation of 328 constraints, policy actions, setting default behavior etc. The parent 329 PCE could also maintain all E2E LSP or per-domain path segments under 330 a single VN association. 332 6. Security Considerations 334 This document defines one new type for association, which do not add 335 any new security concerns beyond those discussed in [RFC5440], 336 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 338 Some deployments may find VN associations and their implications as 339 extra sensitive and thus should employ suitable PCEP security 340 mechanisms like TCP-AO or [RFC8253]. 342 7. IANA Considerations 344 7.1. Association Object Type Indicator 346 This document defines a new association type, originally defined in 347 [I-D.ietf-pce-association-group], for path protection. IANA is 348 requested to make the assignment of a new value for the sub-registry 349 "ASSOCIATION Type Field" (request to be created in [I-D.ietf-pce- 350 association-group]), as follows: 352 Value Name Reference 354 TBD1 VN Association Type [This I.D.] 356 7.2. PCEP TLV Type Indicator 358 This document defines a new TLV for carrying additional information 359 of LSPs within a path protection association group. IANA is 360 requested to make the assignment of a new value for the existing 361 "PCEP TLV Type Indicators" registry as follows: 363 Value Name Reference 365 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 367 7.3. PCEP Error 369 This document defines new Error-Type and Error-Value related to path 370 protection association. IANA is requested to allocate new error 371 values within the "PCEP-ERROR Object Error Types and Values" sub- 372 registry of the PCEP Numbers registry, as follows: 374 Error-Type Meaning 376 6 Mandatory Object missing 377 Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This 378 I.D.] 380 8. Manageability Considerations 382 8.1. Control of Function and Policy 384 An operator MUST BE allowed to mark LSPs that belong to the same VN. 385 This could also be done automatically based on the VN configuration. 387 8.2. Information and Data Models 389 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the 390 association between LSPs including VN association. 392 8.3. Liveness Detection and Monitoring 394 Mechanisms defined in this document do not imply any new liveness 395 detection and monitoring requirements in addition to those already 396 listed in [RFC5440]. 398 8.4. Verify Correct Operations 400 Mechanisms defined in this document do not imply any new operation 401 verification requirements in addition to those already listed in 402 [RFC5440]. 404 8.5. Requirements On Other Protocols 406 Mechanisms defined in this document do not imply any new requirements 407 on other protocols. 409 8.6. Impact On Network Operations 411 Mechanisms defined in this document do not have any impact on network 412 operations in addition to those already listed in [RFC5440]. 414 9. References 416 9.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, DOI 420 10.17487/RFC2119, March 1997. 422 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 423 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 424 March 2009. 426 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 427 2119 Key Words", BCP 14, RFC 8174, May 2017. 429 [RFC8231] E. Crabbe, I. Minei, J. Medved, and R. Varga, "PCEP 430 Extensions for Stateful PCE", RFC 8231, September 2017. 432 [RFC8281] E. Crabbe, et. al., "PCEP Extensions for PCE-initiated LSP 433 Setup in a Stateful PCE Model", RFC 8281, December 2017. 435 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for 436 Establishing Relationships Between Sets of LSPs", draft- 437 ietf-pce-association-group, work in progress. 439 9.2. Informative References 441 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation 442 Element (PCE)-Based Architecture", RFC 4655, August 2006. 444 [RFC6805] A. Farrel and D. King, "The Application of the Path 445 Computation Element Architecture to the Determination of a 446 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 447 2012. 449 [I-D.ietf-pce-applicability-actn] Dhody D., Lee Y., and D. 450 Ceccarelli, "Applicability of Path Computation Element 451 (PCE) for Abstraction and Control of TE Networks (ACTN)", 452 draft-ietf-pce-applicability-actn, work-in-progress. 454 [I-D.ietf-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical 455 Stateful Path Computation Element (PCE)", 456 draft-ietf-pce-stateful-hpce, work in progress. 458 [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D. 459 Ceccarelli, "Requirements for Abstraction and Control of TE 460 Networks", draft-ietf-teas-actn-requirements, work in 461 progress. 463 [ACTN-FWK] Ceccarelli D. and Y. Lee, "Framework for Abstraction and 464 Control of Transport Networks", draft-ietf-teas- 465 actn-framework (work in progress). 467 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 468 Objective Functions in the Path Computation Element 469 Communication Protocol (PCEP)", RFC 5541, 470 DOI 10.17487/RFC5541, June 2009, 471 . 473 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 474 Constraints in the Path Computation Element Communication 475 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 476 . 478 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 479 Stateful Path Computation Element (PCE)", RFC 8051, 480 DOI 10.17487/RFC8051, January 2017, 481 . 483 [RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 484 Transport for PCEP", RFC 8253, October 2017 . 486 [I-D.ietf-pce-pcep-yang] 487 Dhody, D., Hardwick, J., Beeram, V., and j. 488 jefftant@gmail.com, "A YANG Data Model for Path 489 Computation Element Communications Protocol (PCEP)", 490 draft-ietf-pce-pcep-yang (work in progress). 492 Author's Addresses 494 Young Lee (Editor) 495 Huawei Technologies 496 5340 Legacy Drive, Building 3 497 Plano, TX 75023, 498 USA 500 Email: leeyoung@huawei.com 502 Dhruv Dhody (Editor) 503 Huawei Technologies 504 Divyashree Technopark, Whitefield 505 Bangalore, Karnataka 560066 506 India 508 Email: dhruv.ietf@gmail.com 510 Xian Zhang 511 Huawei Technologies 512 China 514 Email: zhang.xian@huawei.com 516 Daniele Ceccarelli 517 Ericsson 518 Torshamnsgatan,48 519 Stockholm, 520 Sweden 522 Email: daniele.ceccarelli@ericsson.com