idnits 2.17.1 draft-dhody-pce-association-policy-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 : ---------------------------------------------------------------------------- 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 (October 28, 2016) is 2736 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 (-10) exists of draft-ietf-pce-association-group-01 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-16 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-10 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 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 D. Dhody, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Sivabalan, Ed. 5 Expires: May 1, 2017 Cisco Systems, Inc. 6 S. Litkowski 7 Orange 8 J. Tantsura 9 Individual 10 J. Hardwick 11 Metaswitch Networks 12 October 28, 2016 14 Path Computation Element communication Protocol extension for 15 associating Policies and LSPs 16 draft-dhody-pce-association-policy-00 18 Abstract 20 This document introduces a simple mechanism to associate policies to 21 a group of Label Switched Paths (LSPs) via an extension to the Path 22 Computation Element (PCE) Communication Protocol (PCEP). 24 Status of This Memo 26 This Internet-Draft is submitted 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). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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." 39 This Internet-Draft will expire on May 1, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5 63 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Policy Association Group . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Association object Type Indicators . . . . . . . . . . . 6 68 8. Manageability Considerations . . . . . . . . . . . . . . . . 6 69 8.1. Control of Function and Policy . . . . . . . . . . . . . 6 70 8.2. Information and Data Models . . . . . . . . . . . . . . . 6 71 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 6 72 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7 73 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 7 74 8.6. Impact On Network Operations . . . . . . . . . . . . . . 7 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 10.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 [RFC5440] describes the Path Computation Element communication 85 Protocol (PCEP) which enables the communication between a Path 86 Computation Client (PCC) and a Path Control Element (PCE), or between 87 two PCEs based on the PCE architecture [RFC4655]. 89 PCEP Extensions for Stateful PCE Model [I-D.ietf-pce-stateful-pce] 90 describes a set of extensions to PCEP to enable active control of 91 MPLS-TE and GMPLS tunnels. [I-D.ietf-pce-pce-initiated-lsp] 92 describes the setup and teardown of PCE-initiated LSPs under the 93 active stateful PCE model, without the need for local configuration 94 on the PCC, thus allowing for a dynamic network. Currently, the LSPs 95 can either be signaled via RSVP-TE or can be segment routed as 96 specified in [I-D.ietf-pce-segment-routing]. 98 [I-D.ietf-pce-association-group] introduces a generic mechanism to 99 create a grouping of LSPs which can then be used to define 100 associations between a set of LSPs and a set of attributes (such as 101 configuration parameters or behaviors) and is equally applicable to 102 the active and passive modes of a stateful PCE or a stateless PCE. 104 This document specifies a PCEP extension to associate one or more 105 LSPs with policies using the generic association mechanism. 107 A PCEP speaker may want to influence the PCEP peer with respect to 108 path selection and other policies. This document describes a PCEP 109 extension to associate policies by creating Policy Association Group 110 (PAG) and encoding this association in PCEP messages. The 111 specification is applicable to both stateful and stateless PCEP 112 sessions. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. Terminology 122 The following terminology is used in this document. 124 LSR: Label Switch Router. 126 MPLS: Multiprotocol Label Switching. 128 PAG: Policy Association Group. 130 PCC: Path Computation Client. Any client application requesting a 131 path computation to be performed by a Path Computation Element. 133 PCE: Path Computation Element. An entity (component, application, 134 or network node) that is capable of computing a network path or 135 route based on a network graph and applying computational 136 constraints. 138 PCEP: Path Computation Element Communication Protocol. 140 3. Motivation 142 Paths computed using PCE MAY be subjected to various policies on both 143 PCE and PCC. For example, in a centralized traffic engineering 144 scenario, network operators may instantiate LSPs and specifies 145 policies for traffic steering, path monitoring, etc., for some LSPs 146 via the stateful PCE. Similarly, a PCC may request a user- or 147 service-specific policy to be applied at the PCE, such as constraints 148 relaxation to meet optimal QoS and resiliency. 150 PCEP speaker can use the generic mechanism as per 151 [I-D.ietf-pce-association-group] to associate a set of LSPs with 152 policy, without the need to know the details of such policies, which 153 simplifies network operations, avoids frequent software upgrades, as 154 well provides an ability to introduce new policy faster. 156 Policy-ID Y 157 {Service-Specific Policy 158 for cosntraint 159 Initiate & Monitor LSP relaxation} 160 | | 161 | PCReq | 162 V {policy-ID Y} V 163 +-----+ ----------------> +-----+ 164 _ _ _ _ _ _| PCE | | | PCE | 165 | +-----+ | ----------> +-----+ 166 | PCEInitiate | | PCReq 167 |{policy-ID X} | | {policy-ID Y} 168 | | | 169 | .-----. | | .-----. 170 | ( ) | +----+ ( ) 171 | .--( )--. | |PCC1|--.--( )--. 172 V ( ) | +----+ ( ) 173 +---+ ( ) | ( ) 174 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 175 +---+ ( ) |PCC2|------( ) 176 Policy ID X ( ) +----+ ( ) 177 {Monitor LSP} '--( )--' '--( )--' 178 ( ) ( ) 179 '-----' '-----' 181 Case 1: Policy initiated by PCE Case 2: Policy initiated by 182 and enforced by PCC PCC and enforced by 183 PCE 185 Sample use-cases for carrying policies over PCEP session 187 3.1. Policy based Constraints 189 In the context of policy-enabled path computation [RFC5394], path 190 computation policies may be applied at both a PCC and a PCE. 191 Consider an Label Switch Router (LSR) with a policy enabled PCC, it 192 receives a service request via signaling, including over a Network- 193 Network Interface (NNI) or User Network Interface (UNI) reference 194 point, or receives a configuration request over a management 195 interface to establish a service. The PCC may also apply user- or 196 service-specific policies to decide how the path selection process 197 should be constrained, that is, which constraints, diversities, 198 optimization criterion, and constraint relaxation strategies should 199 be applied in order for the service LSP(s) to have a likelihood to be 200 successfully established and provide necessary QoS and resilience 201 against network failures. The user- or service-specific policies 202 applied to PCC and are then passed to the PCE along with the Path 203 computation request, in the form of constraints [RFC5394]. 205 PCEP speaker can use the generic mechanism as per 206 [I-D.ietf-pce-association-group] to associate a set of LSPs with 207 policy and its resulting path computation constraints. This 208 simplified the path computation message exchanges. 210 4. Overview 212 As per [I-D.ietf-pce-association-group], LSPs are associated with 213 other LSPs with which they interact by adding them to a common 214 association group. Grouping can also be used to define association 215 between LSPs and policies associated to them. One new Association 216 Type is defined in this document, based on the generic Association 217 object - 219 o Association type = TBD1 ("Policy Association Type") for Policy 220 Association Group (PAG) 222 A PAG can have one or more LSPs and its associated policy(s). The 223 Association ID defined in [I-D.ietf-pce-association-group] is used to 224 identify the PAG. 226 5. Policy Association Group 228 Association groups and their memberships are defined using the 229 ASSOCIATION object defined in [I-D.ietf-pce-association-group]. Two 230 object types for IPv4 and IPv6 are defined. The ASSOCIATION object 231 includes "Association type" indicating the type of the association 232 group. This document add a new Association type - 234 Association type = TBD1 ("Policy Association Type") for PAG. 236 PAG may carry optional TLVs including but not limited to - 238 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 239 specific behavioral information, described in [RFC7470]. 241 6. Security Considerations 243 This document defines one new type for association, which do not add 244 any new security concerns beyond those discussed in [RFC5440], 245 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-association-group] in 246 itself. 248 Some deployments may find policy associations and their implications 249 as extra sensitive and thus should employ suitable PCEP security 250 mechanisms like TCP-AO or [I-D.ietf-pce-pceps]. 252 7. IANA Considerations 254 7.1. Association object Type Indicators 256 This document defines the following new association type originally 257 defined in [I-D.ietf-pce-association-group]. 259 Value Name Reference 261 TBD1 Policy Association Type [This I.D.] 263 8. Manageability Considerations 265 8.1. Control of Function and Policy 267 An operator MUST BE allowed to configure the policy associations at 268 PCEP peers and associate it with the LSPs. 270 8.2. Information and Data Models 272 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 273 this document. 275 8.3. Liveness Detection and Monitoring 277 Mechanisms defined in this document do not imply any new liveness 278 detection and monitoring requirements in addition to those already 279 listed in [RFC5440]. 281 8.4. Verify Correct Operations 283 Mechanisms defined in this document do not imply any new operation 284 verification requirements in addition to those already listed in 285 [RFC5440]. 287 8.5. Requirements On Other Protocols 289 Mechanisms defined in this document do not imply any new requirements 290 on other protocols. 292 8.6. Impact On Network Operations 294 Mechanisms defined in this document do not have any impact on network 295 operations in addition to those already listed in [RFC5440]. 297 9. Acknowledgments 299 A special thanks to author of [I-D.ietf-pce-association-group], this 300 document borrow some of the text from it. 302 10. References 304 10.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 312 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 313 DOI 10.17487/RFC5440, March 2009, 314 . 316 [I-D.ietf-pce-association-group] 317 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 318 Zhang, X., and Y. Tanaka, "PCEP Extensions for 319 Establishing Relationships Between Sets of LSPs", draft- 320 ietf-pce-association-group-01 (work in progress), July 321 2016. 323 [I-D.ietf-pce-stateful-pce] 324 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 325 Extensions for Stateful PCE", draft-ietf-pce-stateful- 326 pce-16 (work in progress), September 2016. 328 10.2. Informative References 330 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 331 Element (PCE)-Based Architecture", RFC 4655, 332 DOI 10.17487/RFC4655, August 2006, 333 . 335 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 336 "Policy-Enabled Path Computation Framework", RFC 5394, 337 DOI 10.17487/RFC5394, December 2008, 338 . 340 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 341 Hardwick, "Path Computation Element Communication Protocol 342 (PCEP) Management Information Base (MIB) Module", 343 RFC 7420, DOI 10.17487/RFC7420, December 2014, 344 . 346 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 347 Constraints in the Path Computation Element Communication 348 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 349 . 351 [I-D.ietf-pce-pceps] 352 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 353 Transport for PCEP", draft-ietf-pce-pceps-10 (work in 354 progress), July 2016. 356 [I-D.ietf-pce-pce-initiated-lsp] 357 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 358 Extensions for PCE-initiated LSP Setup in a Stateful PCE 359 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 360 progress), July 2016. 362 [I-D.ietf-pce-segment-routing] 363 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 364 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 365 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 366 ietf-pce-segment-routing-08 (work in progress), October 367 2016. 369 Appendix A. Contributor Addresses 371 Qin Wu 372 Huawei Technologies 373 101 Software Avenue, Yuhua District 374 Nanjing, Jiangsu 210012 375 China 377 EMail: sunseawq@huawei.com 379 Clarence Filsfils 380 Cisco Systems, Inc. 381 Pegasus Parc 382 De kleetlaan 6a, DIEGEM BRABANT 1831 383 BELGIUM 385 Email: cfilsfil@cisco.com 387 Xian Zhang 388 Huawei Technologies 389 Bantian, Longgang District 390 Shenzhen 518129 391 P.R.China 393 EMail: zhang.xian@huawei.com 395 Udayasree Palle 396 Huawei Technologies 397 Divyashree Techno Park, Whitefield 398 Bangalore, Karnataka 560066 399 India 401 EMail: udayasree.palle@huawei.com 403 Authors' Addresses 405 Dhruv Dhody (editor) 406 Huawei Technologies 407 Divyashree Techno Park, Whitefield 408 Bangalore, Karnataka 560066 409 India 411 EMail: dhruv.ietf@gmail.com 412 Siva Sivabalan (editor) 413 Cisco Systems, Inc. 414 2000 Innovation Drive 415 Kanata, Ontario K2K 3E8 416 Canada 418 EMail: msiva@cisco.com 420 Stephane Litkowski 421 Orange 423 EMail: stephane.litkowski@orange.com 425 Jeff Tantsura 426 Individual 428 EMail: jefftant.ietf@gmail.com 430 Jonathan Hardwick 431 Metaswitch Networks 432 100 Church Street 433 Enfield, Middlesex 434 UK 436 EMail: Jonathan.Hardwick@metaswitch.com