idnits 2.17.1 draft-dhody-pce-association-attr-06.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 (March 12, 2017) is 2602 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-02 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-11 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-requirements-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-association-policy-00 == Outdated reference: A later version (-08) exists of draft-leedhody-pce-vn-association-01 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 13, 2017 March 12, 2017 7 Path Computation Element communication Protocol extension for 8 relationship between LSPs and Attributes 9 draft-dhody-pce-association-attr-06 11 Abstract 13 The Path Computation Element (PCE) provides functions of path 14 computation in support of traffic engineering in networks controlled 15 by Multi-Protocol Label Switching (MPLS) and Generalized MPLS 16 (GMPLS). 18 This document defines a mechanism to create associations between a 19 set of LSPs and a set of attributes (such as configuration 20 parameters). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 13, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Opaque Identifier . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Bundled requests . . . . . . . . . . . . . . . . . . . . 4 62 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Attribute Association Group . . . . . . . . . . . . . . . . . 5 64 5.1. ATTRIBUTE-OBJECT-TLV . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Association object Type Indicators . . . . . . . . . . . 8 68 7.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8 69 7.3. Flag field in ATTRIBUTE-OBJECT-TLV . . . . . . . . . . . 8 70 8. Manageability Considerations . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 9 75 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 76 8.6. Impact On Network Operations . . . . . . . . . . . . . . 9 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 10.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Appendix A. Policy . . . . . . . . . . . . . . . . . . . . . . . 12 82 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 [RFC5440] describes the Path Computation Element communication 88 Protocol (PCEP) which enables the communication between a Path 89 Computation Client (PCC) and a Path Control Element (PCE), or between 90 two PCEs based on the PCE architecture [RFC4655]. 92 [I-D.ietf-pce-association-group] introduces a generic mechanism to 93 create a grouping of LSPs which can then be used to define 94 associations between a set of LSPs and a set of attributes (such as 95 configuration parameters) and is equally applicable to the active and 96 passive modes of a stateful PCE and a stateless PCE. 98 This document specifies a PCEP extension to associate one or more 99 LSPs with a set of attributes. 101 PCEP Extensions for Stateful PCE Model [I-D.ietf-pce-stateful-pce] 102 describes a set of extensions to PCEP to enable active control of 103 MPLS-TE and GMPLS tunnels. [I-D.ietf-pce-pce-initiated-lsp] 104 describes the setup and teardown of PCE-initiated LSPs under the 105 active stateful PCE model, without the need for local configuration 106 on the PCC, thus allowing for a dynamic network. The mechanism 107 described in this document is equally applicable to these deployment 108 models. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Terminology 118 The following terminology is used in this document. 120 AAG: Attribute Association Group. 122 LSR: Label Switch Router. 124 MPLS: Multi-protocol Label Switching. 126 PAG: Policy Association Group. 128 PCC: Path Computation Client. Any client application requesting a 129 path computation to be performed by a Path Computation Element. 131 PCE: Path Computation Element. An entity (component, application, 132 or network node) that is capable of computing a network path or 133 route based on a network graph and applying computational 134 constraints. 136 PCEP: Path Computation Element Communication Protocol. 138 3. Motivation 140 This section discusses in more detail the motivation and use cases 141 for such an association including but not limited to - 143 3.1. Opaque Identifier 145 An opaque identifier may represent attributes such as configured 146 parameters or constraints that a PCEP speaker may invoke on a peer. 147 Thus a PCEP speaker may only need an opaque identifier to invoke 148 these attributes (parameters or constraints) rather than encoding 149 them explicitly in each PCEP message. 151 This can also be used for tagging bunch of LSP to a particular 152 customer or for creation of virtual network like in case of 153 Abstraction and Control of TE Networks (ACTN) 154 [I-D.ietf-teas-actn-requirements]. (See 155 [I-D.leedhody-pce-vn-association]) 157 3.2. Bundled requests 159 In some scenarios(e.g.,the topology example described in Section 4.6 160 of [RFC6805]), there is a need to send multiple requests with the 161 same constraints and attributes to the PCE. Currently these requests 162 are either sent in a separate path computation request (PCReq) 163 messages or bundled together in one (or more) PCReq messages. In 164 either case, the constraints and attributes need to be encoded 165 separately for each request even though they are exactly identical. 167 If a association is used to identify these constraints and attributes 168 shared by multiple requests and grouped together via association 169 mechanism, thus simplifying the path computation message exchanges. 171 4. Overview 173 As per [I-D.ietf-pce-association-group], LSPs are associated with 174 other LSPs with which they interact by adding them to a common 175 association group. This grouping can then be used to define 176 associations between sets of LSPs or between a set of LSPs and a set 177 of attributes (such as configuration parameters). A new optional 178 Association Object-type is defined based on the generic Association 179 object - 181 o Attribute Association Group (AAG) 183 Thus this document defines a new association type called "Attribute 184 Association Type" of value TBD1. An AAG can have one or more LSPs 185 and its associated attributes. The scope and handling of AAG 186 identifier is similar to the generic association identifier defined 187 in [I-D.ietf-pce-association-group]. 189 One or more LSP are grouped via a single group identifier as defined 190 in [I-D.ietf-pce-association-group]. The attributes that may be 191 associated with this set of LSPs may either are - 193 o known to the PCEP peers via some external means like 194 configuration, policy enforcement etc (can be considered as 'out- 195 of-band'). PCEP speaker simply use the AAG identifier in the PCEP 196 message and the peer is supposed to be aware of the associated 197 attributes. This is suitable for stateless PCE where the PCEP 198 peers should be aware of the association and its significance 199 outside of the protocol. 201 o or communicated to the PCEP peer via PCEP itself on first use (can 202 be considered as 'in-band'). PCEP speaker creates a new AAG by 203 using a new identifier and the associated attributes are 204 communicated via TLVs in association object. This is applicable 205 for stateful PCE only. 207 Error handling would be taken up in future revision. 209 5. Attribute Association Group 211 The format of the generic Association object used for AAG is shown in 212 Figure 1: 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Reserved | Flags |R| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Association type (TBD1) | Association ID | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | IPv4 Association Source | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 // Optional TLVs // 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Reserved | Flags |R| 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Association type (TBD1) | Association ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 | IPv6 Association Source | 235 | | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 // Optional TLVs // 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 1: The AAG Object formats 243 Type = TBD1 for the Attribute Association Type. 245 AAG may carry optional TLVs including but not limited to - 247 o ATTRIBUTE-OBJECT-TLV: Used to communicate associated attributes in 248 form of PCEP objects, described in this document. 250 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary behavioral 251 information, described in [RFC7470]. 253 5.1. ATTRIBUTE-OBJECT-TLV 255 The ATTRIBUTE-OBJECT-TLV(s) maybe included in AAG object to associate 256 attributes encoded in PCEP objects. 258 The format of the ATTRIBUTE-OBJECT-TLV is shown in the following 259 figure: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type (TBD2) | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Flags |M|R| 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Object-Class | OT |Res|P|I| Object Length (bytes) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 // (Object body) // 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 2: ATTRIBUTE-OBJECT-TLV format 277 The type of the TLV is TBD2 and it has a variable length. The value 278 part consist of a 32-bit Flag filed followed by a PCEP object 279 (including common header [RFC5440] identifying the object) that is 280 associated with this AAG. 282 Following Flags are defined: 284 R (Remove - 1 bit): This is set to indicate that the attribute is 285 being removed from the attribute-list. 287 M (Modify - 1 bit): This is set to indicate that a previous 288 attribute is being modified, and the peer should overwrite the 289 attribute with the new value as per the object-body. 291 This TLV identifies the attributes associated with this group. For 292 each attribute a separate TLV is used. Future PCEP message exchanges 293 may only carry the AAG with no ATTRIBUTE-OBJECT-TLV. 295 6. Security Considerations 297 This document defines a new types for association and a new 298 ATTRIBUTE-OBJECT-TLV which do not add any new security concerns 299 beyond those discussed in [RFC5440], [I-D.ietf-pce-stateful-pce] and 300 [I-D.ietf-pce-association-group] in itself. 302 Some deployments may find the associations and their implications as 303 extra sensitive and thus should employ suitable PCEP security 304 mechanisms like TCP-AO or [I-D.ietf-pce-pceps]. 306 7. IANA Considerations 308 7.1. Association object Type Indicators 310 This document defines the following new association type originally 311 defined in [I-D.ietf-pce-association-group]. 313 Value Name Reference 314 TBD1 Attribute Association Type [This I.D.] 316 7.2. PCEP TLV Type Indicators 318 This document defines the following new PCEP TLV; IANA is requested 319 to make the following allocations from this registry. 320 http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- 321 indicators 323 Value Name Reference 324 TBD2 ATTRIBUTE-OBJECT-TLV [This I.D.] 326 7.3. Flag field in ATTRIBUTE-OBJECT-TLV 328 This document requests that a new sub-registry, named "ATTRIBUTE- 329 OBJECT-TLV Flag Field", is created within the "Path Computation 330 Element Protocol (PCEP) Numbers" registry to manage the Flag field of 331 the ATTRIBUTE-OBJECT-TLV. New values are to be assigned by Standards 332 Action [RFC5226]. Each bit should be tracked with the following 333 qualities: 335 o Bit number (counting from bit 0 as the most significant bit) 337 o Capability description 339 o Defining RFC 341 The following values are defined in this document: 343 Bit Description Reference 344 31 Remove [This I.D.] 345 30 Modify [This I.D.] 347 8. Manageability Considerations 348 8.1. Control of Function and Policy 350 An operator MUST BE allowed to configure the attribute associations 351 at PCEP peers and associate it with the LSPs. 353 8.2. Information and Data Models 355 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 356 this document. 358 8.3. Liveness Detection and Monitoring 360 Mechanisms defined in this document do not imply any new liveness 361 detection and monitoring requirements in addition to those already 362 listed in [RFC5440]. 364 8.4. Verify Correct Operations 366 Mechanisms defined in this document do not imply any new operation 367 verification requirements in addition to those already listed in 368 [RFC5440]. 370 8.5. Requirements On Other Protocols 372 Mechanisms defined in this document do not imply any new requirements 373 on other protocols. 375 8.6. Impact On Network Operations 377 Mechanisms defined in this document do not have any impact on network 378 operations in addition to those already listed in [RFC5440]. 380 9. Acknowledgments 382 A special thanks to author of [I-D.ietf-pce-association-group], this 383 document borrow some of the text from it. 385 10. References 387 10.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 395 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 396 DOI 10.17487/RFC5440, March 2009, 397 . 399 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 400 Constraints in the Path Computation Element Communication 401 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 402 . 404 [I-D.ietf-pce-association-group] 405 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 406 Zhang, X., and Y. Tanaka, "PCEP Extensions for 407 Establishing Relationships Between Sets of LSPs", draft- 408 ietf-pce-association-group-02 (work in progress), January 409 2017. 411 [I-D.ietf-pce-stateful-pce] 412 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 413 Extensions for Stateful PCE", draft-ietf-pce-stateful- 414 pce-18 (work in progress), December 2016. 416 10.2. Informative References 418 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 419 Element (PCE)-Based Architecture", RFC 4655, 420 DOI 10.17487/RFC4655, August 2006, 421 . 423 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 424 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 425 DOI 10.17487/RFC5226, May 2008, 426 . 428 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 429 Path Computation Element Architecture to the Determination 430 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 431 DOI 10.17487/RFC6805, November 2012, 432 . 434 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 435 Hardwick, "Path Computation Element Communication Protocol 436 (PCEP) Management Information Base (MIB) Module", 437 RFC 7420, DOI 10.17487/RFC7420, December 2014, 438 . 440 [I-D.ietf-pce-pceps] 441 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 442 Transport for PCEP", draft-ietf-pce-pceps-11 (work in 443 progress), January 2017. 445 [I-D.ietf-pce-pce-initiated-lsp] 446 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 447 Extensions for PCE-initiated LSP Setup in a Stateful PCE 448 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 449 progress), March 2017. 451 [I-D.ietf-teas-actn-requirements] 452 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 453 Ceccarelli, "Requirements for Abstraction and Control of 454 TE Networks", draft-ietf-teas-actn-requirements-04 (work 455 in progress), January 2017. 457 [I-D.ietf-pce-association-policy] 458 Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and 459 J. Hardwick, "Path Computation Element communication 460 Protocol extension for associating Policies and LSPs", 461 draft-ietf-pce-association-policy-00 (work in progress), 462 December 2016. 464 [I-D.leedhody-pce-vn-association] 465 Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP 466 Extensions for Establishing Relationships Between Sets of 467 LSPs and Virtual Networks", draft-leedhody-pce-vn- 468 association-01 (work in progress), October 2016. 470 Appendix A. Policy 472 An earlier version of this document also had details about Policy 473 association group. This has been moved to an independent document - 474 [I-D.ietf-pce-association-policy]. 476 Appendix B. Contributor Addresses 478 Xian Zhang 479 Huawei Technologies 480 Bantian, Longgang District 481 Shenzhen 518129 482 P.R.China 484 EMail: zhang.xian@huawei.com 486 Udayasree Palle 487 Huawei Technologies 488 Divyashree Techno Park, Whitefield 489 Bangalore, Karnataka 560066 490 India 492 EMail: udayasree.palle@huawei.com 494 Authors' Addresses 496 Dhruv Dhody 497 Huawei Technologies 498 Divyashree Techno Park, Whitefield 499 Bangalore, Karnataka 560066 500 India 502 EMail: dhruv.ietf@gmail.com 504 Qin Wu 505 Huawei Technologies 506 101 Software Avenue, Yuhua District 507 Nanjing, Jiangsu 210012 508 China 510 EMail: sunseawq@huawei.com