draft-ietf-pce-stateful-pce-p2mp-05.txt   draft-ietf-pce-stateful-pce-p2mp-06.txt 
PCE Working Group U. Palle PCE Working Group U. Palle
Internet-Draft D. Dhody Internet-Draft D. Dhody
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: May 3, 2018 Y. Tanaka Expires: September 5, 2018 Y. Tanaka
NTT Communications NTT Communications
V. Beeram V. Beeram
Juniper Networks Juniper Networks
October 30, 2017 March 4, 2018
Path Computation Element (PCE) Protocol Extensions for Stateful PCE Path Computation Element (PCE) Protocol Extensions for Stateful PCE
usage for Point-to-Multipoint Traffic Engineering Label Switched Paths usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-stateful-pce-p2mp-05 draft-ietf-pce-stateful-pce-p2mp-06
Abstract Abstract
The Path Computation Element (PCE) has been identified as an The Path Computation Element (PCE) has been identified as an
appropriate technology for the determination of the paths of point- appropriate technology for the determination of the paths of point-
to-multipoint (P2MP) TE LSPs. This document provides extensions to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document
required for Path Computation Element communication Protocol (PCEP) provides extensions required for Path Computation Element
so as to enable the usage of a stateful PCE capability in supporting Communication Protocol (PCEP) so as to enable the usage of a stateful
P2MP TE LSPs. PCE capability in supporting P2MP TE LSPs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 3, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4 3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5
4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5
5. Architectural Overview of Protocol Extensions . . . . . . . . 6 5. Architectural Overview of Protocol Extensions . . . . . . . . 5
5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6
5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6
5.3. IGP Extensions for Stateful PCE P2MP Capabilities 5.3. IGP Extensions for Stateful PCE P2MP Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 7 Advertisement . . . . . . . . . . . . . . . . . . . . . . 7
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8
5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 8 5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 8
5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9 5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9
5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9 5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9
5.6.3.1. P2MP TE LSP Instantiation . . . . . . . . . . . . 9 5.6.3.1. P2MP TE LSP Instantiation . . . . . . . . . . . . 9
5.6.3.2. P2MP TE LSP Deletion . . . . . . . . . . . . . . 9 5.6.3.2. P2MP TE LSP Deletion . . . . . . . . . . . . . . 9
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 9
5.6.3.4. P2MP TE LSP Delegation and Cleanup . . . . . . . 10 5.6.3.4. P2MP TE LSP Delegation and Cleanup . . . . . . . 10
6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 10 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 10
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 10 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 10
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 12 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 12
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 13 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 13
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 14 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 14
6.5. The PCInitiate message . . . . . . . . . . . . . . . . . 15 6.5. The PCInitiate message . . . . . . . . . . . . . . . . . 15
6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.6.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 17 6.6.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 17
6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17 6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 33 skipping to change at page 3, line 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 29 14.1. Normative References . . . . . . . . . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
As per [RFC4655], the Path Computation Element (PCE) is an entity As per [RFC4655], the Path Computation Element (PCE) is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path network graph and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. computed.
[RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The
PCE has been identified as a suitable application for the computation PCE has been identified as a suitable application for the computation
of paths for P2MP TE LSPs ([RFC5671]). of paths for P2MP TE LSPs ([RFC5671]).
The PCEP is designed as a communication protocol between PCCs and The PCEP is designed as a communication protocol between PCCs and
PCEs for point-to-point (P2P) path computations and is defined in PCEs for point-to-point (P2P) path computations and is defined in
[RFC5440]. The extensions of PCEP to request path computation for [RFC5440]. The extensions of PCEP to request path computation for
P2MP TE LSPs are described in [I-D.ietf-pce-rfc6006bis]. P2MP TE LSPs are described in [RFC8306].
Stateful PCEs are shown to be helpful in many application scenarios, Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in [RFC8051]. These in both MPLS and GMPLS networks, as illustrated in [RFC8051]. These
scenarios apply equally to P2P and P2MP TE LSPs. [RFC8231] provides scenarios apply equally to P2P and P2MP TE LSPs. [RFC8231] provides
the fundamental extensions needed for stateful PCE to support general the fundamental extensions needed for stateful PCE to support general
functionality for P2P TE LSP. [I-D.ietf-pce-pce-initiated-lsp] functionality for P2P TE LSP. [RFC8281] provides the an extensions
provides the an extensions needed for stateful PCE-initiated P2P TE needed for stateful PCE-initiated P2P TE LSP. Complementarily, this
LSP. Complementarily, this document focuses on the extensions that document focuses on the extensions that are necessary in order for
are necessary in order for the deployment of stateful PCEs to support the deployment of stateful PCEs to support P2MP TE LSPs. This
P2MP TE LSPs. This document describes the setup, maintenance and document describes the setup, maintenance and teardown of PCE-
teardown of PCE-initiated P2MP LSPs under the stateful PCE model. initiated P2MP LSPs under the stateful PCE model.
1.1. Requirements Language 1.1. Requirements Language
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
Terminology used in this document is same as terminology used in Terminology used in this document is same as terminology used in
[RFC8231], [I-D.ietf-pce-pce-initiated-lsp], and [RFC8231], [RFC8281], and [RFC8306].
[I-D.ietf-pce-rfc6006bis].
3. Supporting P2MP TE LSP for Stateful PCE 3. Supporting P2MP TE LSP for Stateful PCE
3.1. Motivation 3.1. Motivation
[RFC8051] presents several use cases, demonstrating scenarios that [RFC8051] presents several use cases, demonstrating scenarios that
benefit from the deployment of a stateful PCE including optimization, benefit from the deployment of a stateful PCE including optimization,
recovery, etc which are equally applicable to P2MP TE LSPs. recovery, etc which are equally applicable to P2MP TE LSPs.
[RFC8231] defines the extensions to PCEP for P2P TE LSPs. [RFC8231] defines the extensions to PCEP for P2P TE LSPs.
Complementarily, this document focuses on the extensions that are Complementarily, this document focuses on the extensions that are
necessary in order for the deployment of stateful PCEs to support necessary in order for the deployment of stateful PCEs to support
P2MP TE LSPs. P2MP TE LSPs.
In addition to that, the stateful nature of a PCE simplifies the In addition to that, the stateful nature of a PCE simplifies the
information conveyed in PCEP messages since it is possible to refer information conveyed in PCEP messages since it is possible to refer
to the LSPs via PLSP-ID ([RFC8231]). For P2MP this is an added to the LSPs via PLSP-ID ([RFC8231]). For P2MP this is an added
advantage, where the size of message is much larger. In case of advantage, where the size of message is much larger. In case of
stateless PCE, a modification of P2MP tree requires encoding of all stateless PCE, a modification of P2MP tree requires encoding of all
leaves along with the paths in PCReq message, but using a stateful leaves along with the paths in PCEP message, but using a stateful PCE
PCE with P2MP capability, the PCEP message can be used to convey only with P2MP capability, the PCEP message can be used to convey only the
the modifications (the other information can be retrieved from the modifications (the other information can be retrieved from the P2MP
P2MP LSP identifier in the LSP database (LSPDB)). LSP identifier in the LSP database (LSPDB)).
In environments where the P2MP TE LSP placement needs to change in In environments where the P2MP TE LSP placement needs to change in
response to application demands, it is useful to support dynamic response to application demands, it is useful to support dynamic
creation and tear down of P2MP TE LSPs. The ability for a PCE to creation and tear down of P2MP TE LSPs. The ability for a PCE to
trigger the creation of P2MP TE LSPs on demand can be seamlessly trigger the creation of P2MP TE LSPs on demand can be seamlessly
integrated into a controller-based network architecture, where integrated into a controller-based network architecture, where
intelligence in the controller can determine when and where to set up intelligence in the controller can determine when and where to set up
paths. Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further paths. Section 3 of [RFC8281] further describes the motivation
describes the motivation behind the PCE-Initiation capability, which behind the PCE-Initiation capability, which is equally applicable to
are equally applicable for P2MP TE LSPs. P2MP TE LSPs.
3.2. Objectives 3.2. Objectives
The objectives for the protocol extensions to support P2MP TE LSP for The objectives for the protocol extensions to support P2MP TE LSP for
stateful PCE are same as the objectives described in section 3.2 of stateful PCE are same as the objectives described in section 3.2 of
[RFC8231]. [RFC8231].
4. Functions to Support P2MP TE LSPs for Stateful PCEs 4. Functions to Support P2MP TE LSPs for Stateful PCEs
[RFC8231] specifies new functions to support a stateful PCE. It also [RFC8231] specifies new functions to support a stateful PCE. It also
specifies that a function can be initiated either from a PCC towards specifies that a function can be initiated either from a PCC towards
a PCE (C-E) or from a PCE towards a PCC (E-C). a PCE (C-E) or from a PCE towards a PCC (E-C).
This document extends these functions to support P2MP TE LSPs. This document extends these functions to support P2MP TE LSPs.
Capability Advertisement (E-C,C-E): both the PCC and the PCE must Capability Advertisement (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP announce during PCEP session establishment that they support
Stateful PCE extensions for P2MP using mechanisms defined in Stateful PCE extensions for P2MP using mechanisms defined in
Section 5.2. Section 5.2.
LSP State Synchronization (C-E): after the session between the PCC LSP State Synchronization (C-E): after the session between the PCC
and a stateful PCE with P2MP capability is initialized, the PCE and a stateful PCE with P2MP capability is initialized, the PCE
must learn the state of a PCC's P2MP TE LSPs before it can perform must learn the state of a PCC's P2MP TE LSPs before it can perform
path computations or update LSP attributes in a PCC. path computations or update LSP attributes in a PCC.
LSP Update Request (E-C): a stateful PCE with P2MP capability LSP Update Request (E-C): a stateful PCE with P2MP capability
requests modification of attributes on a PCC's P2MP TE LSP. requests modification of attributes on a PCC's P2MP TE LSP.
skipping to change at page 5, line 46 skipping to change at page 5, line 45
whenever the state of a P2MP TE LSP changes. whenever the state of a P2MP TE LSP changes.
LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to LSP Control Delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more P2MP TE LSPs; the PCE becomes update LSP attributes on one or more P2MP TE LSPs; the PCE becomes
the authoritative source of the LSP's attributes as long as the the authoritative source of the LSP's attributes as long as the
delegation is in effect (See Section 5.7 of [RFC8231]); the PCC delegation is in effect (See Section 5.7 of [RFC8231]); the PCC
may withdraw the delegation or the PCE may give up the delegation may withdraw the delegation or the PCE may give up the delegation
at any time. at any time.
PCE-initiated LSP instantiation (E-C): a PCE sends an LSP Initiate PCE-initiated LSP instantiation (E-C): a PCE sends an LSP Initiate
Message to a PCC to instantiate or delete a P2MP TE LSP. Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281].
5. Architectural Overview of Protocol Extensions 5. Architectural Overview of Protocol Extensions
5.1. Extension of PCEP Messages 5.1. Extension of PCEP Messages
New PCEP messages are defined in [RFC8231] to support stateful PCE New PCEP messages are defined in [RFC8231] to support stateful PCE
for P2P TE LSPs. In this document these messages are extended to for P2P TE LSPs. In this document these messages are extended to
support P2MP TE LSPs. support P2MP TE LSPs.
Path Computation State Report (PCRpt): Each P2MP TE LSP State Report Path Computation State Report (PCRpt): Each P2MP TE LSP State Report
in a PCRpt message can contain actual P2MP TE LSP path attributes, in a PCRpt message can contain actual P2MP TE LSP path attributes,
LSP status, etc. An LSP State Report carried on a PCRpt message LSP status, etc. An LSP State Report carried in a PCRpt message
is also used in delegation or revocation of control of a P2MP TE is also used in delegation or revocation of control of a P2MP TE
LSP to/from a PCE. The extension of PCRpt message is described in LSP to/from a PCE. The extension of PCRpt message is described in
Section 6.1. Section 6.1.
Path Computation Update Request (PCUpd): Each P2MP TE LSP Update Path Computation Update Request (PCUpd): Each P2MP TE LSP Update
Request in a PCUpd message MUST contain all LSP parameters that a Request in a PCUpd message MUST contain all LSP parameters that a
PCE wishes to set for a given P2MP TE LSP. An LSP Update Request PCE wishes to set for a given P2MP TE LSP. An LSP Update Request
carried on a PCUpd message is also used to return LSP delegations carried in a PCUpd message is also used to return LSP delegations
if at any point PCE no longer desires control of a P2MP TE LSP. if at any point PCE no longer desires control of a P2MP TE LSP.
The PCUpd message is described in Section 6.2. The PCUpd message is described in Section 6.2.
A new PCEP message is defined in [I-D.ietf-pce-pce-initiated-lsp] to A PCEP message is defined in [RFC8281] to support stateful PCE
support stateful PCE instantiation of P2P TE LSPs. In this document instantiation of P2P TE LSPs. In this document this message is
this message is extended to support P2MP TE LSPs. extended to support P2MP TE LSPs.
Path Computation LSP Initiate Message (PCInitiate): is a PCEP Path Computation LSP Initiate Message (PCInitiate): is a PCEP
message sent by a PCE to a PCC to trigger P2MP TE LSP message sent by a PCE to a PCC to trigger P2MP TE LSP
instantiation or deletion. The PCInitiate message is described in instantiation or deletion. The PCInitiate message is described in
Section 6.5. Section 6.5.
The path computation request (PCReq) and path computation reply The path computation request (PCReq) and path computation reply
(PCRep) messages are also extended to support stateful PCE for P2P TE (PCRep) messages are also extended to support passive stateful PCE
LSP in [RFC8231]. In this document these messages are extended to for P2P TE LSP in [RFC8231]. In this document these messages are
support P2MP TE LSPs as well. extended to support P2MP TE LSPs as well.
5.2. Capability Advertisement 5.2. Capability Advertisement
During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231], During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231],
PCEP speakers advertises Stateful capability via Stateful PCE PCEP speakers advertises Stateful capability via Stateful PCE
Capability TLV in open message. Two new flags are defined for the Capability TLV in open message. Various flags are defined for the
STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in
[I-D.ietf-pce-pce-initiated-lsp] and [RFC8232]. [RFC8281] and [RFC8232].
Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY),
and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document:
N (P2MP-CAPABILITY bit - TBD4): if set to 1 by a PCC, the N Flag N (P2MP-CAPABILITY bit - TBD4): if set to 1 by a PCC, the N Flag
indicates that the PCC is willing to send P2MP LSP State Reports indicates that the PCC is willing to send P2MP LSP State Reports
whenever P2MP LSP parameters or operational status changes.; if whenever P2MP LSP parameters or operational status changes.; if
set to 1 by a PCE, the N Flag indicates that the PCE is interested set to 1 by a PCE, the N Flag indicates that the PCE is interested
in receiving LSP State Reports whenever LSP parameters or in receiving LSP State Reports whenever LSP parameters or
operational status changes. The P2MP-CAPABILITY Flag must be operational status changes. The P2MP-CAPABILITY Flag must be
skipping to change at page 7, line 29 skipping to change at page 7, line 25
for PCUpd messages P2MP extension to be allowed on a PCEP session. for PCUpd messages P2MP extension to be allowed on a PCEP session.
P (P2MP-LSP-INSTANTIATION-CAPABILITY bit - TBD6): If set to 1 by a P (P2MP-LSP-INSTANTIATION-CAPABILITY bit - TBD6): If set to 1 by a
PCC, the P Flag indicates that the PCC allows instantiation of an PCC, the P Flag indicates that the PCC allows instantiation of an
P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates
that the PCE supports P2MP LSP instantiation. The P2MP-LSP- that the PCE supports P2MP LSP instantiation. The P2MP-LSP-
INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in
order to support PCE-initiated P2MP LSP instantiation. order to support PCE-initiated P2MP LSP instantiation.
A PCEP speaker should continue to advertise the basic P2MP capability A PCEP speaker should continue to advertise the basic P2MP capability
via mechanisms as described in [I-D.ietf-pce-rfc6006bis]. via mechanisms as described in [RFC8306].
5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the consists of utilizing IGP advertisements. Extensions for the
advertisement of PCE Discovery Information are defined for OSPF and advertisement of PCE Discovery Information are defined for OSPF and
for IS-IS in [RFC5088] and [RFC5089] respectively. for IS-IS in [RFC5088] and [RFC5089] respectively.
skipping to change at page 8, line 26 skipping to change at page 8, line 23
Note that while active, passive or initiation stateful PCE with P2MP Note that while active, passive or initiation stateful PCE with P2MP
capabilities may be advertised during discovery, PCEP Speakers that capabilities may be advertised during discovery, PCEP Speakers that
wish to use stateful PCEP MUST advertise stateful PCEP capabilities wish to use stateful PCEP MUST advertise stateful PCEP capabilities
during PCEP session setup, as specified in the current document. A during PCEP session setup, as specified in the current document. A
PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP
session setup even if it did not receive any IGP PCE capability session setup even if it did not receive any IGP PCE capability
advertisements. advertisements.
5.4. State Synchronization 5.4. State Synchronization
State Synchronization operations described in Section 5.6 of State Synchronization operations (described in Section 5.6 of
[RFC8231] are applicable for P2MP TE LSPs as well. The optimizations [RFC8231]) are applicable for the P2MP TE LSPs as well. The
described in [RFC8232] can also be applied for P2MP. optimizations described in [RFC8232] can also be applied for P2MP TE
LSPs.
5.5. LSP Delegation 5.5. LSP Delegation
LSP delegation operations described in Section 5.7 of [RFC8231] are LSP delegation operations (described in Section 5.7 of [RFC8231]) are
applicable for P2MP TE LSPs as well. applicable for P2MP TE LSPs as well.
5.6. LSP Operations 5.6. LSP Operations
5.6.1. Passive Stateful PCE 5.6.1. Passive Stateful PCE
LSP operations for passive stateful PCE described in Section 5.8.1 of LSP operations for passive stateful PCE (described in Section 5.8.1
[RFC8231] are applicable for P2MP TE LSPs as well. of [RFC8231]) are applicable for P2MP TE LSPs as well.
The Path Computation Request and Response message format for P2MP TE The PCReq and PCRep message format for P2MP TE LSPs is described in
LSPs is described in Section 3.4 and Section 3.5 of Section 3.4 and Section 3.5 of [RFC8306] respectively.
[I-D.ietf-pce-rfc6006bis] respectively.
The Request and Response message for P2MP TE LSPs are extended to The PCReq and PCRep message for P2MP TE LSPs are extended to support
support encoding of LSP object, so that it is possible to refer to a encoding of LSP object, so that it is possible to refer to a LSP with
LSP with a unique identifier and simplify the PCEP message exchange. a unique identifier and simplify the PCEP message exchange. For
For example, in case of modification of one leaf in a P2MP tree, example, in case of modification of one leaf in a P2MP tree, there
there should be no need to carry the full P2MP tree in PCReq message. should be no need to carry the full P2MP tree in PCReq message.
The extension for the Request and Response message for passive The extension for the Request and Response message for passive
stateful operations on P2MP TE LSPs are described in Section 6.3 and stateful operations on P2MP TE LSPs are described in Section 6.3 and
Section 6.4. The extension for the Path Computation LSP State Report Section 6.4. The extension for the Path Computation LSP State Report
(PCRpt) message is described in Section 6.1. (PCRpt) message is described in Section 6.1.
5.6.2. Active Stateful PCE 5.6.2. Active Stateful PCE
LSP operations for active stateful PCE described in Section 5.8.2 of LSP operations for active stateful PCE (described in Section 5.8.2 of
[RFC8231] are applicable for P2MP TE LSPs as well. [RFC8231]) are applicable for P2MP TE LSPs as well.
The extension for the Path Computation LSP Update (PCUpd) message for The extension for the Path Computation LSP Update (PCUpd) message for
active stateful operations on P2MP TE LSPs are described in active stateful operations on P2MP TE LSPs are described in
Section 6.2. Section 6.2.
5.6.3. PCE-Initiated LSP 5.6.3. PCE-Initiated LSP
As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends As per section 5.1 of [RFC8281], the PCE sends a Path Computation LSP
a Path Computation LSP Initiate Request (PCInitiate) message to the Initiate Request (PCInitiate) message to the PCC to suggest
PCC to suggest instantiation or deletion of a P2P TE LSP. This instantiation or deletion of a P2P TE LSP. This document extends the
document extends the PCInitiate message to support P2MP TE LSP (see PCInitiate message to support P2MP TE LSP (see details in
details in Section 6.5). Section 6.5).
P2MP TE LSP suggested instantiation and deletion operations are same The P2MP TE LSP suggested instantiation and deletion operations are
as P2P LSP as described in section 5.3 and 5.4 of same as P2P LSP as described in section 5.3 and 5.4 of [RFC8281].
[I-D.ietf-pce-pce-initiated-lsp].
5.6.3.1. P2MP TE LSP Instantiation 5.6.3.1. P2MP TE LSP Instantiation
The Instantiation operation of P2MP TE LSP is same as defined in The Instantiation operation of P2MP TE LSP is same as defined in
section 5.3 of [I-D.ietf-pce-pce-initiated-lsp] including handling of section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC-
PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error PATH-NAME TLV etc. Rules of processing and error codes remains
codes remains unchanged. The N bit MUST be set in LSP object in unchanged. The N (P2MP) bit (Section 7.1) MUST be set in LSP object
PCInitiate message by PCE to specify the instantiation is for P2MP TE in PCInitiate message by PCE to specify the instantiation is for P2MP
LSP. TE LSP. Like the PLSP-ID as per [RFC8281], the P2MP-LSP-IDENTIFIER
TLV SHOULD NOT be included in the LSP object in PCIntiitate message
Though N bit is set in the LSP object, P2MP-LSP-IDENTIFIER TLV MUST (as it is generated by PCC and carried in PCRpt message instead) and
NOT be included in the LSP object in PCIntiitate message as it SHOULD MUST be ignored on receipt.
be generated by PCC and carried in PCRpt message.
5.6.3.2. P2MP TE LSP Deletion 5.6.3.2. P2MP TE LSP Deletion
The deletion operation of P2MP TE LSP is same as defined in section The deletion operation of P2MP TE LSP is same as defined in section
5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 5.4 of [RFC8281] by sending an LSP Initiate Message with an LSP
Message with an LSP object carrying the PLSP-ID of the LSP to be object carrying the PLSP-ID of the LSP to be removed and an SRP
removed and an SRP object with the R flag set (LSP-REMOVE as per object with the R flag set (LSP-REMOVE as per section 5.2 of
section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of [RFC8281]). Rules of processing and error codes remains unchanged.
processing and error codes remains unchanged.
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP
Adding of new leaves and Pruning of old Leaves for the PCE initiated Adding of new leaves and Pruning of old Leaves for the PCE initiated
P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for
P2MP TE LSP extensions. As defined in [I-D.ietf-pce-rfc6006bis], P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 for
leaf type = 1 for adding of new leaves, leaf type = 2 for pruning of adding of new leaves, leaf type = 2 for pruning of old leaves of P2MP
old leaves of P2MP END-POINTS Object are used in PCUpd message. END-POINTS Object are used in PCUpd message.
PCC MAY use the Incremental State Update mechanism as described in PCC MAY use the Incremental State Update mechanism as described in
[RFC4875] to signal adding and pruning of leaves. [RFC4875] to signal adding and pruning of leaves.
5.6.3.4. P2MP TE LSP Delegation and Cleanup 5.6.3.4. P2MP TE LSP Delegation and Cleanup
P2MP TE LSP delegation and cleanup operations are same as defined in P2MP TE LSP delegation and cleanup operations are same as defined in
section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing section 6 of [RFC8281]. Rules of processing and error codes remains
and error codes remains unchanged. unchanged.
6. PCEP Message Extensions 6. PCEP Message Extensions
6.1. The PCRpt Message 6.1. The PCRpt Message
As per Section 6.1 of [RFC8231], PCRpt message is used to report the As per Section 6.1 of [RFC8231], PCRpt message is used to report the
current state of a P2P TE LSP. This document extends the PCRpt current state of a P2P TE LSP. This document extends the PCRpt
message in reporting the status of P2MP TE LSP. message in reporting the status of P2MP TE LSP.
The format of PCRpt message is as follows: The format of PCRpt message is as follows:
skipping to change at page 11, line 44 skipping to change at page 11, line 44
<actual-path> ::= (<RRO>|<SRRO>) <actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>] [<actual-path>]
<intended-attribute-list> is defined in [RFC5440] and <intended-attribute-list> is defined in [RFC5440] and
extended by PCEP extensions. extended by PCEP extensions.
<actual-attribute-list> consists of the actual computed and <actual-attribute-list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists> signaled values of the <BANDWIDTH> and <metric-lists>
objects defined in [RFC5440]. objects defined in [RFC5440].
The P2MP END-POINTS object defined in [I-D.ietf-pce-rfc6006bis] is The P2MP END-POINTS object defined in [RFC8306] is mandatory for
mandatory for specifying address of P2MP leaves grouped based on leaf specifying address of P2MP leaves grouped based on leaf types.
types.
o New leaves to add (leaf type = 1) o New leaves to add (leaf type = 1)
o Old leaves to remove (leaf type = 2) o Old leaves to remove (leaf type = 2)
o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o Old leaves whose path must be left unchanged (leaf type = 4) o Old leaves whose path must be left unchanged (leaf type = 4)
When reporting the status of a P2MP TE LSP, the destinations are When reporting the status of a P2MP TE LSP, the destinations are
grouped in END-POINTS object based on the operational status (O field grouped in END-POINTS object based on the operational status (O field
in S2LS object) and leaf type (in END-POINTS). This way the leaves in S2LS object) and leaf type (in END-POINTS). This way the leaves
that share the same operational status are grouped together. For that share the same operational status are grouped together. For
reporting the status of delegated P2MP TE LSP, leaf-type = 3, where reporting the status of delegated P2MP TE LSP leaf-type = 3 is used,
as for non-delegated P2MP TE LSP, leaf-type = 4 is used. where as for non-delegated P2MP TE LSP, leaf-type = 4 is used.
For delegated P2MP TE LSP configuration changes are reported via For delegated P2MP TE LSP configuration changes are reported via
PCRpt message. For example, adding of new leaves END-POINTS (leaf- PCRpt message. For example, adding of new leaves END-POINTS (leaf-
type = 1) is used where as removing of old leaves (leaf-type = 2) is type = 1) is used where as removing of old leaves (leaf-type = 2) is
used. used.
Note that we preserve compatibility with the [RFC8231] definition of Note that the compatibility with the [RFC8231] definition of <state-
<state-report>. At least one instance of <END-POINTS> MUST be report> is preserved. At least one instance of <END-POINTS> MUST be
present in this message for P2MP LSP. present in this message for P2MP LSP.
During state synchronization, the PCRpt message must report the During state synchronization, the PCRpt message reports the status of
status of the full P2MP TE LSP. the full P2MP TE LSP.
The S2LS object MUST be carried in PCRpt message along with END- The S2LS object MUST be carried in PCRpt message along with END-
POINTS object when N bit is set in LSP object for P2MP TE LSP. If POINTS object when N (P2MP) bit is set in LSP object for P2MP TE LSP.
the S2LS object is missing, the receiving PCE MUST send a PCErr If the S2LS object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error- message with Error-type=6 (Mandatory Object missing) and Error-
value=TBD11 (S2LS object missing). If the END-POINTS object is value=TBD11 (S2LS object missing). If the END-POINTS object is
missing, the receiving PCE MUST send a PCErr message with Error- missing, the receiving PCE MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS
object missing) (defined in [RFC5440]. object missing) (defined in [RFC5440].
6.2. The PCUpd Message 6.2. The PCUpd Message
As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P
TE LSP attributes. This document extends the PCUpd message in TE LSP attributes. This document extends the PCUpd message in
skipping to change at page 13, line 31 skipping to change at page 13, line 31
[<END-POINTS>] [<END-POINTS>]
<intended-path> <intended-path>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>) <intended-path> ::= (<ERO>|<SERO>)
[<intended-path>] [<intended-path>]
<attribute-list> is defined in [RFC5440] and <attribute-list> is defined in [RFC5440] and
extended by PCEP extensions. extended by PCEP extensions.
Note that we preserve compatibility with the [RFC8231] definition of Note that the compatibility with the [RFC8231] definition of <update-
<update-request>. request> is preserved.
The PCC MAY use the make-before-break or sub-group-based procedures The PCC SHOULD use the make-before-break or sub-group-based
described in [RFC4875] based on a local policy decision. procedures described in [RFC4875] based on a local policy decision.
The END-POINTS object MUST be carried in PCUpd message when N bit is The END-POINTS object MUST be carried in PCUpd message when N bit is
set in LSP object for P2MP TE LSP. If the END-POINTS object is set in LSP object for P2MP TE LSP. If the END-POINTS object is
missing, the receiving PCC MUST send a PCErr message with Error- missing, the receiving PCC MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS
object missing) (defined in [RFC5440]. object missing) (defined in [RFC5440].
6.3. The PCReq Message 6.3. The PCReq Message
As per Section 3.4 of [I-D.ietf-pce-rfc6006bis], PCReq message is As per Section 3.4 of [RFC8306], PCReq message is used for a P2MP
used for a P2MP path computation request. This document extends the path computation request. This document extends the PCReq message
PCReq message such that a PCC MAY include the LSP object in the PCReq such that a PCC MAY include the LSP object in the PCReq message if
message if the stateful PCE P2MP capability has been negotiated on a the stateful PCE P2MP capability has been negotiated on a PCEP
PCEP session between the PCC and a PCE. session between the PCC and a PCE.
The format of PCReq message is as follows: The format of PCReq message is as follows:
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
where: where:
<svec-list>::= <SVEC> <svec-list>::= <SVEC>
skipping to change at page 14, line 37 skipping to change at page 14, line 37
<end-point-rro-pair-list>::= <END-POINTS> <end-point-rro-pair-list>::= <END-POINTS>
[<RRO-List>[<BANDWIDTH>]] [<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>] [<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>] <RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>] <metric-list>::=<METRIC>[<metric-list>]
6.4. The PCRep Message 6.4. The PCRep Message
As per Section 3.5 of [I-D.ietf-pce-rfc6006bis], PCRep message is As per Section 3.5 of [RFC8306], PCRep message is used for a P2MP
used for a P2MP path computation reply. This document extends the path computation reply. This document extends the PCRep message such
PCRep message such that a PCE MAY include the LSP object in the PCRep that a PCE MAY include the LSP object in the PCRep message if the
message if the stateful PCE P2MP capability has been negotiated on a stateful PCE P2MP capability has been negotiated on a PCEP session
PCEP session between the PCC and a PCE. between the PCC and a PCE.
The format of PCRep message is as follows: The format of PCRep message is as follows:
<PCRep Message>::= <Common Header> <PCRep Message>::= <Common Header>
<response-list> <response-list>
where: where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
skipping to change at page 15, line 33 skipping to change at page 15, line 33
<path> ::= (<ERO>|<SERO>) [<path>] <path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>] <attribute-list>::=[<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>] [<IRO>]
6.5. The PCInitiate message 6.5. The PCInitiate message
As defined in section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], PCE As defined in section 5.1 of [RFC8281], PCE sends a PCInitiate
sends a PCInitiate message to a PCC to recommend instantiation of a message to a PCC to recommend instantiation of a P2P TE LSP, this
P2P TE LSP, this document extends the format of PCInitiate message document extends the format of PCInitiate message for the creation of
for the creation of P2MP TE LSPs but the creation and deletion P2MP TE LSPs but the creation and deletion operations of P2MP TE LSP
operations of P2MP TE LSP are same to the P2P TE LSP. are same to the P2P TE LSP.
The format of PCInitiate message is as follows: The format of PCInitiate message is as follows:
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>] [<PCE-initiated-lsp-list>]
skipping to change at page 18, line 40 skipping to change at page 18, line 40
7.1. Extension of LSP Object 7.1. Extension of LSP Object
LSP Object is defined in Section 7.3 of [RFC8231]. It specifies LSP Object is defined in Section 7.3 of [RFC8231]. It specifies
PLSP-ID to uniquely identify an LSP that is constant for the life PLSP-ID to uniquely identify an LSP that is constant for the life
time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify
a P2MP TE LSP uniquely. This document adds the following flags to a P2MP TE LSP uniquely. This document adds the following flags to
the LSP Object: the LSP Object:
N (P2MP bit - TBD7): If the bit is set to 1, it specifies the N (P2MP bit - TBD7): If the bit is set to 1, it specifies the
message is for P2MP TE LSP which MUST be set in PCRpt or PCUpd message is for P2MP TE LSP which MUST be set in PCRpt, PCUpd, or
message for a P2MP TE LSP. PCInitiate message for a P2MP TE LSP.
F (Fragmentation bit - TBD8): If the bit is set to 1, it specifies F (Fragmentation bit - TBD8): If the bit is set to 1, it specifies
the message is fragmented. the message is fragmented.
If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be
present in LSP object. present in LSP object.
7.2. P2MP-LSP-IDENTIFIER TLV 7.2. P2MP-LSP-IDENTIFIER TLV
The P2MP LSP Identifier TLV MUST be included in the LSP object in The P2MP LSP Identifier TLV MUST be included in the LSP object in
skipping to change at page 21, line 26 skipping to change at page 21, line 26
Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.2 for the identifier defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. P2MP ID: As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV.
Tunnel ID remains constant over the life time of a tunnel. Tunnel ID remains constant over the life time of a tunnel.
7.3. S2LS Object 7.3. S2LS Object
The S2LS (Source-to-Leaves) Object is used to report RSVP-TE state of The S2LS (Source-to-Leaves) Object is used to report state of one or
one or more destinations (leaves) encoded within the END-POINTS more destinations (leaves) encoded within the END-POINTS object for a
object for a P2MP TE LSP. It MUST be carried in PCRpt message along P2MP TE LSP. It MUST be carried in PCRpt message along with END-
with END-POINTS object when N bit is set in LSP object. POINTS object when N bit is set in LSP object.
S2LS Object-Class is TBD19. S2LS Object-Class is TBD19.
S2LS Object-Types is 1. S2LS Object-Types is 1.
The format of the S2LS object is shown in the following figure: The format of the S2LS object is shown in the following figure:
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 22, line 32 skipping to change at page 22, line 32
not fit into a single PCEP message (e.g. initial report or update). not fit into a single PCEP message (e.g. initial report or update).
The F-bit is used in the LSP object to signal that the initial The F-bit is used in the LSP object to signal that the initial
report, update, or initiate message was too large to fit into a report, update, or initiate message was too large to fit into a
single message and will be fragmented into multiple messages. In single message and will be fragmented into multiple messages. In
order to identify the single report or update each message will use order to identify the single report or update each message will use
the same PLSP-ID. In order to identify that a series of PCInitiate the same PLSP-ID. In order to identify that a series of PCInitiate
messages represents a single Initiate, each message will use the same messages represents a single Initiate, each message will use the same
PLSP-ID (in this case 0) and SRP-ID-number. PLSP-ID (in this case 0) and SRP-ID-number.
Fragmentation procedure described below for report or update message Fragmentation procedure described below for report or update message
is similar to [I-D.ietf-pce-rfc6006bis] which describes request and is similar to [RFC8306] which describes request and response message
response message fragmentation. fragmentation.
8.1. Report Fragmentation Procedure 8.1. Report Fragmentation Procedure
If the initial report is too large to fit into a single report If the initial report is too large to fit into a single report
message, the PCC will split the report over multiple messages. Each message, the PCC will split the report over multiple messages. Each
message sent to the PCE, except the last one, will have the F-bit set message sent to the PCE, except the last one, will have the F-bit set
in the LSP object to signify that the report has been fragmented into in the LSP object to signify that the report has been fragmented into
multiple messages. In order to identify that a series of report multiple messages. In order to identify that a series of report
messages represents a single report, each message will use the same messages represents a single report, each message will use the same
PLSP-ID. PLSP-ID.
skipping to change at page 24, line 18 skipping to change at page 24, line 18
SHOULD generate a PCErr with error-type 19 (Invalid Operation), SHOULD generate a PCErr with error-type 19 (Invalid Operation),
error-value TBD16 (Attempted LSP State Report for P2MP if stateful error-value TBD16 (Attempted LSP State Report for P2MP if stateful
PCE capability for P2MP was not advertised) and it will terminate the PCE capability for P2MP was not advertised) and it will terminate the
PCEP session. PCEP session.
If a Stateful PCE receives a P2MP TE LSP report message and the PCE If a Stateful PCE receives a P2MP TE LSP report message and the PCE
does not understand the P2MP flag in the LSP object, and therefore does not understand the P2MP flag in the LSP object, and therefore
the PCEP extensions described in this document, then the Stateful PCE the PCEP extensions described in this document, then the Stateful PCE
would act as per [RFC8231]. would act as per [RFC8231].
The PCEP protocol extensions described in this document for PCC or The PCEP extensions described in this document for PCC or PCE with
PCE with instantiation capability for P2MP TE LSPs MUST NOT be used instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or
if PCC or PCE has not advertised its stateful capability with PCE has not advertised its stateful capability with Instantiation and
Instantiation and P2MP capability as per Section 5.2. If the PCEP P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC
Speaker on the PCC supports the extensions of this draft (understands supports the extensions of this draft (understands the P (P2MP-LSP-
the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but INSTANTIATION-CAPABILITY) flag) but did not advertise this
did not advertise this capability, then upon receipt of PCInitiate capability, then upon receipt of PCInitiate message from the PCE, it
message from the PCE, it SHOULD generate a PCErr with error-type 19 SHOULD generate a PCErr with error-type 19 (Invalid Operation),
(Invalid Operation), error-value TBD18 (Attempted LSP Instantiation error-value TBD18 (Attempted LSP Instantiation Request for P2MP if
Request for P2MP if stateful PCE instantiation capability for P2MP stateful PCE instantiation capability for P2MP was not advertised).
was not advertised).
10. Manageability Considerations 10. Manageability Considerations
All manageability requirements and considerations listed in All manageability requirements and considerations listed in
[RFC5440], [I-D.ietf-pce-rfc6006bis], [RFC8231], and [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP protocol
[I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol extensions extensions defined in this document. In addition, requirements and
defined in this document. In addition, requirements and
considerations listed in this section apply. considerations listed in this section apply.
10.1. Control of Function and Policy 10.1. Control of Function and Policy
A PCE or PCC implementation MUST allow configuring the stateful PCEP A PCE or PCC implementation MUST allow configuring the stateful PCEP
capability, the LSP Update capability, and the LSP Initiation capability, the LSP Update capability, and the LSP Initiation
capability for P2MP LSPs. capability for P2MP LSPs.
10.2. Information and Data Models 10.2. Information and Data Models
skipping to change at page 25, line 15 skipping to change at page 25, line 15
10.3. Liveness Detection and Monitoring 10.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].
10.4. Verify Correct Operations 10.4. Verify 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], [I-D.ietf-pce-rfc6006bis], [RFC8231], and [RFC5440], [RFC8306], [RFC8231], and [RFC8281].
[I-D.ietf-pce-pce-initiated-lsp].
10.5. Requirements On Other Protocols 10.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.
10.6. Impact On Network Operations 10.6. Impact On Network Operations
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],
[I-D.ietf-pce-rfc6006bis], [RFC8231], and [RFC8306], [RFC8231], and [RFC8281].
[I-D.ietf-pce-pce-initiated-lsp].
Stateful PCE feature for P2MP LSP would help with network operations. Stateful PCE feature for P2MP LSP would help with network operations.
11. IANA Considerations 11. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA actions to allocate code points for the
protocol elements defined in this document. protocol elements defined in this document.
11.1. PCE Capabilities in IGP Advertisements 11.1. PCE Capabilities in IGP Advertisements
skipping to change at page 27, line 9 skipping to change at page 27, line 9
11.4. PCEP-Error Object 11.4. PCEP-Error Object
IANA is requested to allocate new error values within the "PCEP-ERROR IANA is requested to allocate new error values within the "PCEP-ERROR
Object Error Types and Values" sub-registry of the PCEP Numbers Object Error Types and Values" sub-registry of the PCEP Numbers
registry, as follows: registry, as follows:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing [RFC5440] 6 Mandatory Object missing [RFC5440]
Error-value=TBD11: S2LS object missing Error-value=TBD11: S2LS object missing
Error-value=TBD12: P2MP-LSP-IDENTIFIER TLV missing Error-value=TBD12: P2MP-LSP-IDENTIFIER TLV missing
18 P2MP Fragmentation Error [I-D.ietf-pce-rfc6006bis] 18 P2MP Fragmentation Error [RFC8306]
Error-value= TBD13. Fragmented Report Error-value= TBD13. Fragmented Report
failure failure
Error-value= TBD14. Fragmented Update Error-value= TBD14. Fragmented Update
failure failure
Error-value= TBD15. Fragmented Instantiation Error-value= TBD15. Fragmented Instantiation
failure failure
19 Invalid Operation [RFC8231] 19 Invalid Operation [RFC8231]
Error-value= TBD16. Attempted LSP State Report Error-value= TBD16. Attempted LSP State Report
for P2MP if stateful PCE capability for P2MP if stateful PCE capability
for P2MP was not advertised for P2MP was not advertised
skipping to change at page 28, line 39 skipping to change at page 28, line 39
29-31 Operational (3-bit) [This.I-D] 29-31 Operational (3-bit) [This.I-D]
12. Security Considerations 12. Security Considerations
The stateful operations on P2MP TE LSP are more CPU-intensive and The stateful operations on P2MP TE LSP are more CPU-intensive and
also utilize more bandwidth on wire. In the event of an unauthorized also utilize more bandwidth on wire. In the event of an unauthorized
stateful P2MP operations, or a denial of service attack, the stateful P2MP operations, or a denial of service attack, the
subsequent PCEP operations may be disruptive to the network. subsequent PCEP operations may be disruptive to the network.
Consequently, it is important that implementations conform to the Consequently, it is important that implementations conform to the
relevant security requirements of [RFC5440], relevant security requirements of [RFC5440], [RFC8306] and [RFC8231],
[I-D.ietf-pce-rfc6006bis] and [RFC8231], and and [RFC8281].
[I-D.ietf-pce-pce-initiated-lsp]. Further [RFC8253] discusses an
enhanced approach to provide secure transport for PCEP via Transport As stated in [RFC6952], PCEP implementations SHOULD support the TCP-
Layer Security (TLS). AO [RFC5925] and not use TCP MD5 because of TCP MD5's known
vulnerabilities and weakness. PCEP also support Transport Layer
Security (TLS) [RFC8253] as per the recommendations and best current
practices in [RFC7525].
13. Acknowledgments 13. Acknowledgments
Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his
comments. comments.
14. References 14. References
14.1. Normative References 14.1. Normative References
skipping to change at page 30, line 11 skipping to change at page 30, line 11
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232, Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017, DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>. <https://www.rfc-editor.org/info/rfc8232>.
[I-D.ietf-pce-pce-initiated-lsp] [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "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", draft-ietf-pce-pce-initiated-lsp-11 (work in Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
progress), October 2017. <https://www.rfc-editor.org/info/rfc8281>.
[I-D.ietf-pce-rfc6006bis] [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
Zhao, Q., Dhody, D., Palleti, R., and D. King, "Extensions "Extensions to the Path Computation Element Communication
to the Path Computation Element Communication Protocol Protocol (PCEP) for Point-to-Multipoint Traffic
(PCEP) for Point-to-Multipoint Traffic Engineering Label Engineering Label Switched Paths", RFC 8306,
Switched Paths", draft-ietf-pce-rfc6006bis-04 (work in DOI 10.17487/RFC8306, November 2017,
progress), September 2017. <https://www.rfc-editor.org/info/rfc8306>.
14.2. Informative References 14.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
Element (PCE)-Based Architecture", RFC 4655, 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>.
[RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 [RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
Regional Registration", RFC 4857, DOI 10.17487/RFC4857, Regional Registration", RFC 4857, DOI 10.17487/RFC4857,
skipping to change at page 30, line 48 skipping to change at page 30, line 48
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009, DOI 10.17487/RFC5671, October 2009,
<https://www.rfc-editor.org/info/rfc5671>. <https://www.rfc-editor.org/info/rfc5671>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j. Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
jefftant@gmail.com, "A YANG Data Model for Path YANG Data Model for Path Computation Element
Computation Element Communications Protocol (PCEP)", Communications Protocol (PCEP)", draft-ietf-pce-pcep-
draft-ietf-pce-pcep-yang-05 (work in progress), June 2017. yang-06 (work in progress), January 2018.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Granpark Tower Granpark Tower
3-4-1 Shibaura, Minato-ku 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118 Tokyo 108-8118
Japan Japan
 End of changes. 61 change blocks. 
163 lines changed or deleted 172 lines changed or added

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