idnits 2.17.1 draft-sivabalan-pce-policy-identifier-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 6, 2015) is 3124 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) == Unused Reference: 'RFC4206' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 258, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-06 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-11 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 S. Sivabalan 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 8, 2016 J. Tantsura 6 Ericsson 7 J. Hardwick 8 Metaswitch Networks 9 October 6, 2015 11 Conveying policies associated with traffic engineering paths over PCEP 12 session 13 draft-sivabalan-pce-policy-identifier-00.txt 15 Abstract 17 This document describes a simple extension to the Path Computation 18 Element (PCE) Communication Protocol (PCEP) using which a PCEP 19 speaker can enforce one or more policies on the other PCEP speaker. 20 A policy is represented by a numeric value which can be interpreted 21 only by the receiving PCEP speaker. Using the proposed extension, a 22 path computation client (PCC) can signal one or more policies that 23 must be taken into consideration by a PCE during path computation. 24 Similarly, when initiating or updating a path, a stateful PCE can 25 signal one or more policies (e.g., traffic steering rules) that a PCC 26 is expected to apply to the path. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 8, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Policy Identifier TLV . . . . . . . . . . . . . . . . . . . . 4 71 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 75 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 81 communication between a Path Computation Client (PCC) and a PCE or 82 between a pair of PCEs. [I-D.ietf-pce-stateful-pce] specifies 83 extension to PCEP that allows a PCC to delegate its LSPs to a PCE. 84 The PCE can then update the state of LSPs delegated to it. 85 [I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE 86 to dynamically instantiate, maintain, and tear down Label Switched 87 Paths (LSPs) without the need for configuring those LSPs on the PCC. 88 Currently, the LSPs can either be signaled via RSVP-TE or can be 89 segment routed as specified in [I-D.ietf-pce-segment-routing]. 91 As described in the next section, a PCEP speaker may want to 92 influence its PCEP counterpart with respect to path selection and 93 other policies. This document describes a PCEP extension to signal 94 policy identifier represented by numeric value using OPTIONAL PCEP 95 TLV. The specification is applicable to both stateful and stateless 96 PCEP sessions. 98 2. Motivation 100 Paths computed using PCEP are subject to various policies on both PCE 101 as well as PCC. For example, in a centralized traffic engineering 102 scenario, network operators may instantiate LSPs and specifies 103 policies for traffic steering, path monitoring, etc., for those LSPs 104 via stateful PCE. Similarly, a PCC can request a path that is 105 diverse from any other path originating from other PCC(s) from a 106 stateful PCE. With a current state of PCEP, introducing such policy 107 requires new PCEP extension. A generic mechanism that allows a PCEP 108 speaker to specify the path policies without the need to know the 109 details of such policies simplifies network operations, avoids 110 frequent software upgrades, as well provides an ability to introduce 111 new policy faster. 113 Policy-ID Y 114 Initiate & Monitor LSP {Disjoint paths} 115 | | 116 | PCReq | 117 V {policy-ID Y} V 118 +-----+ ----------------> +-----+ 119 _ _ _ _ _ _| PCE | | | PCE | 120 | +-----+ | ----------> +-----+ 121 | PCEInitiate | | PCReq 122 |{policy-ID X} | | {policy-ID Y} 123 | | | 124 | .-----. | | .-----. 125 | ( ) | +----+ ( ) 126 | .--( )--. | |PCC1|--.--( )--. 127 V ( ) | +----+ ( ) 128 +---+ ( ) | ( ) 129 |PCC|----( MPLS network ) +----+ ( MPLS network ) 130 +---+ ( ) |PCC2|------( ) 131 Policy ID X ( ) +----+ ( ) 132 {Monitor LSP} '--( )--' '--( )--' 133 ( ) ( ) 134 '-----' '-----' 136 Case 1: Policy initiated by PCE Case 2: Policy initiated by PCC 137 and enforced by PCC and enforced by PCE 139 Figure 1: Sample use-cases for carrying policies over PCEP session 141 3. Terminology 143 The following terminologies are used in this document: 145 LSP: Label Switched Path. 147 PCC: Path Computation Client. 149 PCE: Path Computation Element 151 PCEP: Path Computation Element Protocol. 153 TLV: Type, Length, and Value. 155 4. Policy Identifier TLV 157 The new optional TLV is called "POLICY-ID-TLV" whose format is shown 158 in the diagram below is defined to indicate the policies applied to a 159 path. This TLV is associated with the RP or SRP objects specified 160 in[RFC5440] and [I-D.ietf-pce-stateful-pce] respectively. The type 161 of this TLV is to be allocated by IANA. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type (TBD) | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Flags |M| Policy ID | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 ~ VENDOR-INFORMATION-TLV (optional) ~ 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 2: Format of POLICY-ID-TLV 175 The TLV is formatted according to the rules specified in [RFC5440]. 176 The body of the POLICY-ID-TLV contains one 1-Octet flags and 3-Octet 177 policy identifier. By default, a policy is OPTIONAL. If the M-flag 178 is set, the policy is considered MANDATORY. This TLV can optionally 179 carry vendor-specific information via VENDOR-INFORMATION-TLV whose 180 format and processing rules are specified in [RFC7470]. The presence 181 of VENDOR-INFORMATION-TLV is detected based on the TLV length, and 182 the content and processing rule of vendor-specific information is 183 outside the scope of this specification. 185 5. Operation 187 A single message MAY contain more than one POLICY-ID-TLVs. In case, 188 a a speaker receives a message containing multiple POLICY-ID-TLVs 189 with the same policy ID, it MUST ignore all except for the first one 190 itencounters in the message. If a PCEP speaker does not recognize 191 the TLV, it MUST ignore the TLV in accordance with ([RFC5440]). If a 192 PCEP speaker recognizes the TLV but does not support a mandatory 193 policy included in the message, it MUST ignore the whole message and 194 send PCErr with Error-Type = 2 (Capability not supported) as well 195 include the POLICY-ID-TLV corresponding to the unsupported policies. 197 When requesting a path from a PCE using a PCReq message ([RFC5440]), 198 a PCC MAY include the POLICY-ID-TLV in the RP object. The PCE MUST 199 take into account all the policies included in the PCReq otherwise it 200 MUST ignore the whole message and send PCErr message as mentioned 201 above. 203 In the case of stateful PCE, POLICY-ID-TLV MAY be included in PCReq, 204 PCRpt, PCUpd, and PCInitiate messages as well. When including 205 POLICY-ID-TLV in PCRpt message, the SRP object MUST be present even 206 in cases when the SRP-ID-number is the reserved value of 0x00000000. 208 6. Security Considerations 210 No additional security measure is required. 212 7. IANA Considerations 214 IANA is requested to allocate a new code point in the PCEP TLV Type 215 Indicators registry, as follows: 217 Value Description Reference 219 TBD POLICY-ID-TLV This document 221 8. Acknowledgements 223 9. Normative References 225 [I-D.ietf-pce-pce-initiated-lsp] 226 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 227 Extensions for PCE-initiated LSP Setup in a Stateful PCE 228 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 229 progress), April 2015. 231 [I-D.ietf-pce-segment-routing] 232 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 233 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 234 "PCEP Extensions for Segment Routing", draft-ietf-pce- 235 segment-routing-06 (work in progress), August 2015. 237 [I-D.ietf-pce-stateful-pce] 238 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 239 Extensions for Stateful PCE", draft-ietf-pce-stateful- 240 pce-11 (work in progress), April 2015. 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, 244 DOI 10.17487/RFC2119, March 1997, 245 . 247 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 248 Hierarchy with Generalized Multi-Protocol Label Switching 249 (GMPLS) Traffic Engineering (TE)", RFC 4206, 250 DOI 10.17487/RFC4206, October 2005, 251 . 253 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 254 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 255 DOI 10.17487/RFC5440, March 2009, 256 . 258 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 259 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 260 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 261 2009, . 263 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 264 Constraints in the Path Computation Element Communication 265 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 266 . 268 Authors' Addresses 270 Siva Sivabalan 271 Cisco Systems, Inc. 272 2000 Innovation Drive 273 Kanata, Ontario K2K 3E8 274 Canada 276 Email: msiva@cisco.com 277 Clarence Filsfils 278 Cisco Systems, Inc. 279 Pegasus Parc 280 De kleetlaan 6a, DIEGEM BRABANT 1831 281 BELGIUM 283 Email: cfilsfil@cisco.com 285 Jeff Tantsura 286 Ericsson 287 300 Holger Way 288 San Jose, CA 95134 289 USA 291 Email: jeff.tantsura@ericsson.com 293 Jonathan Hardwick 294 Metaswitch Networks 295 100 Church Street 296 Enfield, Middlesex 297 UK 299 Email: Jonathan.Hardwick@metaswitch.com