idnits 2.17.1 draft-leedhody-pce-vn-association-02.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 13, 2017) is 2600 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 (-15) exists of draft-ietf-teas-actn-framework-04 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-11 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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: September 14, 2017 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 March 13, 2017 10 PCEP Extensions for Establishing Relationships Between Sets of LSPs 11 and Virtual Networks 12 draft-leedhody-pce-vn-association-02 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 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on September 14, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 90 provide stateful control. A stateful PCE has access to not only the 91 information carried by the network's Interior Gateway Protocol (IGP), 92 but also 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 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 98 teardown of PCE-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.dhody-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.dhodylee-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 PNC, and the parent PCE as MDSC[ACTN-FWK]. 123 This document specifies a PCEP extension to associate a set of LSPs 124 based on Virtual Network (or customer). 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Terminology 134 The terminology is as per [RFC4655], [RFC5440], [RFC6805], and [I- 135 D.ietf-pce-stateful-pce]. 137 3. Operation Overview 139 As per [I-D.ietf-pce-association-group], LSPs are associated with 140 other LSPs with which they interact by adding them to a common 141 association group. 143 An association group based on VN is useful for various optimizations 144 that should be applied by considering all the LSPs in the 145 association. This includes, but not limited to - 147 o Path Computation: When computing path for a LSP, the impact of 148 this LSP, on the other LSPs belonging to the same VN is useful to 149 analyze. The aim would be optimize overall VN and all LSPs, rather 150 than a single LSP. Also, the optimization criteria such as 151 minimize the load of the most loaded link (MLL) [RFC5541] and 152 other could be applied for all the LSP belonging to the same VN, 153 identified by the VN association. 155 o Path Re-Optimization: The child PCE or the parent PCE would like 156 to use advanced path computation algorithm and optimization 157 technique that consider all the LSPs belonging to a VN/customer 158 and optimize them all together. 160 This association is useful in PCEP session between parent PCE 161 (MDSC) and child PCE (PNC). 163 ****** 164 ..........*MDSC*.............................. 165 . ****** .. MPI . 166 . . . PCEP . 167 . . . PCInitiate LSPx . 168 . . . with VNAG = 10 . 169 . . . . 170 . . . . 171 . . . . 172 v v v . 173 ****** ****** ****** . 174 *PNC1* *PNC2* *PNC4* . 175 ****** ****** ****** . 176 +---------------+ +---------------+ +---------------+ . 177 |A |----| |----| C| . 178 | | | | | | . 179 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 180 +------------B13+ +---------------+ +B43------------+ . 181 / . 182 ****** / . 183 *PNC3*<............/..................... 184 ****** / 185 +---------------+/ 186 B31 B34 187 | | 188 |DOMAIN 3 B| 189 +---------------+ 191 MDSC -> Parent PCE 192 PNC -> Child PCE 193 MPI -> PCEP 195 In this draft, this grouping is used to define associations between a 196 set of LSPs and a virtual network. 198 One new optional Association Object-type is defined based on the 199 generic Association object - 201 o VN Association Group (VNAG) 203 Thus this document define one new association type called "VN 204 Association Type" of value TBD1. The scope and handling of VNAG 205 identifier is similar to the generic association identifier defined 206 in [I-D.ietf-pce-association-group]. 208 Local polices on the PCE MAY define the computational and 209 optimization behavior for the LSPs in the VN. An LSP MUST belong to a 210 single VNAG. If an implementation encounters more than one VNAG, it 211 MUST consider the first occurrence and ignore the others. 213 4. Extensions to PCEP 215 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object, 216 the format of VNAG is as follows: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Reserved | Flags |R| 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Association type=TBD1 | Association ID | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | IPv4 Association Source | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 // Optional TLVs // 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Reserved | Flags |R| 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Association type=TBD1 | Association ID | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 | IPv6 Association Source | 239 | | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 // Optional TLVs // 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1: The VNAG Object formats 247 Please refer to [I-D.ietf-pce-association-group] for the definition 248 of each field in Figure 1. This document defines one mandatory TLV 249 "VIRTUAL-NETWORK-TLV" and one optional TLV "VENDOR-INFORMATION-TLV" - 251 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 252 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 253 specific behavioral information, described in [RFC7470]. 255 The format of VIRTUAL-NETWORK-TLV is as follows. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type=TBD2 | Length (variable) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 // Virtual Network Name // 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: The VIRTUAL-NETWORK-TLV formats 269 Type: TBD2 (to be allocated by IANA) 271 Length: Variable Length 273 Virtual Network Name(variable): symbolic name for the VN. 275 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 276 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 277 MUST send a PCErr message with Error-Type= 6 (mandatory object 278 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close 279 the session. 281 The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 283 5. Applicability to H-PCE architecture 285 The ability to compute shortest constrained TE LSPs in Multiprotocol 286 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 287 multiple domains has been identified as a key motivation for PCE 288 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 289 architecture which can be used for computing end-to-end paths for 290 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 291 Paths (LSPs). Within the hierarchical PCE architecture, the parent 292 PCE is used to compute a multi-domain path based on the domain 293 connectivity information. A child PCE may be responsible for a 294 single domain or multiple domains, it is used to compute the intra- 295 domain path based on its domain topology information. 297 [I-D.dhodylee-pce-stateful-hpce] introduces general considerations 298 for stateful PCE(s) in hierarchical PCE architecture. In particular, 299 the behavior changes and additions to the existing stateful PCE 300 mechanisms in the context of a H-PCE architecture. 302 In Stateful H-PCE architecture, the Parent PCE receives a virtual 303 network creation request by its client over its Northbound API. This 304 VN is uniquely identified by an Association ID in VNAG as well as the 305 VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 306 network in a single domain or across multiple domains. 308 As the Parent PCE computes the optimum E2E paths for each tunnel in 309 VN, it MUST associate each LSP with the VN to which it belongs. 310 Parent PCE sends a PCInitiate Message with this association 311 information in the VNAG Object (See Section 4 for details). This in 312 effect binds an LSP that is to be instantiated at the child PCE with 313 the VN. 315 Whenever changes occur with the instantiated LSP in a domain network, 316 the domain child PCE reports the changes using a PCRpt Message in 317 which the VNAG Object indicates the relationship between the LSP and 318 the VN. 320 Whenever an update occurs with VNs in the Parent PCE (via the 321 client's request), the parent PCE sends an PCUpd Message to inform 322 each affected child PCE of this change. 324 The Child PCE could then use this association to optimize all LSPs 325 belonging to the same VN association together. The Child PCE could 326 further take VN specific actions on the LSPs such as relaxation of 327 constraints, policy actions, setting default behavior etc. The parent 328 PCE could also maintain all E2E LSP or per-domain path segments under 329 a single VN association. 331 6. Security Considerations 333 This document defines one new type for association, which do not add 334 any new security concerns beyond those discussed in [RFC5440], [I- 335 D.ietf-pce-stateful-pce] and [I-D.ietf-pce-association-group] in 336 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 [I-D.ietf-pce-pceps]. 342 7. IANA Considerations 344 7.1. Association Object Type Indicator 346 This document defines the following new association type originally 347 defined in [I-D.ietf-pce-association-group]. 349 Value Name Reference 350 TBD1 VN Association Type [This I.D.] 352 7.2. PCEP TLV Type Indicator 354 This document defines the following new PCEP TLV; IANA is requested 355 to make the following allocations from this registry at 356 ; see PCEP TLV Type 357 Indicators. 359 Value Name Reference 361 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 363 7.3. PCEP Error 365 IANA is requested to make the following allocations from this 366 registry at ; see PCEP-ERROR 367 Object Error Types and Values. 369 This document defines new Error-Type and Error-Value for the 370 following new error conditions: 372 Error-Type Meaning 374 6 Mandatory Object missing 376 Error-value=TBD3: VIRTUAL-NETWORK TLV missing 378 8. Manageability Considerations 380 8.1. Control of Function and Policy 382 An operator MUST BE allowed to mark LSPs that belong to the same VN. 383 This could also be done automatically based on the VN configuration. 385 8.2. Information and Data Models 387 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the 388 association between LSPs including VN association. 390 8.3. Liveness Detection and Monitoring 392 Mechanisms defined in this document do not imply any new liveness 393 detection and monitoring requirements in addition to those already 394 listed in [RFC5440]. 396 8.4. Verify Correct Operations 398 Mechanisms defined in this document do not imply any new operation 399 verification requirements in addition to those already listed in 400 [RFC5440]. 402 8.5. Requirements On Other Protocols 404 Mechanisms defined in this document do not imply any new requirements 405 on other protocols. 407 8.6. Impact On Network Operations 409 Mechanisms defined in this document do not have any impact on network 410 operations in addition to those already listed in [RFC5440]. 412 9. References 414 9.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, DOI 418 10.17487/RFC2119, March 1997. 420 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 421 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 422 March 2009. 424 [I-D.ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, and R. 425 Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- 426 stateful-pce, work in progress. 428 [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP Extensions 429 for PCE-initiated LSP Setup in a Stateful PCE Model", 430 draft-ietf-pce-pce-initiated-lsp, work in progress. 432 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for 433 Establishing Relationships Between Sets of LSPs", draft- 434 ietf-pce-association-group, work in progress. 436 9.2. Informative References 438 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation 439 Element (PCE)-Based Architecture", RFC 4655, August 2006. 441 [RFC6805] A. Farrel and D. King, "The Application of the Path 442 Computation Element Architecture to the Determination of a 443 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 444 2012. 446 [I-D.dhody-pce-applicability-actn] Dhody D., Lee Y., and D. 447 Ceccarelli, "Applicability of Path Computation Element 448 (PCE) for Abstraction and Control of TE Networks (ACTN)", 449 draft-dhody-pce-applicability-actn, work-in-progress. 451 [I-D.dhodylee-pce-stateful-hpce] Dhody, D. and Lee, Y., "Hierarchical 452 Stateful Path Computation Element (PCE)", 453 draft-dhodylee-pce-stateful-hpce, work in progress. 455 [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D. 456 Ceccarelli, "Requirements for Abstraction and Control of TE 457 Networks", draft-ietf-teas-actn-requirements, work in 458 progress. 460 [ACTN-FWK] Ceccarelli D. and Y. Lee, "Framework for Abstraction and 461 Control of Transport Networks", draft-ietf-teas- 462 actn-framework-04 (work in progress), February 2017. 464 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 465 Objective Functions in the Path Computation Element 466 Communication Protocol (PCEP)", RFC 5541, 467 DOI 10.17487/RFC5541, June 2009, 468 . 470 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 471 Constraints in the Path Computation Element Communication 472 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 473 . 475 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 476 Stateful Path Computation Element (PCE)", RFC 8051, 477 DOI 10.17487/RFC8051, January 2017, 478 . 480 [I-D.ietf-pce-pceps] 481 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 482 Transport for PCEP", draft-ietf-pce-pceps-11 (work in 483 progress), January 2017. 485 [I-D.ietf-pce-pcep-yang] 486 Dhody, D., Hardwick, J., Beeram, V., and j. 487 jefftant@gmail.com, "A YANG Data Model for Path 488 Computation Element Communications Protocol (PCEP)", 489 draft-ietf-pce-pcep-yang-02 (work in progress), March 490 2017. 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