rfc9358.original   rfc9358.txt 
PCE Working Group Y. Lee Internet Engineering Task Force (IETF) Y. Lee
Internet-Draft Samsung Request for Comments: 9358 Samsung Electronics
Intended status: Standards Track H. Zheng Category: Standards Track H. Zheng
Expires: 27 April 2023 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
D. Ceccarelli D. Ceccarelli
Ericsson Cisco Systems
24 October 2022 February 2023
Path Computation Element Communication Protocol (PCEP) extensions for Path Computation Element Communication Protocol (PCEP) Extensions for
establishing relationships between sets of Label Switched Paths and Establishing Relationships between Sets of Label Switched Paths and
Virtual Networks Virtual Networks
draft-ietf-pce-vn-association-11
Abstract Abstract
This document describes how to extend the Path Computation Element This document describes how to extend the Path Computation Element
(PCE) Communication Protocol (PCEP) association mechanism introduced Communication Protocol (PCEP) association mechanism introduced by RFC
by the PCEP Association Group specification, to further associate 8697 to further associate sets of Label Switched Paths (LSPs) with a
sets of Label Switched Paths (LSPs) with a higher-level structure higher-level structure such as a Virtual Network (VN) requested by a
such as a Virtual Network (VN) requested by a customer or customer or application. This extended association mechanism can be
application. This extended association mechanism can be used to used to facilitate control of a VN using the PCE architecture.
facilitate control of virtual network using the PCE architecture.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 27 April 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9358.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2. Terminology
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation Overview
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Extensions to PCEP
4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations
5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 8 6.1. ASSOCIATION Object Type Indicator
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.2. PCEP TLV Type Indicator
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.3. PCEP Error
7.1. Association Object Type Indicator . . . . . . . . . . . . 9 7. Manageability Considerations
7.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 9 7.1. Control of Function and Policy
7.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Information and Data Models
8. Manageability Considerations . . . . . . . . . . . . . . . . 10 7.3. Liveness Detection and Monitoring
8.1. Control of Function and Policy . . . . . . . . . . . . . 10 7.4. Verification of Correct Operations
8.2. Information and Data Models . . . . . . . . . . . . . . . 10 7.5. Requirements on Other Protocols
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 7.6. Impact on Network Operations
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 8. References
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 8.1. Normative References
8.6. Impact On Network Operations . . . . . . . . . . . . . . 10 8.2. Informative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Contributors
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to requests from Path Computation Clients computations in response to requests from Path Computation Clients
(PCCs) [RFC5440]. (PCCs) [RFC5440].
[RFC8051] describes general considerations for a stateful PCE [RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as deployment and examines its applicability and benefits as well as its
its challenges and limitations through a number of use cases. challenges and limitations through a number of use cases. [RFC8231]
[RFC8231] describes a set of extensions to PCEP to provide stateful describes a set of extensions to PCEP to provide stateful control.
control. For its computations, a stateful PCE has access to not only For its computations, a stateful PCE has access to not only the
the information carried by the network's Interior Gateway Protocol information carried by the network's Interior Gateway Protocol (IGP)
(IGP), but also the set of active paths and their reserved resources. but also the set of active paths and their reserved resources. The
The additional state allows the PCE to compute constrained paths additional state allows the PCE to compute constrained paths while
while considering individual Label Switched Paths (LSPs) and their considering individual Label Switched Paths (LSPs) and their
interactions. interactions.
[RFC8281] describes the setup, maintenance and teardown of PCE- [RFC8281] describes the setup, maintenance, and teardown of PCE-
initiated LSPs under the stateful PCE model. initiated LSPs under the stateful PCE model.
[RFC8697] introduces a generic mechanism to create a grouping of [RFC8697] introduces a generic mechanism to create a grouping of
LSPs. This grouping can then be used to define associations between LSPs. This grouping can then be used to define associations between
sets of LSPs or between a set of LSPs and a set of attributes. sets of LSPs or between a set of LSPs and a set of attributes.
[RFC8453] introduces a framework for Abstraction and Control of TE [RFC8453] introduces a framework for Abstraction and Control of TE
Networks (ACTN) and describes various Virtual Network (VN) operations Networks (ACTN) and describes various VN operations initiated by a
initiated by a customer or application. A VN is a customer view of customer or application. A VN is a customer view of the TE network.
the TE network. Depending on the agreement between client and Depending on the agreement between client and provider, various VN
provider, various VN operations and VN views are possible. operations and VN views are possible.
[RFC8637] examines the PCE and ACTN architectures and describes how [RFC8637] examines the PCE and ACTN architectures and describes how
the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751] the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751]
describes a hierarchy of stateful PCEs with Parent PCE coordinating describe a hierarchy of stateful PCEs with the parent PCE
multi-domain path computation function between Child PCEs, and thus coordinating multi-domain path computation functions between child
making it the base for PCE applicability for ACTN. As [RFC8751] PCEs, thus making it the base for PCE applicability for ACTN. As
explains, in the context of ACTN, the Child PCE is identified with [RFC8751] explains, in the context of ACTN, the child PCE is
the Provisioning Network Controller (PNC), and the Parent PCE is identified with the Provisioning Network Controller (PNC), and the
identified with the Multi-domain Service Coordinator (MDSC). parent PCE is identified with the Multi-Domain Service Coordinator
(MDSC).
In this context, there is a need to associate a set of LSPs with a VN In this context, there is a need to associate a set of LSPs with a VN
"construct" to facilitate VN operations in the PCE architecture. "construct" to facilitate VN operations in the PCE architecture.
This association allows a PCE to identify which LSPs belong to a This association allows a PCE to identify which LSPs belong to a
certain VN. The PCE could then use this association to optimize all certain VN. The PCE could then use this association to optimize all
LSPs belonging to the VN at once. The PCE could further take VN- LSPs belonging to the VN at once. The PCE could further take VN-
specific actions on the LSPs, such as relaxation of constraints, specific actions on the LSPs, such as relaxing constraints, taking
policy actions, setting default behavior, etc. policy actions, setting default behavior, etc.
This document specifies a PCEP extension to associate a set of LSPs This document specifies a PCEP extension to associate a set of LSPs
based on their Virtual Network (VN). based on their VN.
1.1. Requirement Language 2. Terminology
This document uses terminology from [RFC4655], [RFC5440], [RFC6805],
[RFC8231], and [RFC8453].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology
The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231]
and [RFC8453].
3. Operation Overview 3. Operation 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. interact by adding them to a common association group.
An association group based on VN is useful for various optimizations An association group based on VN is useful for various optimizations
that should be applied by considering all the LSPs in the that should be applied by considering all the LSPs in the
association. This includes, but is not limited to - association. This includes, but is not limited to, the following:
* Path Computation: When computing a path for an LSP, it is useful Path Computation: When computing a path for an LSP, it is useful to
to analyze the impact of this LSP on the other LSPs belonging to analyze the impact of this LSP on the other LSPs belonging to the
the same VN. The aim would be to optimize all LSPs belonging to same VN. The aim would be to optimize all LSPs belonging to the
the VN rather than a single LSP. Also, the optimization criteria VN rather than a single LSP. Also, the optimization criteria
(such as minimizing the load of the most loaded link (MLL) (such as minimizing the load of the most loaded link (MLL)
[RFC5541]) could be applied for all the LSPs belonging to the VN [RFC5541]) could be applied for all the LSPs belonging to the VN
identified by the VN association. identified by the VN association.
* Path Re-Optimization: The PCE would like to use advanced path Path Reoptimization: The PCE would like to use advanced path
computation algorithms and optimization techniques that consider computation algorithms and optimization techniques that consider
all the LSPs belonging to a VN, and optimize them all together all the LSPs belonging to a VN and optimize them all together
during the path re-optimization. during the path reoptimization.
In this document we define a new association group called the VN In this document, we define a new association group called the "VN
Association Group (VNAG). This grouping is used to define the Association Group (VNAG)". This grouping is used to define the
association between a set of LSPs and a virtual network. association between a set of LSPs and a VN.
The Association Object contains a field to identify the type of The ASSOCIATION object contains a field to identify the type of
association, and this document defines a new Association Type value association, and this document defines a new Association Type value
of TBD1 to indicate that the association is a "VN Association". The of 7 to indicate that the association is a "VN Association". The
Association Identifier in the Association Object is the VNAG Association Identifier in the ASSOCIATION object is the VNAG
Identifier and is handled in the same way as the generic association Identifier and is handled in the same way as the generic Association
identifier defined in [RFC8697]. Identifier defined in [RFC8697].
In this document, "VNAG object" refers to an Association Object with In this document, "VNAG object" refers to an ASSOCIATION object with
the Association type set to "VN Association". the Association Type set to "VN Association" (7).
Local polices on the PCE define the computational and optimization Local policies on the PCE define the computational and optimization
behavior for the LSPs in the VN. An LSP MUST NOT belong to more than behavior for the LSPs in the VN. An LSP MUST NOT belong to more than
one VNAG. If an implementation encounters more than one VNAG object one VNAG. If an implementation encounters more than one VNAG object
in a PCEP message, it MUST process the first occurrence and it MUST in a PCEP message, it MUST process the first occurrence, and it MUST
ignore the others. ignore the others.
[RFC8697] specifies the mechanism by which a PCEP speaker can [RFC8697] specifies the mechanism by which a PCEP speaker can
advertise which association types it supports. This is done using advertise which Association Types it supports. This is done using
the ASSOC-Type-List TLV carried within an OPEN object. A PCEP the ASSOC-Type-List TLV carried within an OPEN object. A PCEP
speaker MUST include the VN Association Type (TBD1) in the ASSOC- speaker MUST include the VN Association Type (7) in the ASSOC-Type-
Type-List TLV before using the VNAG object in a PCEP message. As per List TLV before using the VNAG object in a PCEP message. As per
[RFC8697], if the implementation does not support the VN Association [RFC8697], if the implementation does not support the VN Association
Type, it will return a PCErr message with Error-Type 26 "Association Type, it will return a PCErr message with Error-Type=26 (Association
Error" and Error-value 1 "Association Type is not supported". Error) and Error-value=1 (Association Type is not supported).
The Association IDs (VNAG IDs) for this Association Type are dynamic The Association Identifiers (VNAG IDs) for this Association Type are
in nature (and created by the Parent PCE (MDSC) based on the VN dynamic in nature and created by the parent PCE (MDSC) based on the
operations for the LSPs belonging to the same VN). Operator VN operations for the LSPs belonging to the same VN. Operator
configuration of VNAG IDs is not supported, so there is no need for configuration of VNAG IDs is not supported, so there is no need for
an Operator-Configured Association Range to be set. Thus, the VN an Operator-configured Association Range to be set. Thus, the VN
Association Type (TBD1) MUST NOT be present in the Operator- Association Type (7) MUST NOT be present in the Operator-configured
Configured Association Range TLV if that TLV is present in the OPEN Association Range TLV if that TLV is present in the OPEN object. If
object. If an implementation encounters the VN Association Type an implementation encounters the VN Association Type (7) in an
(TBD1) in an Operator-Configured Association Range TLV, it MUST Operator-configured Association Range TLV, it MUST ignore the
ignore the associated Start-Assoc-ID and Range values. associated Start-Assoc-ID and Range values.
This association is useful in a PCEP session between a parent PCE This association is useful in a PCEP session between a parent PCE
(MDSC) and a child PCE (PNC). When computing the path, the child PCE (MDSC) and a child PCE (PNC). When computing the path, the child PCE
(PNC) refers to the VN association in the request from the parent PCE (PNC) refers to the VN association in the request from the parent PCE
(MDSC) and maps the VN to the associated LSPs and network resources. (MDSC) and maps the VN to the associated LSPs and network resources.
From the perspective of the Parent PCE, it receives a virtual network From the perspective of the parent PCE, it receives a VN creation
creation request by its customer, with the VN uniquely identified by request from its customer, with the VN uniquely identified by the
the Association parameters (section 6.1.4 of [RFC8697]) in the VNAG association parameters (Section 6.1.4 of [RFC8697]) in the VNAG or
or the Virtual Network identifier encoded in the VIRTUAL-NETWORK-TLV. the Virtual Network Identifier encoded in the VIRTUAL-NETWORK-TLV.
This VN may comprise multiple LSPs in the network in a single domain This VN may comprise multiple LSPs in the network in a single domain
or across multiple domains. The Parent PCE sends a PCInitiate or across multiple domains. The parent PCE sends a PCInitiate
Message with this association information in the VNAG Object. This message with this association information in the VNAG object. This
in effect binds an LSP that is to be instantiated at the child PCE in effect binds an LSP that is to be instantiated at the child PCE
with the VN. The VN association information MUST be included as a with the VN. The VN association information MUST be included as a
part of the first PCRpt message. Figure 1 shows an example of a part of the first PCRpt message. Figure 1 shows an example of a
typical VN operation using PCEP. It is worth noting that in a multi- typical VN operation using PCEP. It is worth noting that in a multi-
domain scenario, the different domains are controlled by different domain scenario, the different domains are controlled by different
child PCEs. In order to set up the cross-domain tunnel, multiple child PCEs. In order to set up the cross-domain tunnel, multiple
segments need to be stitched, by the border nodes in each domain who segments need to be stitched by the border nodes in each domain that
receive the instruction from their child PCE (PNC). receive the instruction from their child PCE (PNC).
****** ******
..........*MDSC*.............................. ..........*MDSC*..............................
. ****** .. MPI . . ****** .. MPI .
. . . PCEP . . . . .
. . . PCInitiate LSPx . . . . PCInitiate LSPx .
. . . with VNAG . . . . with VNAG .
. . . . . . . .
. . . . . . . .
. . . . . . . .
v v v . v v v .
****** ****** ****** . ****** ****** ****** .
*PNC1* *PNC2* *PNC4* . *PNC1* *PNC2* *PNC4* .
****** ****** ****** . ****** ****** ****** .
+---------------+ +---------------+ +---------------+ . +---------------+ +---------------+ +---------------+ .
| |----| |----| C| . | |----| |----| C| .
| | | | | | . | | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+---------------+ +---------------+ +---------------+ . +---------------+ +---------------+ +---------------+ .
/ . / .
****** / . ****** / .
*PNC3*<............/...................... *PNC3*<............/......................
****** / ****** /
+---------------+/ +---------------+/
| | | |
| | | |
|DOMAIN 3 | |DOMAIN 3 |
+---------------+ +---------------+
MDSC -> Parent PCE MDSC -> parent PCE
PNC -> Child PCE PNC -> child PCE
MPI -> PCEP MPI -> PCEP
Figure 1: Example of VN operations in H-PCE Architecture Figure 1: Example of VN Operations in H-PCE (Hierarchical PCE)
Architecture
Whenever changes occur with the instantiated LSP in a domain network, Whenever changes occur with the instantiated LSP in a domain network,
the domain child PCE reports the changes using a PCRpt Message in the domain child PCE reports the changes using a PCRpt message in
which the VNAG Object indicates the relationship between the LSP and which the VNAG object indicates the relationship between the LSP and
the VN. the VN.
Whenever an update occurs with VNs in the Parent PCE (due to the Whenever an update occurs with VNs in the parent PCE (due to the
customer's request), the parent PCE sends an PCUpd Message to inform customer's request), the parent PCE sends a PCUpd message to inform
each affected child PCE of this change. each affected child PCE of this change.
4. Extensions to PCEP 4. Extensions to PCEP
The format of VNAG is as per the ASSOCIATION object [RFC8697]. The VNAG uses the generic ASSOCIATION object [RFC8697].
This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV". This document defines one new mandatory TLV called the "VIRTUAL-
Optionally, the new TLV can be jointly used with the existing NETWORK-TLV". Optionally, the new TLV can be jointly used with the
"VENDOR-INFORMATION-TLV" specified in [RFC7470] as described below: existing VENDOR-INFORMATION-TLV specified in [RFC7470] as described
below:
* VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network
Identifier. Identifier.
* VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor-
specific behavioral information, described in [RFC7470]. specific behavioral information, as described in [RFC7470].
The format of VIRTUAL-NETWORK-TLV is as follows. The format of the VIRTUAL-NETWORK-TLV is as follows.
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 (variable) | | Type=65 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Virtual Network Identifier // // Virtual Network Identifier //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The VIRTUAL-NETWORK-TLV formats
Type (16-bits): TBD2 (to be allocated by IANA) Figure 2: Format of the VIRTUAL-NETWORK-TLV
Length (16-bits): indicates the length of the value portion of the Type (16 bits): 65
TLV in octets and MUST be greater than 0. The TLV MUST be zero-
padded so that the TLV is 4-octet aligned.
Virtual Network Identifier (variable): a symbolic name for the VN Length (16 bits): Indicates the length of the value portion of the
that uniquely identifies the VN. It SHOULD be a string of printable TLV in octets and MUST be greater than 0. The TLV MUST be zero-
ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL padded so that the TLV is 4-octet aligned.
terminator. The Virtual Network Identifier is a human-readable
string that identifies a VN, it can be specified with the association Virtual Network Identifier (variable): A symbolic name for the VN
information which may be conveyed in a VENDOR-INFORMATION-TLV. An that uniquely identifies the VN. It SHOULD be a string of
implementation uses the Virtual Network Identifier to maintain a printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without
mapping to the VN association group and the LSPs associated with the a NULL terminator. The Virtual Network Identifier is a human-
VN. The Virtual Network Identifier MAY be specified by the customer readable string that identifies a VN. It can be specified with
or set via an operator policy or auto-generated by the PCEP speaker. the association information, which may be conveyed in a VENDOR-
INFORMATION-TLV. An implementation uses the Virtual Network
Identifier to maintain a mapping to the VNAG and the LSPs
associated with the VN. The Virtual Network Identifier MAY be
specified by the customer, set via an operator policy, or auto-
generated by the PCEP speaker.
The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP
speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
MUST send a PCErr message with Error-Type=6 (mandatory object MUST send a PCErr message with Error-Type=6 (Mandatory Object
missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close missing) and Error-value=18 (VIRTUAL-NETWORK-TLV missing) and close
the session. the session.
The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].
If a PCEP speaker receives a VN ASSOCIATION object with a TLV that If a PCEP speaker receives a VNAG object with a TLV that violates the
violates the rules specified in this document, the PCEP speaker MUST rules specified in this document, the PCEP speaker MUST send a PCErr
send a PCErr message with Error-Type = 10 (Reception of an invalid message with Error-Type=10 (Reception of an invalid object) and
object) and Error-value = 11 (Malformed object) and MUST close the Error-value=11 (Malformed object) and MUST close the PCEP session.
PCEP session.
5. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
5.1. Huawei's Proof of Concept based on ONOS
The PCE function was developed in the ONOS open source platform.
This extension was implemented on a private version as a proof of
concept to ACTN.
* Organization: Huawei
* Implementation: Huawei's PoC based on ONOS
* Description: PCEP as a southbound plugin was added to ONOS. To
support ACTN, this extension in PCEP is used. Refer
https://wiki.onosproject.org/display/ONOS/PCEP+Protocol
* Maturity Level: Prototype
* Coverage: Full
* Contact: satishk@huawei.com
6. Security Considerations 5. Security Considerations
The security considerations described in [RFC5440], [RFC8231] and The security considerations described in [RFC5440], [RFC8231], and
[RFC8281] apply to the extensions defined in this document as well. [RFC8281] apply to the extensions defined in this document as well.
One new Association Type (VN Association) for the ASSOCIATION object This document introduces the VN Association Type (7) for the
is introduced in this document. Additional security considerations ASSOCIATION object. Additional security considerations related to
related to LSP associations due to a malicious PCEP speaker are LSP associations due to a malicious PCEP speaker are described in
described in [RFC8697] and apply to the VN Association type. Hence, [RFC8697] and apply to the VN Association Type. Hence, securing the
securing the PCEP session using Transport Layer Security (TLS) PCEP session using Transport Layer Security (TLS) [RFC8253] is
[RFC8253] is RECOMMENDED. RECOMMENDED.
7. IANA Considerations 6. IANA Considerations
7.1. Association Object Type Indicator 6.1. ASSOCIATION Object Type Indicator
IANA is requested to make the assignment of a new value in the sub- IANA has assigned the following new value in the "ASSOCIATION Type
registry "ASSOCIATION Type Field" within the "Path Computation Field" subregistry within the "Path Computation Element Protocol
Element Protocol (PCEP) Numbers" registry, as follows: (PCEP) Numbers" registry:
Value Name Reference +=======+================+===========+
| Value | Name | Reference |
+=======+================+===========+
| 7 | VN Association | RFC 9358 |
+-------+----------------+-----------+
TBD1 VN Association Type [This I.D.] Table 1
7.2. PCEP TLV Type Indicator 6.2. PCEP TLV Type Indicator
IANA is requested to make the assignment of a new value for the IANA has assigned the following new value in the "PCEP TLV Type
existing "PCEP TLV Type Indicators" sub-registry within the "Path Indicators" subregistry within the "Path Computation Element Protocol
Computation Element Protocol (PCEP) Numbers" registry, as follows: (PCEP) Numbers" registry:
Value Name Reference +=======+=====================+===========+
| Value | Name | Reference |
+=======+=====================+===========+
| 65 | VIRTUAL-NETWORK-TLV | RFC 9358 |
+-------+---------------------+-----------+
TBD2 VIRTUAL-NETWORK-TLV [This I.D.] Table 2
7.3. PCEP Error 6.3. PCEP Error
IANA is requested to allocate new error value within the "PCEP-ERROR IANA has allocated the following new error value in the "PCEP-ERROR
Object Error Types and Values" sub-registry within the "Path Object Error Types and Values" subregistry within the "Path
Computation Element Protocol (PCEP) Numbers" registry, as follows: Computation Element Protocol (PCEP) Numbers" registry:
Error-Type Meaning +============+================+=====================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+================+=====================+===========+
| 6 | Mandatory | 18: VIRTUAL- | RFC 9358 |
| | Object missing | NETWORK-TLV missing | |
+------------+----------------+---------------------+-----------+
6 Mandatory Object missing Table 3
Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
I.D.]
8. Manageability Considerations 7. Manageability Considerations
8.1. Control of Function and Policy 7.1. Control of Function and Policy
An operator MUST be allowed to mark LSPs that belong to the same VN. An operator MUST be allowed to mark LSPs that belong to the same VN.
This could also be done automatically based on the VN configuration. This could also be done automatically based on the VN configuration.
8.2. Information and Data Models 7.2. Information and Data Models
The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the The PCEP YANG module [PCE-PCEP-YANG] should support the association
association between LSPs including VN association. between LSPs including VN association.
8.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
8.4. Verify Correct Operations 7.4. Verification of Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[RFC5440]. [RFC5440].
8.5. Requirements On Other Protocols 7.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements Mechanisms defined in this document do not imply any new requirements
on other protocols. on other protocols.
8.6. Impact On Network Operations 7.6. Impact on Network Operations
[RFC8637] describe the network operations when PCE is used for VN [RFC8637] describes the network operations when PCE is used for VN
operations. Section 3 further specifies the operations when VN operations. Section 3 further specifies the operations when VN
associations are used. associations are used.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[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>.
skipping to change at page 11, line 39 skipping to change at line 464
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>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] 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)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
9.2. Informative References 8.2. Informative References
[PCE-PCEP-YANG]
Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-20>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012, DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>. <https://www.rfc-editor.org/info/rfc6805>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Code: The Implementation Status Section", BCP 205, Constraints in the Path Computation Element Communication
RFC 7942, DOI 10.17487/RFC7942, July 2016, Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7470>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of [RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of
the Path Computation Element (PCE) to the Abstraction and the Path Computation Element (PCE) to the Abstraction and
Control of TE Networks (ACTN)", RFC 8637, Control of TE Networks (ACTN)", RFC 8637,
DOI 10.17487/RFC8637, July 2019, DOI 10.17487/RFC8637, July 2019,
<https://www.rfc-editor.org/info/rfc8637>. <https://www.rfc-editor.org/info/rfc8637>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)", "Hierarchical Stateful Path Computation Element (PCE)",
RFC 8751, DOI 10.17487/RFC8751, March 2020, RFC 8751, DOI 10.17487/RFC8751, March 2020,
<https://www.rfc-editor.org/info/rfc8751>. <https://www.rfc-editor.org/info/rfc8751>.
[I-D.ietf-pce-pcep-yang] Contributors
Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October
2022, <https://datatracker.ietf.org/api/v1/doc/document/
draft-ietf-pce-pcep-yang/>.
Appendix A. Contributors Dhruv Dhody
Dhruv Dhody Huawei Technologies
Huawei Technologies Divyashree Technopark, Whitefield
Divyashree Technopark, Whitefield Bangalore 560066
Bangalore, Karnataka 560066 Karnataka
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
China China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Authors' Addresses Authors' Addresses
Young Lee Young Lee
Samsung Samsung Electronics
Seoul Seoul
South Korea Republic of Korea
Email: younglee.tx@gmail.com Email: younglee.tx@gmail.com
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake H1, Huawei Xiliu Beipo Village Songshan Lake
Dongguan Dongguan
Guangdong, 523808 Guangdong, 523808
China China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Cisco Systems
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm Stockholm
Sweden Sweden
Email: daniele.ceccarelli@ericsson.com Email: daniele.ietf@gmail.com
 End of changes. 95 change blocks. 
338 lines changed or deleted 297 lines changed or added

This html diff was produced by rfcdiff 1.48.