idnits 2.17.1 draft-ietf-pce-association-policy-03.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 19, 2018) is 2139 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-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-07 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 D. Dhody, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Sivabalan 5 Expires: December 21, 2018 Cisco Systems, Inc. 6 S. Litkowski 7 Orange 8 J. Tantsura 9 Individual 10 J. Hardwick 11 Metaswitch Networks 12 June 19, 2018 14 Path Computation Element communication Protocol extension for 15 associating Policies and LSPs 16 draft-ietf-pce-association-policy-03 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 https://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 21, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Policy based Constraints . . . . . . . . . . . . . . . . 5 63 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Policy Association Group . . . . . . . . . . . . . . . . . . 7 65 5.1. Policy Parameters TLV . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Association object Type Indicators . . . . . . . . . . . 9 69 7.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 9 70 8. Manageability Considerations . . . . . . . . . . . . . . . . 9 71 8.1. Control of Function and Policy . . . . . . . . . . . . . 9 72 8.2. Information and Data Models . . . . . . . . . . . . . . . 9 73 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 74 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 75 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 76 8.6. Impact On Network Operations . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 [RFC5440] describes the Path Computation Element communication 87 Protocol (PCEP) which enables the communication between a Path 88 Computation Client (PCC) and a Path Control Element (PCE), or between 89 two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides 90 additional details on policy within the PCE architecture and also 91 provides context for the support of PCE Policy. 93 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 94 extensions to PCEP to enable active control of Multiprotocol Label 95 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 96 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 97 LSPs under the active stateful PCE model, without the need for local 98 configuration on the PCC, thus allowing for a dynamic network. 99 Currently, the LSPs can either be signaled via Resource Reservation 100 Protocol Traffic Engineering (RSVP-TE) or can be segment routed as 101 specified in [I-D.ietf-pce-segment-routing]. 103 [I-D.ietf-pce-association-group] introduces a generic mechanism to 104 create a grouping of LSPs which can then be used to define 105 associations between a set of LSPs and a set of attributes (such as 106 configuration parameters or behaviors) and is equally applicable to 107 stateful PCE (active and passive modes) and stateless PCE. 109 This document specifies a PCEP extension to associate one or more 110 LSPs with policies using the generic association mechanism. 112 A PCEP speaker may want to influence the PCEP peer with respect to 113 path selection and other policies. This document describes a PCEP 114 extension to associate policies by creating Policy Association Group 115 (PAG) and encoding this association in PCEP messages. The 116 specification is applicable to both stateful and stateless PCEP 117 sessions. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Terminology 129 The following terminology is used in this document. 131 Association parameters: As described in 132 [I-D.ietf-pce-association-group], the combination of the mandatory 133 fields Association type, Association ID and Association Source in 134 the ASSOCIATION object uniquely identify the association group. 135 If the optional TLVs - Global Association Source or Extended 136 Association ID are included, then they are included in combination 137 with mandatory fields to uniquely identifying the association 138 group. 140 Association information: As described in 141 [I-D.ietf-pce-association-group], the ASSOCIATION object could 142 include other optional TLVs based on the association types, that 143 provides 'information' related to the association. 145 LSR: Label Switch Router. 147 LSR: Label Switch Router. 149 MPLS: Multiprotocol Label Switching. 151 PAG: Policy Association Group. 153 PCC: Path Computation Client. Any client application requesting a 154 path computation to be performed by a Path Computation Element. 156 PCE: Path Computation Element. An entity (component, application, 157 or network node) that is capable of computing a network path or 158 route based on a network graph and applying computational 159 constraints. 161 PCEP: Path Computation Element Communication Protocol. 163 3. Motivation 165 Paths computed using PCE can be subjected to various policies on both 166 PCE and PCC. For example, in a centralized traffic engineering 167 scenario, network operators may instantiate LSPs and specifies 168 policies for traffic steering, path monitoring, etc., for some LSPs 169 via the stateful PCE. Similarly, a PCC could request a user- or 170 service-specific policy to be applied at the PCE, such as constraints 171 relaxation to meet optimal QoS and resiliency. 173 PCEP speaker can use the generic mechanism as per 174 [I-D.ietf-pce-association-group] to associate a set of LSPs with a 175 policy, without the need to know the details of such a policy, which 176 simplifies network operations, avoids frequent software upgrades, as 177 well provides an ability to introduce new policy faster. 179 PAG Y 180 {Service-Specific Policy 181 for constraint 182 Initiate & Monitor LSP relaxation} 183 | | 184 | PAG X PCReq | 185 V {Monitor LSP} {PAG Y} V 186 +-----+ ----------------> +-----+ 187 _ _ _ _ _ _| PCE | | | PCE | 188 | +-----+ | ----------> +-----+ 189 | PCEInitiate | | PCReq 190 |{PAG X} | | {PAG Y} 191 | | | 192 | .-----. | | .-----. 193 | ( ) | +----+ ( ) 194 | .--( )--. | |PCC1|--.--( )--. 195 V ( ) | +----+ ( ) 196 +---+ ( ) | ( ) 197 |PCC|----( (G)MPLS network ) +----+ ( (G)MPLS network ) 198 +---+ ( ) |PCC2|------( ) 199 PAG X ( ) +----+ ( ) 200 {Monitor LSP} '--( )--' '--( )--' 201 ( ) ( ) 202 '-----' '-----' 204 Case 1: Policy requested by PCE Case 2: Policy requested by 205 and enforced by PCC PCC and enforced by 206 PCE 208 Figure 1: Sample use-cases for carrying policies over PCEP session 210 3.1. Policy based Constraints 212 In the context of policy-enabled path computation [RFC5394], path 213 computation policies may be applied at both a PCC and a PCE. 214 Consider an Label Switch Router (LSR) with a policy enabled PCC, it 215 receives a service request via signaling, including over a Network- 216 Network Interface (NNI) or User Network Interface (UNI) reference 217 point, or receives a configuration request over a management 218 interface to establish a service. The PCC may also apply user- or 219 service-specific policies to decide how the path selection process 220 should be constrained, that is, which constraints, diversities, 221 optimization criterion, and constraint relaxation strategies should 222 be applied in order for the service LSP(s) to have a likelihood to be 223 successfully established and provide necessary QoS and resilience 224 against network failures. The user- or service-specific policies 225 applied to PCC and are then passed to the PCE along with the Path 226 computation request, in the form of constraints [RFC5394]. 228 PCEP speaker can use the generic mechanism as per 229 [I-D.ietf-pce-association-group] to associate a set of LSPs with 230 policy and its resulting path computation constraints. This would 231 simplify the path computation message exchanges in PCEP. 233 4. Overview 235 As per [I-D.ietf-pce-association-group], LSPs are associated with 236 other LSPs with which they interact by adding them to a common 237 association group. Grouping can also be used to define association 238 between LSPs and policies associated to them. One new Association 239 Type is defined in this document, based on the generic Association 240 object - 242 o Association type = TBD1 ("Policy Association Type") for Policy 243 Association Group (PAG) 245 [I-D.ietf-pce-association-group] specify the mechanism for the 246 capability advertisement of the association types supported by a PCEP 247 speaker by defining a ASSOC-Type-List TLV to be carried within an 248 OPEN object. This capability exchange for the association type 249 described in this document (i.e. Policy Association Type) MUST be 250 done before using the policy association. Thus the PCEP speaker MUST 251 include the Policy Association Type (TBD1) in the ASSOC-Type-List TLV 252 before using the PAG in the PCEP messages. 254 This Association-Type is operator-configured association in nature 255 and created by the operator manually on the PCEP peers. The LSP 256 belonging to this associations is conveyed via PCEP messages to the 257 PCEP peer. Operator-configured Association Range SHOULD NOT be set 258 for this association-type, and MUST be ignored, so that the full 259 range of association identifier can be utilized. 261 A PAG can have one or more LSPs and its associated policy. The 262 association parameters including association identifier, type 263 (Policy), as well as the association source IP address is manually 264 configured by the operator and is used to identify the PAG as 265 described in [I-D.ietf-pce-association-group]. The Global 266 Association Source and Extended Association ID MAY also be included. 268 As per the processing rules specified in section 5.4 of 269 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 270 this Policy association-type, it would return a PCErr message with 271 Error-Type 26 (Early allocation by IANA) "Association Error" and 272 Error-Value 1 "Association-type is not supported". Since the PAG is 273 opaque in nature, the PAG and the policy MUST be configured on the 274 PCEP peers as per the operator-configured association procedures. 275 All processing is as per section 5.4 of 276 [I-D.ietf-pce-association-group]. If a PCE speaker receives PAG in a 277 PCEP message, and the policy association information is not 278 configured, it MUST return a PCErr message with Error-Type TBD 279 "Association Error" and Error- Value 4 "Association unknown". If 280 some of the association information [I-D.ietf-pce-association-group] 281 (the TLVs defined in this document) received from the peer does not 282 match the local configured values, the PCEP speaker MUST reject the 283 PCEP message and send a PCErr message with Error-Type 26 (Early 284 allocation by IANA) "Association Error" and Error-Value 5 "Operator- 285 configured association information mismatch". 287 5. Policy Association Group 289 Association groups and their memberships are defined using the 290 ASSOCIATION object defined in [I-D.ietf-pce-association-group]. Two 291 object types for IPv4 and IPv6 are defined. The ASSOCIATION object 292 includes "Association type" indicating the type of the association 293 group. This document add a new Association type - 295 Association type = TBD1 ("Policy Association Type") for PAG. 297 PAG may carry optional TLVs including but not limited to - 299 o POLICY-PARAMETERS-TLV: Used to communicate opaque information 300 useful to apply the policy, described in Section 5.1. 302 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 303 specific behavioral information, described in [RFC7470]. 305 5.1. Policy Parameters TLV 307 The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in 308 ASSOCIATION object (with "Policy Association Type") to carry opaque 309 information needed to apply the policy at the PCEP peer. In some 310 cases to apply a PCE policy successfully, it is required to also 311 associate some policy parameters that needs to be evaluated to 312 successfully apply the said policy. This TLV is used to carry those 313 policy parameters. The TLV could include one or more policy related 314 parameter. The encoding format and the order MUST be known to the 315 PCEP peers, this could be done during configuration of policy (and 316 its association parameters) for the PAG. The TLV format is as per 317 the format of the PCEP TLVs, as defined in [RFC5440], and shown in 318 Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and only the 319 first occurrence is processed and any others MUST be ignored. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type=TBD2 | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 // Policy Parameters // 328 | | 329 +---------------------------------------------------------------+ 331 Figure 2: The POLICY-PARAMETERS-TLV format 333 The type of the POLICY-PARAMETERS-TLV is TBD2 and it has a variable 334 length. The Value field is variable field padded to a 4-bytes 335 alignment; padding is not included in the Length field. The PCEP 336 peer implementation need to be aware of the encoding format, order, 337 and meaning of the 'Policy Parameters' well in advance based on the 338 policy. Note that from the protocol point of view this data is 339 opaque and can be used to carry parameters in any format understood 340 by the PCEP peers and associated to the policy. The exact use of 341 this TLV is beyond the scope of this document. 343 If the PCEP peer is unaware of the policy parameters associated with 344 the policy and it receives the POLICY-PARAMETERS-TLV, it MUST ignore 345 the TLV and SHOULD log this event. Further, if one or more 346 parameters received in the POLICY-PARAMETERS-TLV received by the PCEP 347 speaker are considered as unacceptable in the context of the 348 associated policy (e.g. out of range value, badly encoded value...), 349 the PCEP speaker MUST NOT apply the received policy and SHOULD log 350 this event. 352 Note that, the vendor specific behavioral information is encoded in 353 VENDOR-INFORMATION-TLV which can be used along with this TLV. 355 6. Security Considerations 357 This document defines one new type for association, which do not add 358 any new security concerns beyond those discussed in [RFC5440], 359 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 361 Some deployments may find policy associations and their implications 362 as extra sensitive and thus should employ suitable PCEP security 363 mechanisms like [RFC8253]. Also extra care needs to be taken by the 364 implementation with respect to POLICY-PARAMETERS-TLV while decoding, 365 verifying and applying these policy variables. 367 7. IANA Considerations 369 7.1. Association object Type Indicators 371 This document defines the following new association type originally 372 defined in [I-D.ietf-pce-association-group]. 374 Value Name Reference 376 TBD1 Policy Association Type [This I.D.] 378 7.2. PCEP TLV Type Indicators 380 The following TLV Type Indicator values are requested within the 381 "PCEP TLV Type Indicators" subregistry of the "Path Computation 382 Element Protocol (PCEP) Numbers" registry: 384 Value Description Reference 386 TBD2 POLICY-PARAMETERS-TLV [This I.D.] 388 8. Manageability Considerations 390 8.1. Control of Function and Policy 392 An operator MUST be allowed to configure the policy associations at 393 PCEP peers and associate it with the LSPs. They MAY also allow 394 configuration to related policy parameters, in which case the an 395 operator MUST also be allowed to set the encoding format and order to 396 parse the associated policy parameters TLV. 398 8.2. Information and Data Models 400 An implementation SHOULD allow the operator to view the PAG 401 configured. Further implementation SHOULD allow to view the current 402 set of LSPs in the PAG. To serve this purpose, the PCEP YANG module 403 [I-D.ietf-pce-pcep-yang] includes association groups and can be used 404 for PAG. 406 8.3. Liveness Detection and Monitoring 408 Mechanisms defined in this document do not imply any new liveness 409 detection and monitoring requirements in addition to those already 410 listed in [RFC5440]. 412 8.4. Verify Correct Operations 414 Mechanisms defined in this document do not imply any new operation 415 verification requirements in addition to those already listed in 416 [RFC5440]. 418 8.5. Requirements On Other Protocols 420 Mechanisms defined in this document do not imply any new requirements 421 on other protocols. 423 8.6. Impact On Network Operations 425 Mechanisms defined in this document do not have any impact on network 426 operations in addition to those already listed in [RFC5440]. 428 9. Acknowledgments 430 A special thanks to author of [I-D.ietf-pce-association-group], this 431 document borrow some of the text from it. 433 10. References 435 10.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 443 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 444 DOI 10.17487/RFC5440, March 2009, 445 . 447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 449 May 2017, . 451 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 452 Computation Element Communication Protocol (PCEP) 453 Extensions for Stateful PCE", RFC 8231, 454 DOI 10.17487/RFC8231, September 2017, 455 . 457 [I-D.ietf-pce-association-group] 458 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 459 Dhody, D., and Y. Tanaka, "PCEP Extensions for 460 Establishing Relationships Between Sets of LSPs", draft- 461 ietf-pce-association-group-06 (work in progress), June 462 2018. 464 10.2. Informative References 466 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 467 Element (PCE)-Based Architecture", RFC 4655, 468 DOI 10.17487/RFC4655, August 2006, 469 . 471 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 472 "Policy-Enabled Path Computation Framework", RFC 5394, 473 DOI 10.17487/RFC5394, December 2008, 474 . 476 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 477 Constraints in the Path Computation Element Communication 478 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 479 . 481 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 482 "PCEPS: Usage of TLS to Provide a Secure Transport for the 483 Path Computation Element Communication Protocol (PCEP)", 484 RFC 8253, DOI 10.17487/RFC8253, October 2017, 485 . 487 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 488 Computation Element Communication Protocol (PCEP) 489 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 490 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 491 . 493 [I-D.ietf-pce-segment-routing] 494 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 495 and J. Hardwick, "PCEP Extensions for Segment Routing", 496 draft-ietf-pce-segment-routing-11 (work in progress), 497 November 2017. 499 [I-D.ietf-pce-pcep-yang] 500 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 501 YANG Data Model for Path Computation Element 502 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 503 yang-07 (work in progress), March 2018. 505 Appendix A. Contributor Addresses 507 Qin Wu 508 Huawei Technologies 509 101 Software Avenue, Yuhua District 510 Nanjing, Jiangsu 210012 511 China 513 EMail: sunseawq@huawei.com 515 Clarence Filsfils 516 Cisco Systems, Inc. 517 Pegasus Parc 518 De kleetlaan 6a, DIEGEM BRABANT 1831 519 BELGIUM 521 Email: cfilsfil@cisco.com 523 Xian Zhang 524 Huawei Technologies 525 Bantian, Longgang District 526 Shenzhen 518129 527 P.R.China 529 EMail: zhang.xian@huawei.com 531 Udayasree Palle 532 Huawei Technologies 533 Divyashree Techno Park, Whitefield 534 Bangalore, Karnataka 560066 535 India 537 EMail: udayasreereddy@gmail.com 539 Authors' Addresses 541 Dhruv Dhody (editor) 542 Huawei Technologies 543 Divyashree Techno Park, Whitefield 544 Bangalore, Karnataka 560066 545 India 547 EMail: dhruv.ietf@gmail.com 548 Siva Sivabalan 549 Cisco Systems, Inc. 550 2000 Innovation Drive 551 Kanata, Ontario K2K 3E8 552 Canada 554 EMail: msiva@cisco.com 556 Stephane Litkowski 557 Orange 559 EMail: stephane.litkowski@orange.com 561 Jeff Tantsura 562 Individual 564 EMail: jefftant.ietf@gmail.com 566 Jonathan Hardwick 567 Metaswitch Networks 568 100 Church Street 569 Enfield, Middlesex 570 UK 572 EMail: Jonathan.Hardwick@metaswitch.com