idnits 2.17.1 draft-ietf-pce-association-policy-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 (June 29, 2017) is 2493 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-03 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-14 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 Summary: 0 errors (**), 0 flaws (~~), 5 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 5 Expires: December 31, 2017 Cisco Systems, Inc. 6 S. Litkowski 7 Orange 8 J. Tantsura 9 Individual 10 J. Hardwick 11 Metaswitch Networks 12 June 29, 2017 14 Path Computation Element communication Protocol extension for 15 associating Policies and LSPs 16 draft-ietf-pce-association-policy-01 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 December 31, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Association object Type Indicators . . . . . . . . . . . 6 68 8. Manageability Considerations . . . . . . . . . . . . . . . . 7 69 8.1. Control of Function and Policy . . . . . . . . . . . . . 7 70 8.2. Information and Data Models . . . . . . . . . . . . . . . 7 71 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 stateful PCE (active and passive modes) and 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 PAG Y 157 {Service-Specific Policy 158 for constraint 159 Initiate & Monitor LSP relaxation} 160 | | 161 | PAG X PCReq | 162 V {Monitor LSP} {PAG Y} V 163 +-----+ ----------------> +-----+ 164 _ _ _ _ _ _| PCE | | | PCE | 165 | +-----+ | ----------> +-----+ 166 | PCEInitiate | | PCReq 167 |{PAG X} | | {PAG Y} 168 | | | 169 | .-----. | | .-----. 170 | ( ) | +----+ ( ) 171 | .--( )--. | |PCC1|--.--( )--. 172 V ( ) | +----+ ( ) 173 +---+ ( ) | ( ) 174 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 175 +---+ ( ) |PCC2|------( ) 176 PAG X ( ) +----+ ( ) 177 {Monitor LSP} '--( )--' '--( )--' 178 ( ) ( ) 179 '-----' '-----' 181 Case 1: Policy requested by PCE Case 2: Policy requested 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 This Association-Type is operator-configured association in nature 223 and created by the operator manually on the PCEP peers. The LSP 224 belonging to this associations is conveyed via PCEP messages to the 225 PCEP peer. Operator-configured Association Range SHOULD NOT be set 226 for this association-type, and MUST be ignored, so that the full 227 range of association identifier can be utilized. 229 A PAG can have one or more LSPs and its associated policy(s). The 230 association identifier, type (Policy), as well as the association 231 source IP address is manually configured by the operator and is used 232 to identify the PAG. 234 As per the processing rules, as specified in section 5.3 of 235 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 236 this Policy association-type, it MUST return a PCErr message with 237 Error-Type TBD "Association Error" and Error-Value 1 "Association- 238 type is not supported". Since the PAG is opaque in nature, the PAG 239 and the policy MUST be set on the PCEP peers. If a PCE speaker 240 receives PAG in a PCEP message, and the association information is 241 not configured, it MUST return a PCErr message with Error-Type TBD 242 "Association Error" and Error- Value 4 "Association unknown". All 243 other processing is as per section 5.3 of 244 [I-D.ietf-pce-association-group]. 246 5. Policy Association Group 248 Association groups and their memberships are defined using the 249 ASSOCIATION object defined in [I-D.ietf-pce-association-group]. Two 250 object types for IPv4 and IPv6 are defined. The ASSOCIATION object 251 includes "Association type" indicating the type of the association 252 group. This document add a new Association type - 254 Association type = TBD1 ("Policy Association Type") for PAG. 256 PAG may carry optional TLVs including but not limited to - 258 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 259 specific behavioral information, described in [RFC7470]. 261 6. Security Considerations 263 This document defines one new type for association, which do not add 264 any new security concerns beyond those discussed in [RFC5440], 265 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-association-group] in 266 itself. 268 Some deployments may find policy associations and their implications 269 as extra sensitive and thus should employ suitable PCEP security 270 mechanisms like [I-D.ietf-pce-pceps]. 272 7. IANA Considerations 274 7.1. Association object Type Indicators 276 This document defines the following new association type originally 277 defined in [I-D.ietf-pce-association-group]. 279 Value Name Reference 281 TBD1 Policy Association Type [This I.D.] 283 8. Manageability Considerations 285 8.1. Control of Function and Policy 287 An operator MUST BE allowed to configure the policy associations at 288 PCEP peers and associate it with the LSPs. 290 8.2. Information and Data Models 292 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 293 this document. 295 8.3. Liveness Detection and Monitoring 297 Mechanisms defined in this document do not imply any new liveness 298 detection and monitoring requirements in addition to those already 299 listed in [RFC5440]. 301 8.4. Verify Correct Operations 303 Mechanisms defined in this document do not imply any new operation 304 verification requirements in addition to those already listed in 305 [RFC5440]. 307 8.5. Requirements On Other Protocols 309 Mechanisms defined in this document do not imply any new requirements 310 on other protocols. 312 8.6. Impact On Network Operations 314 Mechanisms defined in this document do not have any impact on network 315 operations in addition to those already listed in [RFC5440]. 317 9. Acknowledgments 319 A special thanks to author of [I-D.ietf-pce-association-group], this 320 document borrow some of the text from it. 322 10. References 324 10.1. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 332 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 333 DOI 10.17487/RFC5440, March 2009, 334 . 336 [I-D.ietf-pce-association-group] 337 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 338 Dhody, D., and Y. Tanaka, "PCEP Extensions for 339 Establishing Relationships Between Sets of LSPs", draft- 340 ietf-pce-association-group-03 (work in progress), June 341 2017. 343 [I-D.ietf-pce-stateful-pce] 344 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 345 Extensions for Stateful PCE", draft-ietf-pce-stateful- 346 pce-21 (work in progress), June 2017. 348 10.2. Informative References 350 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 351 Element (PCE)-Based Architecture", RFC 4655, 352 DOI 10.17487/RFC4655, August 2006, 353 . 355 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 356 "Policy-Enabled Path Computation Framework", RFC 5394, 357 DOI 10.17487/RFC5394, December 2008, 358 . 360 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 361 Hardwick, "Path Computation Element Communication Protocol 362 (PCEP) Management Information Base (MIB) Module", 363 RFC 7420, DOI 10.17487/RFC7420, December 2014, 364 . 366 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 367 Constraints in the Path Computation Element Communication 368 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 369 . 371 [I-D.ietf-pce-pceps] 372 Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure 373 Transport for PCEP", draft-ietf-pce-pceps-14 (work in 374 progress), May 2017. 376 [I-D.ietf-pce-pce-initiated-lsp] 377 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 378 Extensions for PCE-initiated LSP Setup in a Stateful PCE 379 Model", draft-ietf-pce-pce-initiated-lsp-10 (work in 380 progress), June 2017. 382 [I-D.ietf-pce-segment-routing] 383 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 384 and J. Hardwick, "PCEP Extensions for Segment Routing", 385 draft-ietf-pce-segment-routing-09 (work in progress), 386 April 2017. 388 Appendix A. Contributor Addresses 390 Qin Wu 391 Huawei Technologies 392 101 Software Avenue, Yuhua District 393 Nanjing, Jiangsu 210012 394 China 396 EMail: sunseawq@huawei.com 398 Clarence Filsfils 399 Cisco Systems, Inc. 400 Pegasus Parc 401 De kleetlaan 6a, DIEGEM BRABANT 1831 402 BELGIUM 404 Email: cfilsfil@cisco.com 406 Xian Zhang 407 Huawei Technologies 408 Bantian, Longgang District 409 Shenzhen 518129 410 P.R.China 412 EMail: zhang.xian@huawei.com 414 Udayasree Palle 415 Huawei Technologies 416 Divyashree Techno Park, Whitefield 417 Bangalore, Karnataka 560066 418 India 420 EMail: udayasreereddy@gmail.com 422 Authors' Addresses 424 Dhruv Dhody (editor) 425 Huawei Technologies 426 Divyashree Techno Park, Whitefield 427 Bangalore, Karnataka 560066 428 India 430 EMail: dhruv.ietf@gmail.com 431 Siva Sivabalan 432 Cisco Systems, Inc. 433 2000 Innovation Drive 434 Kanata, Ontario K2K 3E8 435 Canada 437 EMail: msiva@cisco.com 439 Stephane Litkowski 440 Orange 442 EMail: stephane.litkowski@orange.com 444 Jeff Tantsura 445 Individual 447 EMail: jefftant.ietf@gmail.com 449 Jonathan Hardwick 450 Metaswitch Networks 451 100 Church Street 452 Enfield, Middlesex 453 UK 455 EMail: Jonathan.Hardwick@metaswitch.com