< draft-barth-pce-segment-routing-policy-cp-05.txt   draft-barth-pce-segment-routing-policy-cp-06.txt >
PCE Working Group M. Koldychev PCE Working Group M. Koldychev
Internet-Draft S. Sivabalan Internet-Draft S. Sivabalan
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: November 5, 2020 C. Barth Expires: December 4, 2020 C. Barth
Juniper Networks, Inc. Juniper Networks, Inc.
C. Li S. Peng
Huawei Technologies Huawei Technologies
H. Bidgoli H. Bidgoli
Nokia Nokia
May 04, 2020 June 2, 2020
PCEP extension to support Segment Routing Policy Candidate Paths PCEP extension to support Segment Routing Policy Candidate Paths
draft-barth-pce-segment-routing-policy-cp-05 draft-barth-pce-segment-routing-policy-cp-06
Abstract Abstract
This document introduces a mechanism to specify a Segment Routing This document introduces a mechanism to specify a Segment Routing
(SR) policy, as a collection of SR candidate paths. An SR policy is (SR) policy, as a collection of SR candidate paths. An SR policy is
identified by <headend, color, end-point> tuple. An SR policy can identified by <headend, color, end-point> tuple. An SR policy can
contain one or more candidate paths where each candidate path is contain one or more candidate paths where each candidate path is
identified in PCEP via an PLSP-ID. This document proposes extension identified in PCEP via an PLSP-ID. This document proposes extension
to PCEP to support association among candidate paths of a given SR to PCEP to support association among candidate paths of a given SR
policy. The mechanism proposed in this document is applicable to policy. The mechanism proposed in this document is applicable to
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 November 5, 2020. This Internet-Draft will expire on December 4, 2020.
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 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Group Candidate Paths belonging to the same SR policy . . 5 3.1. Group Candidate Paths belonging to the same SR policy . . 5
3.2. Instantiation of SR policy candidate paths . . . . . . . 5 3.2. Instantiation of SR policy candidate paths . . . . . . . 5
3.3. Avoid computing lower preference candidate paths . . . . 5 3.3. Avoid computing lower preference candidate paths . . . . 5
3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 5 3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 5
4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Choice of Association Parameters . . . . . . . . . . . . 7 4.2. Choice of Association Parameters . . . . . . . . . . . . 8
4.3. Multiple Optimization Objectives and Constraints . . . . 8 4.3. Multiple Optimization Objectives and Constraints . . . . 8
5. SR Policy Association Group . . . . . . . . . . . . . . . . . 8 5. SR Policy Association Group . . . . . . . . . . . . . . . . . 8
5.1. SR Policy Identifiers TLV . . . . . . . . . . . . . . . . 9 5.1. SR Policy Identifiers TLV . . . . . . . . . . . . . . . . 9
5.2. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 10 5.2. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 10
5.3. SR Policy Candidate Path Identifiers TLV . . . . . . . . 10 5.3. SR Policy Candidate Path Identifiers TLV . . . . . . . . 11
5.4. SR Policy Candidate Path Preference TLV . . . . . . . . . 11 5.4. SR Policy Candidate Path Name TLV . . . . . . . . . . . . 12
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. SR Policy Candidate Path Preference TLV . . . . . . . . . 12
6.1. PCC Initiated SR Policy with single candidate-path . . . 12 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. PCC Initiated SR Policy with multiple candidate-paths . . 12 6.1. PCC Initiated SR Policy with single candidate-path . . . 13
6.3. PCE Initiated SR Policy with single candidate-path . . . 13 6.2. PCC Initiated SR Policy with multiple candidate-paths . . 13
6.4. PCE Initiated SR Policy with multiple candidate-paths . . 14 6.3. PCE Initiated SR Policy with single candidate-path . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.4. PCE Initiated SR Policy with multiple candidate-paths . . 15
7.1. Association Type . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 15
7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Path Computation Element (PCE) Communication Protocol (PCEP) Path Computation Element (PCE) Communication Protocol (PCEP)
[RFC5440] enables the communication between a Path Computation Client [RFC5440] enables the communication between a Path Computation Client
(PCC) and a Path Control Element (PCE), or between two PCEs based on (PCC) and a Path Control Element (PCE), or between two PCEs based on
the PCE architecture [RFC4655]. the PCE architecture [RFC4655].
PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set
of extensions to PCEP to enable active control of Multiprotocol Label of 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 setup and teardown of PCE-initiated tunnels. [RFC8281] describes the setup and teardown of PCE-initiated
LSPs under the active stateful PCE model, without the need for local LSPs under the active stateful PCE model, without the need for local
configuration on the PCC, thus allowing for dynamic centralized configuration on the PCC, thus allowing for dynamic centralized
control of a network. control of a network.
PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing] PCEP Extensions for Segment Routing [RFC8664] specifies extensions to
specifies extensions to the Path Computation Element Protocol (PCEP) the Path Computation Element Protocol (PCEP) that allow a stateful
that allow a stateful PCE to compute and initiate Traffic Engineering PCE to compute and initiate Traffic Engineering (TE) paths, as well
(TE) paths, as well as a PCC to request a path subject to certain as a PCC to request a path subject to certain constraint(s) and
constraint(s) and optimization criteria in SR networks. optimization criteria in SR networks.
PCEP Extensions for Establishing Relationships Between Sets of LSPs PCEP Extensions for Establishing Relationships Between Sets of LSPs
[I-D.ietf-pce-association-group] introduces a generic mechanism to [RFC8697] introduces a generic mechanism to create a grouping of LSPs
create a grouping of LSPs which can then be used to define which can then be used to define associations between a set of LSPs
associations between a set of LSPs and a set of attributes (such as and a set of attributes (such as configuration parameters or
configuration parameters or behaviors) and is equally applicable to behaviors) and is equally applicable to stateful PCE (active and
stateful PCE (active and passive modes) and stateless PCE. passive modes) and stateless PCE.
Segment Routing Policy for Traffic Engineering Segment Routing Policy for Traffic Engineering
[I-D.ietf-spring-segment-routing-policy] details the concepts of SR [I-D.ietf-spring-segment-routing-policy] details the concepts of SR
Policy and approaches to steering traffic into an SR Policy. Policy and approaches to steering traffic into an SR Policy.
An SR policy contains one or more candidate paths where one or more An SR policy contains one or more candidate paths where one or more
such paths can be computed via PCE. This document specifies PCEP such paths can be computed via PCE. This document specifies PCEP
extensions to signal additional information to map candidate paths to extensions to signal additional information to map candidate paths to
their SR policies. Each candidate path maps to a unique PLSP-ID in their SR policies. Each candidate path maps to a unique PLSP-ID in
PCEP. By associating multiple candidate paths together, a PCE PCEP. By associating multiple candidate paths together, a PCE
becomes aware of the hierarchical structure of an SR policy. Thus becomes aware of the hierarchical structure of an SR policy. Thus
the PCE can take computation and control decisions about the the PCE can take computation and control decisions about the
candidate paths, with the additional knowledge that these candidate candidate paths, with the additional knowledge that these candidate
paths belong to the same SR policy. This is accomplished via the use paths belong to the same SR policy. This is accomplished via the use
of the existing PCEP Association object, by defining a new of the existing PCEP Association object, by defining a new
association type specifically for associating SR candidate paths into association type specifically for associating SR candidate paths into
a single SR policy. a single SR policy.
[Editor's Note- Currently it is assumed that each candidate path has [Editor's Note- Currently it is assumed that each candidate path has
only one ERO (SID-List) within the scope of this document. A future only one ERO (SID-List) within the scope of this document. Another
update or another document will deal with a way to allow multiple document will deal with a way to allow multiple ERO/SID-Lists for a
ERO/SID-Lists for a candidate path within PCEP.] candidate path within PCEP.]
2. Terminology 2. Terminology
The following terminologies are used in this document: The following terminologies are used in this document:
Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in
question, as described in question, as described in
[I-D.ietf-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
Association parameters: As described in Association parameters: As described in [RFC8697], the combination
[I-D.ietf-pce-association-group], the combination of the mandatory of the mandatory fields Association type, Association ID and
fields Association type, Association ID and Association Source in Association Source in the ASSOCIATION object uniquely identify the
the ASSOCIATION object uniquely identify the association group. association group. If the optional TLVs - Global Association
If the optional TLVs - Global Association Source or Extended Source or Extended Association ID are included, then they MUST be
Association ID are included, then they MUST be included in included in combination with mandatory fields to uniquely identify
combination with mandatory fields to uniquely identify the the association group.
association group.
Association information: As described in Association information: As described in [RFC8697], the ASSOCIATION
[I-D.ietf-pce-association-group], the ASSOCIATION object could object could also include other optional TLVs based on the
also include other optional TLVs based on the association types, association types, that provides 'information' related to the
that provides 'information' related to the association type. 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 network node) that is capable of computing a network path or or network node) that is capable of computing a network path or
route based on a network graph and applying computational route based on a network graph and applying computational
constraints. constraints.
PCEP: Path Computation Element Protocol. PCEP: Path Computation Element Protocol.
PCEP Tunnel: The entity identified by the PLSP-ID, as per PCEP Tunnel: The entity identified by the PLSP-ID, as per
[I-D.koldychev-pce-operational]. [I-D.koldychev-pce-operational].
3. Motivation 3. Motivation
The new Association Type (SR Policy Association) and the new TLVs for The new Association Type (SR Policy Association) and the new TLVs for
the ASSOCIATION object, defined in this document, allow a PCEP peer the ASSOCIATION object, defined in this document, allow a PCEP peer
to exchange additional parameters of SR candidate paths and of their to exchange additional parameters of SR candidate paths and of their
parent SR policy. For the SR policy, the parameters are: color and associated SR policy. For the SR policy, the parameters are: color
endpoint. For the candidate path, the parameters are: protocol and endpoint. For the candidate path, the parameters are: protocol
origin, originator, discriminator and preference. origin, originator, discriminator and preference.
[I-D.ietf-spring-segment-routing-policy] describes the concept of SR [I-D.ietf-spring-segment-routing-policy] describes the concept of SR
Policy and these parameters. Policy and these parameters.
The motivation for signaling these parameters is summarized in the The motivation for signaling these parameters is summarized in the
following subsections. following subsections.
3.1. Group Candidate Paths belonging to the same SR policy 3.1. Group Candidate Paths belonging to the same SR policy
Since each candidate path of an SR policy appears as a different LSP Since each candidate path of an SR policy appears as a different LSP
(identified via a PLSP-ID) in PCEP, it is useful to group together (identified via a PLSP-ID) in PCEP, it is useful to group together
skipping to change at page 6, line 11 skipping to change at page 6, line 13
independently of each other. This is achieved by making each independently of each other. This is achieved by making each
candidate path correspond to a unique LSP (identified via PLSP-ID). candidate path correspond to a unique LSP (identified via PLSP-ID).
For example, if an SR policy has 4 candidate paths, then if the PCE For example, if an SR policy has 4 candidate paths, then if the PCE
wants to update one of those candidate paths, only one set of PCUpd wants to update one of those candidate paths, only one set of PCUpd
and PCRpt messages needs to be exchanged. and PCRpt messages needs to be exchanged.
4. Procedure 4. Procedure
4.1. Overview 4.1. Overview
As per [I-D.ietf-pce-association-group], LSPs are placed into an As per [RFC8697], LSPs are placed into an association group. As per
association group. As per [I-D.koldychev-pce-operational], LSPs are [I-D.koldychev-pce-operational], LSPs are contained in PCEP Tunnels
contained in PCEP Tunnels and a PCEP Tunnel is contained in an and a PCEP Tunnel is contained in an Association if all of its LSPs
Association if all of its LSPs are in that Association. are in that Association.
PCEP Tunnels naturally map to SR Candidate Paths and PCEP PCEP Tunnels naturally map to SR Candidate Paths and PCEP
Associations naturally map to SR Policies. Definition of these Associations naturally map to SR Policies. Definition of these
mappings is the central purpose of this document. mappings is the central purpose of this document.
The mapping between PCEP Associations and SR Policies is always one- The mapping between PCEP Associations and SR Policies is always one-
to-one. However, the mapping between PCEP Tunnels and SR Candidate to-one. However, the mapping between PCEP Tunnels and SR Candidate
Paths may be either one-to-one, or many-to-one. The mapping is one- Paths may be either one-to-one, or many-to-one. The mapping is one-
to-one when the SR Candidate Path has only a single constraint and to-one when the SR Candidate Path has only a single constraint and
optimization objective. The mapping is many-to-one when the SR optimization objective. The mapping is many-to-one when the SR
Candidate Path has multiple constraints and optimization objectives. Candidate Path has multiple constraints and optimization objectives.
For more details on multiple optimization objectives and constraints, For more details on multiple optimization objectives and constraints,
see Section 4.3. see Section 4.3.
[Editor's Note - Segment-lists within a candidate path are not [Editor's Note - Segment-lists within a candidate path are not
represented by different PCEP Tunnels. The subject of encoding represented by different PCEP Tunnels. The subject of encoding
multiple segment lists within a candidate path is left to a future multiple segment lists within a candidate path is left to another
document and is not specified in this document. It is not a good document and is not specified in this document. It is not a good
idea to have each segment-list correspond to a different Tunnel, idea to have each segment-list correspond to a different Tunnel,
because when the PCC wants to get a path, it must know in advance how because when the PCC wants to get a path, it must know in advance how
many multipaths (i.e., segment-lists) there will be and create that many multipaths (i.e., segment-lists) there will be and create that
many Tunnels. For example, if the PCC supports 32 multipaths, then many Tunnels. For example, if the PCC supports 32 multipaths, then
it must delegate 32 Tunnels for every candidate path, which may not it must delegate 32 Tunnels for every candidate path, which may not
be scalable.] be scalable.]
A new Association Type is defined in this document, based on the A new Association Type is defined in this document, based on the
generic ASSOCIATION object. Association type = TBD1 "SR Policy generic ASSOCIATION object. Association type = TBD1 "SR Policy
skipping to change at page 7, line 34 skipping to change at page 7, line 34
SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr
message with Error Code = 26 "Association Error", Error Type = TBD6 message with Error Code = 26 "Association Error", Error Type = TBD6
"Conflicting SRPAG TLV". Candidate path Identifiers consist of: "Conflicting SRPAG TLV". Candidate path Identifiers consist of:
o Protocol Origin of candidate path. o Protocol Origin of candidate path.
o Originator of candidate path. o Originator of candidate path.
o Discriminator of candidate path. o Discriminator of candidate path.
o Optionally, the candidate path name.
Candidate Path Attributes MUST NOT be used to identify the candidate Candidate Path Attributes MUST NOT be used to identify the candidate
path. Candidate path attributes carry additional information about path. Candidate path attributes carry additional information about
the candidate path and MAY change during the lifetime of the LSP. the candidate path and MAY change during the lifetime of the LSP.
Candidate path Attributes consist of: Candidate path Attributes consist of:
o Preference of candidate path. o Preference of candidate path.
As per the processing rules specified in section 5.4 of As per the processing rules specified in section 5.4 of [RFC8697], if
[I-D.ietf-pce-association-group], if a PCEP speaker does not support a PCEP speaker does not support the SRPAG association type, it MUST
the SRPAG association type, it MUST return a PCErr message with return a PCErr message with Error-Type 26 (Early allocation by IANA)
Error-Type 26 (Early allocation by IANA) "Association Error" and "Association Error" and Error-Value 1 "Association-type is not
Error-Value 1 "Association-type is not supported". Please note that supported". Please note that the corresponding PCEP session is not
the corresponding PCEP session is not reset. reset.
4.2. Choice of Association Parameters 4.2. Choice of Association Parameters
The Association Parameters (see Section 2) uniquely identify the The Association Parameters (see Section 2) uniquely identify the
Association. In this section, we describe how these are to be set. Association. In this section, we describe how these are to be set.
The Association Source MUST be set to the PCC's address. This The Association Source MUST be set to the PCC's address. This
applies for both PCC-initiated and PCE-initiated candidate paths. applies for both PCC-initiated and PCE-initiated candidate paths.
The reasoning for this is that if different PCEs could set their own The reasoning for this is that if different PCEs could set their own
Association Source, then the candidate paths instantiated by Association Source, then the candidate paths instantiated by
skipping to change at page 8, line 44 skipping to change at page 8, line 49
Tunnels and SR Candidate Paths. This means that multiple PCEP Tunnels and SR Candidate Paths. This means that multiple PCEP
Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel
has its own optimization objective and constraints. When a single SR has its own optimization objective and constraints. When a single SR
Candidate Path contains multiple PCEP Tunnels, each of these PCEP Candidate Path contains multiple PCEP Tunnels, each of these PCEP
Tunnels MUST have identical values of Candidate Path Identifiers, as Tunnels MUST have identical values of Candidate Path Identifiers, as
encoded in SRPOLICY-CPATH-ID TLV, see Section 5.3. encoded in SRPOLICY-CPATH-ID TLV, see Section 5.3.
5. SR Policy Association Group 5. SR Policy Association Group
Two ASSOCIATION object types for IPv4 and IPv6 are defined in Two ASSOCIATION object types for IPv4 and IPv6 are defined in
[I-D.ietf-pce-association-group]. The ASSOCIATION object includes [RFC8697]. The ASSOCIATION object includes "Association type"
"Association type" indicating the type of the association group. indicating the type of the association group. This document adds a
This document adds a new Association type. new Association type.
Association type = TBD1 "SR Policy Association Type" for SR Policy Association type = TBD1 "SR Policy Association Type" for SR Policy
Association Group (SRPAG). Association Group (SRPAG).
The operator configured Association Range SHOULD NOT be set for this This Association type is dynamic in nature and created by the PCC or
association type and MUST be ignored. PCE for the candidate paths belonging to the same SR policy (as
described in [I-D.ietf-spring-segment-routing-policy]). These
associations are conveyed via PCEP messages to the PCEP peer.
Operator-configured Association Range MUST NOT be set for this
Association type and MUST be ignored.
SRPAG MUST carry additional TLVs to communicate Association SRPAG MUST carry additional TLVs to communicate Association
Information. This document specifies four new TLVs to carry Information. This document specifies five new TLVs to carry
Association Information: SRPOLICY-POL-ID TLV, SRPOLICY-POL-NAME TLV, Association Information: SRPOLICY-POL-ID TLV, SRPOLICY-POL-NAME TLV,
SRPOLICY-CPATH-ID TLV, SRPOLICY-CPATH-PREFERENCE TLV. These four SRPOLICY-CPATH-ID TLV, SRPOLICY-CPATH-NAME TLV, SRPOLICY-CPATH-
TLVs encode the Policy Identifiers, Policy name, Candidate path PREFERENCE TLV. These five TLVs encode the Policy Identifiers, SR
Identifiers and Candidate path Preference, respectively. When any of Policy name, Candidate path identifiers, candidate path name, and
the mandatory TLVs are missing from the SRPAG association object, the Candidate path preference, respectively. When any of the mandatory
PCE MUST send a PCErr message with Error Code = 26 "Association TLVs are missing from the SRPAG association object, the PCE MUST send
Error", Error Type = TBD7 "Missing mandatory SRPAG TLV". a PCErr message with Error Code = 26 "Association Error", Error Type
= TBD7 "Missing mandatory SRPAG TLV".
A given LSP MUST belong to at most one SRPAG, since a candidate path A given LSP MUST belong to at most one SRPAG, since a candidate path
cannot belong to multiple SR policies. If a PCEP speaker receives a cannot belong to multiple SR policies. If a PCEP speaker receives a
PCEP message with more than one SRPAG for an LSP, then the PCEP PCEP message with more than one SRPAG for an LSP, then the PCEP
speaker MUST send a PCErr message with Error-Type 26 "Association speaker MUST send a PCErr message with Error-Type 26 "Association
Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the
message is a PCRpt message, then the PCEP speaker MUST close the PCEP message is a PCRpt message, then the PCEP speaker MUST close the PCEP
connection. Closing the PCEP connection is necessary because connection. Closing the PCEP connection is necessary because
ignoring PCRpt messages may lead to inconsistent LSP DB state between ignoring PCRpt messages may lead to inconsistent LSP DB state between
the two PCEP peers. the two PCEP peers.
If the PCEP speaker receives the SRPAG association when the SR If the PCEP speaker receives the SRPAG association when the SR
capability (as per [I-D.ietf-pce-segment-routing] or capability (as per [RFC8664] or [I-D.ietf-pce-segment-routing-ipv6])
[I-D.negi-pce-segment-routing-ipv6]) was not exchanged, the PCEP was not exchanged, the PCEP speaker MUST send a PCErr message with
speaker MUST send a PCErr message with Error-Type 26 "Association Error-Type 26 "Association Error" and Error-Value TBD9 "Use of SRPAG
Error" and Error-Value TBD9 "Use of SRPAG without SR capability without SR capability exchange". If the Path Setup Type (PST) of the
exchange". If the Path Setup Type (PST) of the LSP in SRPAG is not LSP in SRPAG is not set to SR or SRv6, then the PCEP speaker MUST
set to SR or SRv6, then the PCEP speaker MUST send a PCErr message send a PCErr message with Error-Type 26 "Association Error" and
with Error-Type 26 "Association Error" and Error-Value TBD10 "non-SR Error-Value TBD10 "non-SR LSP in SRPAG".
LSP in SRPAG".
5.1. SR Policy Identifiers TLV 5.1. SR Policy Identifiers TLV
The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association. The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association.
Only one SRPOLICY-POL-ID TLV can be carried and only the first Only one SRPOLICY-POL-ID TLV can be carried and only the first
occurrence is processed and any others MUST be ignored. occurrence is processed and any others MUST be 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 44 skipping to change at page 12, line 12
identifier, as specified in [I-D.ietf-spring-segment-routing-policy] identifier, as specified in [I-D.ietf-spring-segment-routing-policy]
Section 2.4. Section 2.4.
Originator Address: Represented as 128 bit value where IPv4 address Originator Address: Represented as 128 bit value where IPv4 address
are encoded in lowest 32 bits, part of the originator identifier, as are encoded in lowest 32 bits, part of the originator identifier, as
specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4.
Discriminator: 32-bit value that encodes the Discriminator of the Discriminator: 32-bit value that encodes the Discriminator of the
candidate path. candidate path.
5.4. SR Policy Candidate Path Preference TLV 5.4. SR Policy Candidate Path Name TLV
The SRPOLICY-CPATH-NAME TLV is an optional TLV for the SRPAG
Association. At most one SRPOLICY-CPATH-NAME TLV can be carried and
only the first occurrence is processed and any others MUST be
ignored.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SR Policy Candidate Path Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SRPOLICY-CPATH-NAME TLV format
Type: TBD11 for "SRPOLICY-CPATH-NAME" TLV.
Length: indicates the total length of the TLV in octets and MUST be
greater than 0. The TLV MUST be zero-padded so that the TLV is
4-octet aligned.
SR Policy Candidate Path Name: SR Policy Candidate Path Name, as
defined in [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a
string of printable ASCII characters, without a NULL terminator.
5.5. SR Policy Candidate Path Preference TLV
The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG
Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried
and only the first occurrence is processed and any others MUST be and 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SRPOLICY-CPATH-PREFERENCE TLV format Figure 5: The SRPOLICY-CPATH-PREFERENCE TLV format
Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV.
Length: 4. Length: 4.
Preference: Numerical preference of the candidate path, as specified Preference: Numerical preference of the candidate path, as specified
in [I-D.ietf-spring-segment-routing-policy] Section 2.7. in [I-D.ietf-spring-segment-routing-policy] Section 2.7.
If the TLV is missing, a default preference of 100 as specified in If the TLV is missing, a default preference of 100 as specified in
[I-D.ietf-spring-segment-routing-policy] is used. [I-D.ietf-spring-segment-routing-policy] is used.
skipping to change at page 14, line 44 skipping to change at page 15, line 44
2. PCC uses the PLSP-ID from the LSP object to find the candidate 2. PCC uses the PLSP-ID from the LSP object to find the candidate
path and delete it. path and delete it.
7. IANA Considerations 7. IANA Considerations
7.1. Association Type 7.1. Association Type
This document defines a new association type: SR Policy Association This document defines a new association type: SR Policy Association
Group (SRPAG). IANA is requested to make the assignment of a new Group (SRPAG). IANA is requested to make the assignment of a new
value for the sub-registry "ASSOCIATION Type Field" (request to be value for the sub-registry "ASSOCIATION Type Field" (request to be
created in [I-D.ietf-pce-association-group]), as follows: created in [RFC8697]), as follows:
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
| Association Type | Association Name | Reference | | Association Type | Association Name | Reference |
| Value | | | | Value | | |
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
| TBD1 | SR Policy Association | This document | | TBD1 | SR Policy Association | This document |
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
7.2. PCEP Errors 7.2. PCEP Errors
This document defines three new Error-Values within the "Association This document defines five new Error-Values within the "Association
Error" Error-Type. IANA is requested to allocate new error values Error" Error-Type. IANA is requested to allocate new error values
within the "PCEP-ERROR Object Error Types and Values" sub-registry of within the "PCEP-ERROR Object Error Types and Values" sub-registry of
the PCEP Numbers registry, as follows: the PCEP Numbers registry, as follows:
+-------+----------+-----------------------------+------------------+ +-------+----------+-----------------------------+------------------+
| Error | Error | Meaning | Reference | | Error | Error | Meaning | Reference |
| Type | Value | | | | Type | Value | | |
+-------+----------+-----------------------------+------------------+ +-------+----------+-----------------------------+------------------+
| 29 | TBD6 | Conflicting SRPAG TLV | This document | | 29 | TBD6 | Conflicting SRPAG TLV | This document |
+-------+----------+-----------------------------+------------------+ +-------+----------+-----------------------------+------------------+
skipping to change at page 15, line 30 skipping to change at page 16, line 30
| 29 | TBD8 | Multiple SRPAG for one LSP | This document | | 29 | TBD8 | Multiple SRPAG for one LSP | This document |
+-------+----------+-----------------------------+------------------+ +-------+----------+-----------------------------+------------------+
| 29 | TBD9 | Use of SRPAG without SR | This document | | 29 | TBD9 | Use of SRPAG without SR | This document |
| | | capability exchange | | | | | capability exchange | |
+-------+----------+-----------------------------+------------------+ +-------+----------+-----------------------------+------------------+
| 29 | TBD10 | non-SR LSP in SRPAG | This document | | 29 | TBD10 | non-SR LSP in SRPAG | This document |
+-------+----------+-----------------------------+------------------+ +-------+----------+-----------------------------+------------------+
7.3. SRPAG TLVs 7.3. SRPAG TLVs
This document defines three new TLVs for carrying additional This document defines five new TLVs for carrying additional
information about SR policy and SR candidate paths. IANA is information about SR policy and SR candidate paths. IANA is
requested to make the assignment of a new value for the existing requested to make the assignment of a new value for the existing
"PCEP TLV Type Indicators" registry as follows: "PCEP TLV Type Indicators" registry as follows:
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| TLV Type | TLV Name | Reference | | TLV Type | TLV Name | Reference |
| Value | | | | Value | | |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| TBD2 | SRPOLICY-POL-ID | This document | | TBD2 | SRPOLICY-POL-ID | This document |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| TBD3 | SRPOLICY-POL-NAME | This document | | TBD3 | SRPOLICY-POL-NAME | This document |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| TBD4 | SRPOLICY-CPATH-ID | This document | | TBD4 | SRPOLICY-CPATH-ID | This document |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| TBD11 | SRPOLICY-CPATH-NAME | This document |
+------------+-----------------------------------+------------------+
| TBD5 | SRPOLICY-CPATH-PREFERENCE | This document | | TBD5 | SRPOLICY-CPATH-PREFERENCE | This document |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
8. Security Considerations 8. Security Considerations
This document defines one new type for association, which do not add This document defines one new type for association, which do not add
any new security concerns beyond those discussed in [RFC5440], any new security concerns beyond those discussed in [RFC5440],
[RFC8231], [I-D.ietf-pce-segment-routing], [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and
[I-D.negi-pce-segment-routing-ipv6] and [RFC8697] in itself.
[I-D.ietf-pce-association-group] in itself.
The information carried in the SRPAG Association object, as per this The information carried in the SRPAG Association object, as per this
document is related to SR Policy. It often reflects information that document is related to SR Policy. It often reflects information that
can also be derived from the SR Database, but association provides a can also be derived from the SR Database, but association provides a
much easier grouping of related LSPs and messages. The SRPAG much easier grouping of related LSPs and messages. The SRPAG
association could provides an adversary with the opportunity to association could provides an adversary with the opportunity to
eavesdrop on the relationship between the LSPs. Thus securing the eavesdrop on the relationship between the LSPs. Thus securing the
PCEP session using Transport Layer Security (TLS) [RFC8253], as per PCEP session using Transport Layer Security (TLS) [RFC8253], as per
the recommendations and best current practices in [RFC7525], is the recommendations and best current practices in [RFC7525], is
RECOMMENDED. RECOMMENDED.
skipping to change at page 17, line 14 skipping to change at page 18, line 8
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress), ietf-spring-segment-routing-policy-07 (work in progress),
December 2019. May 2020.
[I-D.ietf-pce-association-group] [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships Between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", draft-ietf-pce-association-group-10 (work in (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
progress), August 2019. <https://www.rfc-editor.org/info/rfc8697>.
[I-D.ietf-pce-segment-routing] [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication
and J. Hardwick, "PCEP Extensions for Segment Routing", Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
draft-ietf-pce-segment-routing-16 (work in progress), DOI 10.17487/RFC8664, December 2019,
March 2019. <https://www.rfc-editor.org/info/rfc8664>.
[I-D.koldychev-pce-operational] [I-D.koldychev-pce-operational]
Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and
H. Kotni, "PCEP Operational Clarification", draft- H. Kotni, "PCEP Operational Clarification", draft-
koldychev-pce-operational-01 (work in progress), February koldychev-pce-operational-01 (work in progress), February
2020. 2020.
10.2. Informative References 10.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
skipping to change at page 18, line 11 skipping to change at page 19, line 5
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[I-D.negi-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y.
Extensions for Segment Routing leveraging the IPv6 data Zhu, "PCEP Extensions for Segment Routing leveraging the
plane", draft-negi-pce-segment-routing-ipv6-04 (work in IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-04
progress), February 2019. (work in progress), March 2020.
Appendix A. Contributors Appendix A. Contributors
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing, 10095
China
Email: chengli13@huawei.com
Authors' Addresses Authors' Addresses
Mike Koldychev Mike Koldychev
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: mkoldych@cisco.com Email: mkoldych@cisco.com
skipping to change at page 18, line 44 skipping to change at page 20, line 4
Email: mkoldych@cisco.com Email: mkoldych@cisco.com
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
Colby Barth Colby Barth
Juniper Networks, Inc. Juniper Networks, Inc.
Email: cbarth@juniper.net Email: cbarth@juniper.net
Cheng Li
Shuping Peng
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: chengli13@huawei.com Email: pengshuping@huawei.com
Hooman Bidgoli Hooman Bidgoli
Nokia Nokia
Email: hooman.bidgoli@nokia.com Email: hooman.bidgoli@nokia.com
 End of changes. 39 change blocks. 
111 lines changed or deleted 153 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/