< draft-ietf-pce-association-policy-12.txt   draft-ietf-pce-association-policy-13.txt >
PCE Working Group S. Litkowski PCE Working Group S. Litkowski
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: April 2, 2021 Ciena Expires: April 8, 2021 Ciena
J. Tantsura J. Tantsura
Apstra, Inc. Apstra, Inc.
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
M. Negi M. Negi
RtBrick India RtBrick Inc
C. Li C. Li
Huawei Technologies Huawei Technologies
September 29, 2020 October 05, 2020
Path Computation Element (PCE) communication Protocol (PCEP) extension Path Computation Element (PCE) Communication Protocol (PCEP) extension
for associating Policies and Label Switched Paths (LSPs) for associating Policies and Label Switched Paths (LSPs)
draft-ietf-pce-association-policy-12 draft-ietf-pce-association-policy-13
Abstract Abstract
This document introduces a simple mechanism to associate policies to This document introduces a simple mechanism to associate policies to
a group of Label Switched Paths (LSPs) via an extension to the Path a group of Label Switched Paths (LSPs) via an extension to the Path
Computation Element (PCE) Communication Protocol (PCEP). The Computation Element (PCE) Communication Protocol (PCEP). The
extension allows a PCEP speaker to advertise to a PCEP peer that a extension allows a PCEP speaker to advertise to a PCEP peer that a
particular LSP belongs to a particular Policy Association Group. particular LSP belongs to a particular Policy Association Group.
Status of This Memo Status of This Memo
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2021. This Internet-Draft will expire on April 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Example of Policy Parameters . . . . . . . . . . . . 15 Appendix A. Example of Policy Parameters . . . . . . . . . . . . 15
Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 15 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element Communication
Protocol (PCEP) which enables the communication between a Path Protocol (PCEP) which enables the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides two PCEs based on the PCE architecture [RFC4655]. [RFC5394] provides
additional details on policy within the PCE architecture and also additional details on policy within the PCE architecture and also
provides context for the support of PCE Policy. provides context for the support of PCE Policy.
PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
extensions to PCEP to enable active control of Multiprotocol Label extensions to PCEP to enable active control of Multiprotocol Label
Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS)
tunnels. [RFC8281] describes the set-up and teardown of PCE- tunnels. [RFC8281] describes the set-up and teardown of PCE-
skipping to change at page 4, line 29 skipping to change at page 4, line 29
types, that provide 'information' related to the association. types, that provide 'information' related to the association.
LSR: Label Switch Router. LSR: Label Switch Router.
MPLS: Multiprotocol Label Switching. MPLS: Multiprotocol Label Switching.
PAG: Policy Association Group. PAG: Policy Association Group.
PAT: Policy Association Type. PAT: Policy Association Type.
PCC: Path Computation Client. Any client application requesting a PCC: Path Computation Client; any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity (component, application, PCE: Path Computation Element; an entity (component, application, or
or network node) that is capable of computing a network path or network node) that is capable of computing a network path or route
route based on a network graph and applying computational based on a network graph and applying computational constraints.
constraints.
PCEP: Path Computation Element Communication Protocol. PCEP: Path Computation Element Communication Protocol.
3. Motivation 3. Motivation
Paths computed using PCE can be subjected to various policies at both Paths computed using PCE can be subjected to various policies at both
the PCE and the PCC. For example, in a centralized traffic the PCE and the PCC. For example, in a centralized traffic
engineering (TE) scenario, network operators may instantiate LSPs and engineering (TE) scenario, network operators may instantiate LSPs and
specify policies for traffic accounting, path monitoring, telemetry, specify policies for traffic accounting, path monitoring, telemetry,
etc., for some LSPs via the Stateful PCE. Similarly, a PCC could etc., for some LSPs via the Stateful PCE. Similarly, a PCC could
request a user- or service-specific policy to be applied at the PCE, request a user-specific or service-specific policy to be applied at
such as constraints relaxation policy to meet optimal QoS and the PCE, such as constraints relaxation policy to meet optimal QoS
resiliency. and resiliency.
PCEP speaker can use the generic mechanism as per [RFC8697] to PCEP speaker can use the generic mechanism as per [RFC8697] to
associate a set of LSPs with a policy, without the need to know the associate a set of LSPs with a policy, without the need to know the
details of such a policy, which simplifies network operations, avoids details of such a policy, which simplifies network operations, avoids
frequent software upgrades, as well as provides an ability to frequent software upgrades, as well as provides an ability to
introduce new policies faster. introduce new policies faster.
PAG Y PAG Y
{Service-Specific Policy {Service-Specific Policy
for constraint for constraint
skipping to change at page 5, line 40 skipping to change at page 5, line 40
'-----' '-----' '-----' '-----'
Case 1: Policy requested by PCE Case 2: Policy requested by Case 1: Policy requested by PCE Case 2: Policy requested by
and enforced by PCC PCC and enforced by and enforced by PCC PCC and enforced by
PCE PCE
Figure 1: Sample use-cases for carrying policies over PCEP Figure 1: Sample use-cases for carrying policies over PCEP
3.1. Policy based Constraints 3.1. Policy based Constraints
In the context of policy-enabled path computation [RFC5394], path In the context of Policy-Enabled Path Computation Framework
computation policies may be applied at both a PCC and a PCE. [RFC5394], path computation policies may be applied at either a PCC
Consider a Label Switch Router (LSR) with a policy enabled PCC, it or a PCE or both. Consider a Label Switch Router (LSR) with a policy
receives a service request via signaling, including over a Network- enabled PCC, it receives a service request via signaling, including
Network Interface (NNI) or User-Network Interface (UNI) reference over a Network-Network Interface (NNI) or User-Network Interface
point, or receives a configuration request over a management (UNI) reference point, or receives a configuration request over a
interface to establish a service. The PCC may also apply user- or management interface to establish a service. The PCC may also apply
service-specific policies to decide how the path selection process user-specific or service-specific policies to decide how the path
should be constrained, that is, which constraints, diversities, selection process should be constrained, that is, which constraints,
optimization criterion, and constraint relaxation strategies should diversities, optimization criterion, and constraint relaxation
be applied in order for the service LSP(s) to have a likelihood to be strategies should be applied in order for the service LSP(s) to have
successfully established and provide necessary QoS and resilience a likelihood to be successfully established and provide necessary QoS
against network failures. The user- or service-specific policies and resilience against network failures. The user-specific or
applied to PCC and are then passed to the PCE along with the Path service-specific policies applied to PCC and are then passed to the
computation request, in the form of constraints [RFC5394]. PCE along with the Path computation request, in the form of
constraints [RFC5394].
PCEP speaker can use the generic mechanism as per [RFC8697] to PCEP speaker can use the generic mechanism as per [RFC8697] to
associate a set of LSPs with policy and its resulting path associate a set of LSPs with policy and its resulting path
computation constraints. This would simplify the path computation computation constraints. This would simplify the path computation
message exchanges in PCEP. message exchanges in PCEP.
4. Overview 4. Overview
As per [RFC8697], LSPs are associated with other LSPs with which they As per [RFC8697], LSPs are associated with other LSPs with which they
interact by adding them to a common association group. Grouping can interact by adding them to a common association group. Grouping can
also be used to define the association between LSPs and policies also be used to define the association between LSPs and policies
associated to them. As described in [RFC8697], the association group associated to them. As described in [RFC8697], the association group
is uniquely identified by the combination of the following fields in is uniquely identified by the combination of the following fields in
the ASSOCIATION object: Association Type, Association ID, Association the ASSOCIATION object: Association Type, Association ID, Association
Source, and (if present) Global Association Source or Extended Source, and (if present) Global Association Source or Extended
Association ID. This document defines a new Association type, called Association ID. This document defines a new Association type, called
"Policy Association" (TBD1), based on the generic ASSOCIATION object. "Policy Association", of value 3 (early-allocated by IANA), based on
This new Association type is also called "PAT", for "Policy the generic ASSOCIATION object. This new Association type is also
Association Type". called "PAT", for "Policy Association Type".
[RFC8697] specifies the mechanism for the capability advertisement of [RFC8697] specifies the mechanism for the capability advertisement of
the Association types supported by a PCEP speaker by defining a the Association types supported by a PCEP speaker by defining a
ASSOC-Type-List TLV to be carried within an OPEN object. This ASSOC-Type-List TLV to be carried within an OPEN object. This
capability exchange for the PAT (TBD1) MUST be done before using the capability exchange for the PAT MUST be done before using the policy
policy association. Thus the PCEP speaker MUST include the PAT association. Thus the PCEP speaker MUST include the PAT in the
(TBD1) in the ASSOC-Type-List TLV and MUST receive the same from the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer
PCEP peer before using the Policy Association Group (PAG) in PCEP before using the Policy Association Group (PAG) in PCEP messages.
messages.
This Association type is operator-configured [RFC8697] association in This Association type is operator-configured [RFC8697] association in
nature and created by the operator manually on the PCEP peers. An nature and created by the operator manually on the PCEP peers. An
LSP belonging to this association is conveyed via PCEP messages to LSP belonging to this association is conveyed via PCEP messages to
the PCEP peer. Operator-configured Association Range MUST NOT be set the PCEP peer. Operator-configured Association Range MUST NOT be set
for this association-type, and MUST be ignored, so that the full for this association-type, and MUST be ignored, so that the full
range of association identifier can be utilized. range of association identifier can be utilized.
A PAG can have one or more LSPs. The association parameters A PAG can have one or more LSPs. The association parameters
including association identifier, Association type (PAT), as well as including association identifier, Association type (PAT), as well as
skipping to change at page 8, line 11 skipping to change at page 8, line 11
to the PCEP peers, this could be done during the configuration of the to the PCEP peers, this could be done during the configuration of the
policy (and its association parameters) for the PAG. The TLV format policy (and its association parameters) for the PAG. The TLV format
is as per the format of the PCEP TLVs, as defined in [RFC5440], and is as per the format of the PCEP TLVs, as defined in [RFC5440], and
shown in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and shown in Figure 2. Only one POLICY-PARAMETERS-TLV can be carried and
only the first occurrence is processed and any others MUST be only the first occurrence is processed and any others MUST be
ignored. ignored.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length | | Type=48 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Policy Parameters // // Policy Parameters //
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 2: The POLICY-PARAMETERS-TLV format Figure 2: The POLICY-PARAMETERS-TLV format
The type of the POLICY-PARAMETERS-TLV is TBD2 and it has a variable The type of the POLICY-PARAMETERS-TLV is 48 (early-allocated by IANA)
length. The Value field is variable and padded to a 4-byte and it has a variable length. The Value field is variable and padded
alignment; padding is not included in the Length field. The PCEP to a 4-byte alignment; padding is not included in the Length field.
peer implementation needs to be aware of the encoding format, order, The PCEP peer implementation needs to be aware of the encoding
and meaning of the 'Policy Parameters' well in advance based on the format, order, and meaning of the 'Policy Parameters' well in advance
policy. Note that from the protocol point of view this data is based on the policy. Note that from the protocol point of view this
opaque and can be used to carry parameters in any format understood data is opaque and can be used to carry parameters in any format
by the PCEP peers and associated to the policy. The exact use of understood by the PCEP peers and associated to the policy. The exact
this TLV is beyond the scope of this document. Examples are included use of this TLV is beyond the scope of this document. Examples are
for illustration purposes in Appendix A. included for illustration purposes in Appendix A.
If the PCEP peer is unaware of the policy parameters associated with If the PCEP peer is unaware of the policy parameters associated with
the policy and it receives the POLICY-PARAMETERS-TLV, it MUST reject the policy and it receives the POLICY-PARAMETERS-TLV, it MUST reject
the PCEP message and send a PCErr message with Error-Type 26 the PCEP message and send a PCErr message with Error-Type 26
"Association Error" and Error-Value TBD3 "Not expecting policy "Association Error" and Error-Value TBD3 "Not expecting policy
parameters". Further, if one or more parameters in the POLICY- parameters". Further, if one or more parameters in the POLICY-
PARAMETERS-TLV received by the PCEP speaker are considered as PARAMETERS-TLV received by the PCEP speaker are considered as
unacceptable in the context of the associated policy (e.g. out of unacceptable in the context of the associated policy (e.g. out of
range value, badly encoded value...), the PCEP speaker MUST reject range value, badly encoded value...), the PCEP speaker MUST reject
the PCEP message and send a PCErr message with Error-Type 26 the PCEP message and send a PCErr message with Error-Type 26
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Mechanisms defined in this document do not have any impact on network Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440], operations in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
10. Acknowledgments 10. Acknowledgments
A special thanks to the authors of [RFC8697], this document borrowed A special thanks to the authors of [RFC8697], this document borrowed
some of the text from it. The authors would like to thank Aijun some of the text from it. The authors would like to thank Aijun
Wang, Peng Shuping, and Gyan Mishra for their useful comments. Wang, Peng Shuping, and Gyan Mishra for their useful comments.
Thanks to Hari for shepherding this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
skipping to change at page 17, line 26 skipping to change at page 17, line 26
Jonathan Hardwick Jonathan Hardwick
Metaswitch Networks Metaswitch Networks
100 Church Street 100 Church Street
Enfield, Middlesex Enfield, Middlesex
UK UK
EMail: Jonathan.Hardwick@metaswitch.com EMail: Jonathan.Hardwick@metaswitch.com
Mahendra Singh Negi Mahendra Singh Negi
RtBrick India RtBrick Inc
N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 N-17L, 18th Cross Rd, HSR Layout
Bangalore, Karnataka 560102 Bangalore, Karnataka 560102
India India
EMail: mahend.ietf@gmail.com EMail: mahend.ietf@gmail.com
Cheng Li Cheng Li
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
 End of changes. 17 change blocks. 
51 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/