idnits 2.17.1 draft-leedhody-pce-vn-association-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PCE-Association]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2016) is 2980 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) == Missing Reference: 'PCE-Association' is mentioned on line 18, but not defined == Missing Reference: 'RFC2119' is mentioned on line 120, but not defined ** Downref: Normative reference to an Informational draft: draft-dhodylee-pce-stateful-hpce (ref. 'I-D.ietf-dhodylee-stateful-HPCE') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Y. Lee 2 D. Dhody 3 Internet-Draft Huawei Technologies 4 Intended Status: Standards track D. Ceccarelli 5 Ericsson 6 Expires: August 2016 8 February 25, 2016 10 PCEP Extensions for Establishing Relationships Between Sets of LSPs 11 and Virtual Networks 13 draft-leedhody-pce-vn-association-00.txt 15 Abstract 17 This document describes how to extend PCE association mechanism 18 introduced by [PCE-Association] to further associate sets of LSPs 19 with a higher-level structure such as a virtual network requested by 20 clients or applications. This extended association mechanism can be 21 used to facilitate virtual network control using PCE architecture. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on July 25, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................2 63 1.1. Requirements Language.....................................3 64 2. Terminology....................................................4 65 3. Operation Overview.............................................4 66 4. Extensions to PCEP.............................................4 67 5. Applicability to H-PCE architecture............................6 68 6. Security Considerations........................................7 69 7. IANA Considerations............................................7 70 7.1. Association Object Type Indicator.........................7 71 7.2. PCEP TLV Type Indicator...................................8 72 7.3. PCEP Error................................................8 73 8. References.....................................................8 74 8.1. Normative References......................................8 75 8.2. Informative References....................................9 76 Author's Addresses................................................9 78 1. Introduction 80 The Path Computation Element communication Protocol (PCEP) provides 81 mechanisms for Path Computation Elements (PCEs) to perform path 82 computations in response to Path Computation Clients' (PCCs) 83 requests. 85 [I-D.ietf-pce-stateful-pce-app] describes general considerations for 86 a stateful PCE deployment and examines its applicability and 87 benefits, as well as its challenges and limitations through a number 88 of use cases. [I-D.ietf-pce-stateful-pce] describes a set of 89 extensions to PCEP to provide stateful control. A stateful PCE has 90 access to not only the information carried by the network's Interior 91 Gateway Protocol (IGP), but also the set of active paths and their 92 reserved resources for its computations. The additional state 93 allows the PCE to compute constrained paths while considering 94 individual LSPs and their interactions. 96 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance 97 and teardown of PCE-initiated LSPs under the stateful PCE model. 98 Within the hierarchical PCE architecture, a PCE is used to initiate 99 or delete LSPs to a PCC. 101 [I-D.ietf-pce-association-group] introduces a generic mechanism to 102 create a grouping of LSPs. This grouping can then be used to define 103 association between sets of LSPs or between a set of LSPs and a set 104 of attributes. 106 [ACTN-REQ] describes various Virtual Network (VN) operations 107 initiated by a customer/application. In this context, there is a 108 need for associating a set of LSPs with a VN "construct" to 109 facilitate VN operations in PCE architecture. This association 110 allows the PCEs to identify which LSPs belong to a certain VN. 112 This document specifies a PCEP extension to associate a set of LSPs 113 based on Virtual Network or customer. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Terminology 123 The terminology is as per [RFC4655], [RFC5440], [RFC6805], and [I- 124 D.ietf-pce-stateful-pce]. 126 3. Operation Overview 128 As per [I-D.ietf-pce-association-group], LSPs are associated with 129 other LSPs with which they interact by adding them to a common 130 association group. In this draft, this grouping is used to define 131 associationsbetween a set of LSPs and a virtual network. 133 One new optional Association Object-type is defined based on the 134 generic Association object - 136 o VN Association Group (VNAG) 138 Thus this document define one new association type called "VN 139 Association Type" of value TBD1. The scope and handling of VNAG 140 identifier is similar to the generic association identifier defined 141 in [I-D.ietf-pce-association-group]. 143 4. Extensions to PCEP 145 [I-D.ietf-pce-association-group] introduces the ASSOCIATION object, 146 the format of VNAG is as follows: 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Reserved | Flags |R| 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Association type=TBD1 | Association ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | IPv4 Association Source | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 // Optional TLVs // 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Reserved | Flags |R| 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Association type=TBD1 | Association ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 | IPv6 Association Source | 169 | | 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 // Optional TLVs // 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: The VNAG Object formats 177 Please refer to [I-D.ietf-pce-association-group] for the definition 178 of each field in Figure 1. This document defines one mandatory TLV. 180 o VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier. 182 The format of VIRTUAL-NETWORK-TLV is as follows. 184 0 1 2 3 186 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type=[TBD2] | Length (variable) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 // Virtual Network Name // 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2: The VIRTUAL-NETWORK-TLV formats 198 Type: TBD2 (to be allocated by IANA) 200 Length: Variable Length 202 Virtual Network Name(variable): symbolic name for the VN. 204 The VIRTUAL-NETWORK-TLV MUST be included in VNAG object.If a PCEP 205 speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it 206 MUST send a PCErr message with Error-Type= 6 (mandatory object 207 missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and 208 close the session. 210 5. Applicability to H-PCE architecture 212 The ability to compute shortest constrained TE LSPs in Multiprotocol 213 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 214 multiple domains has been identified as a key motivation for PCE 215 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 216 architecture which can be used for computing end-to-end paths for 217 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 218 Paths (LSPs). Within the hierarchical PCE architecture, the parent 219 PCE is used to compute a multi-domain path based on the domain 220 connectivity information. A child PCE may be responsible for a 221 single domain or multiple domains, it is used to compute the intra- 222 domain path based on its domain topology information. 224 [I-D.ietf-dhodylee-stateful-HPCE] introduces general considerations 225 for stateful PCE(s) in hierarchical PCE architecture. In 226 particular, the behavior changes and additions to the existing 227 stateful PCE mechanisms in the context of a H-PCE architecture. 229 In Stateful H-PCE architecture, the Parent PCE receives a virtual 230 network creation request by its client over its Northbound API. This 231 VN is uniquely identified by an Association ID in VNAG as well as 232 the VIRTUAL-NETWORK name. This VN may comprise multiple LSPs in the 233 network in a single domain or across multiple domains. 235 As the Parent PCE computes the optimum E2E paths for each tunnel in 236 VN, it MUST associate each LSP with the VN to which it belongs. 237 Parent PCE sends a PCInitiate Message with this association 238 information in the VNAG Object (See Section 4 for details). This in 239 effect binds an LSP that is to be instantiated at the child PCE with 240 the VN. 242 Whenever changes occur with the instantiated LSP in a domain 243 network, the domain child PCE reports the changes using a PCRpt 244 Message in which the VNAG Object indicates the relationship between 245 the LSP and the VN. 247 Whenever an update occurs with VNs in the Parent PCE (via the 248 client's request), the parent PCE sends an PCUpd Message to inform 249 each affected child PCE of this change. 251 6. Security Considerations 253 TDB 255 7. IANA Considerations 257 7.1. Association Object Type Indicator 259 This document defines the following new association type originally 260 defined in [I-D.ietf-pce-association-group]. 262 Value Name Reference 264 TBD1 VN Association Type [This I.D.] 266 7.2. PCEP TLV Type Indicator 268 This document defines the following new PCEP TLV; IANA is requested 269 to make the following allocations from this registry at 270 http://www.iana.org/assignments/pcep/pcep.xhtml; see PCEP TLV Type 271 Indicators. 273 Value Name Reference 275 TBD2 VIRTUAL-NETWORK-TLV [This I.D.] 277 7.3. PCEP Error 279 IANA is requested to make the following allocations from this 280 registry at http://www.iana.org/assignments/pcep/pcep.xhtml; see 281 PCEP-ERROR Object Error Types and Values. 283 This document defines new Error-Type and Error-Value for the 284 following new error conditions: 286 Error-Type Meaning 288 6 Mandatory Object missing 290 Error-value=TBD3: VIRTUAL-NETWORK TLV missing 292 8. References 294 8.1. Normative References 296 [I-D.ietf-pce-stateful-pce] E. Crabbe, I. Minei, J. Medved, and R. 297 Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- 298 stateful-pce, work in progress. 300 [I-D.ietf-pce-pce-initiated-lsp] E. Crabbe, et. al., "PCEP 301 Extensions for PCE-initiated LSP Setup in a Stateful PCE 302 Model", draft-ietf-pce-pce-initiated-lsp, work in 303 progress. 305 [I-D.ietf-pce-association-group] I, Minei, Ed., "PCEP Extensions for 306 Establishing Relationships Between Sets of LSPs", draft- 307 ietf-pce-association-group, work in progress. 309 [I-D.ietf-dhodylee-stateful-HPCE] Dhody, D. and Lee, Y., 310 "Hierarchical Stateful Path Computation Element (PCE)", 311 draft-dhodylee-pce-stateful-hpce, work in progress. 313 8.2. Informative References 315 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 316 Computation Element (PCE)-Based Architecture", RFC 4655, 317 August 2006. 319 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 320 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 321 March 2009. 323 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 324 Element (PCE)-Based Architecture", RFC 4655, August 2006. 326 [RFC6805] A. Farrel and D. King, "The Application of the Path 327 Computation Element Architecture to the Determination of a 328 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 329 2012. 331 [I-D.ietf-pce-stateful-pce-app] Zhang, X., ED, and Minei, I., ED, 332 "Applicability of a Stateful Path Computation Element 333 (PCE)", draft-ietf-pce-stateful-pce-app, work-in-progress. 335 [ACTN-REQ] Y. Lee, D. Dhody, S. Belotti, K. Pithewan, and D. 336 Ceccarelli, "Requirements for Abstraction and Control of 337 TE Networks", draft-ietf-teas-actn-requirements, work in 338 progress. 340 Author's Addresses 342 Young Lee (Editor) 343 Huawei Technologies 344 5340 Legacy Drive, Building 3 345 Plano, TX 75023, USA 347 Email: leeyoung@huawei.com 348 Dhruv Dhody (Editor) 349 Huawei Technologies 350 Divyashree Technopark, Whitefield 351 Bangalore, Karnataka 560037 352 India 354 EMail: dhruv.ietf@gmail.com 356 Daniele Ceccarelli 357 Ericsson 358 Torshamnsgatan,48 359 Stockholm, Sweden 361 EMail: daniele.ceccarelli@ericsson.com 363 Xian Zhang 364 Huawei Technologies 366 Email: zhang.xian@huawei.com