draft-ietf-pce-stateful-pce-p2mp-01.txt   draft-ietf-pce-stateful-pce-p2mp-02.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 2, 2017 Y. Tanaka Expires: September 13, 2017 Y. Tanaka
NTT Communications NTT Communications
Z. Ali
Cisco Systems
V. Beeram V. Beeram
Juniper Networks Juniper Networks
October 29, 2016 March 12, 2017
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-01 draft-ietf-pce-stateful-pce-p2mp-02
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 LSPs. This document provides extensions
required for Path Computation Element communication Protocol (PCEP) required for Path Computation Element communication Protocol (PCEP)
so as to enable the usage of a stateful PCE capability in supporting so as to enable the usage of a stateful PCE capability in supporting
P2MP TE LSPs. P2MP TE LSPs.
skipping to change at page 1, line 42 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 2, 2017. This Internet-Draft will expire on September 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 37 skipping to change at page 2, line 33
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 . . 9 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
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 21 skipping to change at page 3, line 19
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 25 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 25
10.5. Requirements On Other Protocols . . . . . . . . . . . . 25 10.5. Requirements On Other Protocols . . . . . . . . . . . . 25
10.6. Impact On Network Operations . . . . . . . . . . . . . . 25 10.6. Impact On Network Operations . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 25 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 25
11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26
11.3. Extension of LSP Object . . . . . . . . . . . . . . . . 26 11.3. Extension of LSP Object . . . . . . . . . . . . . . . . 26
11.4. Extension of PCEP-Error Object . . . . . . . . . . . . . 26 11.4. Extension of PCEP-Error Object . . . . . . . . . . . . . 26
11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
14.2. Informative References . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Contributor 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.palleti-pce-rfc6006bis]. P2MP TE LSPs are described in [I-D.ietf-pce-rfc6006bis].
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 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. These
[I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to scenarios apply equally to P2P and P2MP TE LSPs.
P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the [I-D.ietf-pce-stateful-pce] provides the fundamental extensions
fundamental extensions needed for stateful PCE to support general needed for stateful PCE to support general functionality for P2P TE
functionality for P2P TE LSP. [I-D.ietf-pce-pce-initiated-lsp] LSP. [I-D.ietf-pce-pce-initiated-lsp] 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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
[I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and [I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and
[I-D.palleti-pce-rfc6006bis]. [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
[I-D.ietf-pce-stateful-pce-app] presents several use cases, [RFC8051] presents several use cases, demonstrating scenarios that
demonstrating scenarios that benefit from the deployment of a benefit from the deployment of a stateful PCE including optimization,
stateful PCE including optimization, recovery, etc which are equally recovery, etc which are equally applicable to P2MP TE LSPs.
applicable to P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] defines the [I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE
extensions to PCEP for P2P TE LSPs. Complementarily, this document LSPs. Complementarily, this document focuses on the extensions that
focuses on the extensions that are necessary in order for the are necessary in order for the deployment of stateful PCEs to support
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 ([I-D.ietf-pce-stateful-pce]). For P2MP this to the LSPs via PLSP-ID ([I-D.ietf-pce-stateful-pce]). For P2MP this
is an added advantage, where the size of message is much larger. is an added advantage, where the size of message is much larger.
Incase of stateless PCE, a modification of P2MP tree requires Incase of stateless PCE, a modification of P2MP tree requires
encoding of all leaves along with the paths in PCReq message, but encoding of all leaves along with the paths in PCReq message, but
using a stateful PCE with P2MP capability, the PCEP message can be using a stateful PCE with P2MP capability, the PCEP message can be
used to convey only the modifications (the other information can be used to convey only the modifications (the other information can be
retrieved from the P2MP LSP identifier in the LSP database (LSPDB)). retrieved from the P2MP LSP identifier in the LSP database (LSPDB)).
skipping to change at page 6, line 36 skipping to change at page 6, line 36
A new PCEP message is defined in [I-D.ietf-pce-pce-initiated-lsp] to A new PCEP message is defined in [I-D.ietf-pce-pce-initiated-lsp] to
support stateful PCE instantiation of P2P TE LSPs. In this document support stateful PCE instantiation of P2P TE LSPs. In this document
this message is extended to support P2MP TE LSPs. this message is 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
(PCRep) messages are also extended to support stateful PCE for P2P TE
LSP in [I-D.ietf-pce-stateful-pce]. In this document these messages
are 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 During PCEP Initialization Phase, as per Section 7.1.1 of
[I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful [I-D.ietf-pce-stateful-pce], PCEP speakers advertises Stateful
capability via Stateful PCE Capability TLV in open message. Two new capability via Stateful PCE Capability TLV in open message. Two new
flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in
[I-D.ietf-pce-stateful-pce] and updated in [I-D.ietf-pce-stateful-pce] and updated in
[I-D.ietf-pce-pce-initiated-lsp] and [I-D.ietf-pce-pce-initiated-lsp] and
[I-D.ietf-pce-stateful-sync-optimizations]. [I-D.ietf-pce-stateful-sync-optimizations].
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 - 1 bit): 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
advertised by both a PCC and a PCE for PCRpt messages P2MP advertised by both a PCC and a PCE for PCRpt messages P2MP
extension to be allowed on a PCEP session. extension to be allowed on a PCEP session.
M (P2MP-LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the M M (P2MP-LSP-UPDATE-CAPABILITY bit - TBD5): if set to 1 by a PCC, the
Flag indicates that the PCC allows modification of P2MP LSP M Flag indicates that the PCC allows modification of P2MP LSP
parameters; if set to 1 by a PCE, the M Flag indicates that the parameters; if set to 1 by a PCE, the M Flag indicates that the
PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- PCE is capable of updating P2MP LSP parameters. The P2MP-LSP-
UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE
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 - 1 bit): If set to 1 by a PCC, P (P2MP-LSP-INSTANTIATION-CAPABILITY bit - TBD6): If set to 1 by a
the P Flag indicates that the PCC allows instantiation of an P2MP PCC, the P Flag indicates that the PCC allows instantiation of an
LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates
PCE supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION- that the PCE supports P2MP LSP instantiation. The P2MP-LSP-
CAPABILITY flag must be set by both PCC and PCE in order to INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in
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.palleti-pce-rfc6006bis]. via mechanisms as described in [I-D.ietf-pce-rfc6006bis].
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 9 skipping to change at page 8, line 12
Length: Multiple of 4. Length: Multiple of 4.
Value: This contains an array of units of 32 bit flags with the most Value: This contains an array of units of 32 bit flags with the most
significant bit as 0. Each bit represents one PCE capability. significant bit as 0. Each bit represents one PCE capability.
PCE capability bits are defined in [RFC5088]. This document defines PCE capability bits are defined in [RFC5088]. This document defines
new capability bits for the stateful PCE with P2MP as follows: new capability bits for the stateful PCE with P2MP as follows:
Bit Capability Bit Capability
TBD Active Stateful PCE with P2MP TBD1 Active Stateful PCE with P2MP
TBD Passive Stateful PCE with P2MP TBD2 Passive Stateful PCE with P2MP
TBD PCE-Initiation with P2MP TBD3 PCE-Initiation with P2MP
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
[I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
The optimizations described in
[I-D.ietf-pce-stateful-sync-optimizations] can also be applied for
P2MP.
5.5. LSP Delegation 5.5. LSP Delegation
LSP delegation operations described in Section 5.7 of LSP delegation operations described in Section 5.7 of
[I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. [I-D.ietf-pce-stateful-pce] are 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 of
[I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
The Path Computation Request and Response message format for P2MP TE The Path Computation Request and Response message format for P2MP TE
LSPs is described in Section 3.4 and Section 3.5 of LSPs is described in Section 3.4 and Section 3.5 of
[I-D.palleti-pce-rfc6006bis] respectively. [I-D.ietf-pce-rfc6006bis] respectively.
The Request and Response message for P2MP TE LSPs are extended to The Request and Response message for P2MP TE LSPs are extended to
support encoding of LSP object, so that it is possible to refer to a support encoding of LSP object, so that it is possible to refer to a
LSP with a unique identifier and simplify the PCEP message exchange. LSP with a unique identifier and simplify the PCEP message exchange.
For example, incase of modification of one leaf in a P2MP tree, there For example, incase of modification of one leaf in a P2MP tree, 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
skipping to change at page 10, line 4 skipping to change at page 10, line 10
Message with an LSP object carrying the PLSP-ID of the LSP to be Message with an LSP object carrying the PLSP-ID of the LSP to be
removed and an SRP object with the R flag set (LSP-REMOVE as per removed and an SRP object with the R flag set (LSP-REMOVE as per
section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). 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 and SHOULD refer P2MP TE LSP MUST be carried in PCUpd message and SHOULD refer
Section 6.2 for P2MP TE LSP extensions. As defined in Section 6.2 for P2MP TE LSP extensions. As defined in
[I-D.ietf-pce-rfc6006bis], leaf type = 1 for adding of new leaves,
[I-D.palleti-pce-rfc6006bis], leaf type = 1 for adding of new leaves,
leaf type = 2 for pruning of old leaves of P2MP END-POINTS Object are leaf type = 2 for pruning of old leaves of P2MP END-POINTS Object are
used in PCUpd message. used in PCUpd message.
PCC MAY use the Incremental State Update mechanims as described in PCC MAY use the Incremental State Update mechanims 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 [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing
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.palleti-pce-rfc6006bis] is The P2MP END-POINTS object defined in [I-D.ietf-pce-rfc6006bis] is
mandatory for specifying address of P2MP leaves grouped based on leaf mandatory for 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)
skipping to change at page 12, line 32 skipping to change at page 12, line 32
one instance of <END-POINTS> MUST be present in this message for P2MP one instance of <END-POINTS> MUST be present in this message for P2MP
LSP. LSP.
During state synchronization, the PCRpt message must report the During state synchronization, the PCRpt message must report the
status of the full P2MP TE LSP. status of 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 bit is set in LSP object for P2MP TE LSP. If
the S2LS object is missing, the receiving PCE MUST send a PCErr 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=TBD (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 [I-D.ietf-pce-stateful-pce], PCUpd message is As per Section 6.2 of [I-D.ietf-pce-stateful-pce], PCUpd message is
used to update P2P TE LSP attributes. This document extends the used to update P2P TE LSP attributes. This document extends the
PCUpd message in updating the attributes of P2MP TE LSP. PCUpd message in updating the attributes of P2MP TE LSP.
skipping to change at page 13, line 45 skipping to change at page 13, line 45
described in [RFC4875] based on a local policy decision. 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.palleti-pce-rfc6006bis], PCReq message is As per Section 3.4 of [I-D.ietf-pce-rfc6006bis], PCReq message is
used for a P2MP path computation request. This document extends the used for a P2MP path computation request. This document extends the
PCReq message such that a PCC MAY include the LSP object in the PCReq PCReq message such that a PCC MAY include the LSP object in the PCReq
message if the stateful PCE P2MP capability has been negotiated on a message if the stateful PCE P2MP capability has been negotiated on a
PCEP session between the PCC and a PCE. PCEP 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>
[<OF>] [<OF>]
[<metric-list>] [<metric-list>]
[<svec-list>] [<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<end-point-rro-pair-list> <end-point-rro-pair-list>
[<LSP>] [<LSP>]
[<OF>] [<OF>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>|<BNC>] [<IRO>|<BNC>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
where: <end-point-rro-pair-list>::= <END-POINTS>
[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<end-point-rro-pair-list>::= <RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<END-POINTS>[<RRO-List>[<BANDWIDTH>]] <metric-list>::=<METRIC>[<metric-list>]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
6.4. The PCRep Message 6.4. The PCRep Message
As per Section 3.5 of [I-D.palleti-pce-rfc6006bis], PCRep message is As per Section 3.5 of [I-D.ietf-pce-rfc6006bis], PCRep message is
used for a P2MP path computation reply. This document extends the used for a P2MP path computation reply. This document extends the
PCRep message such that a PCE MAY include the LSP object in the PCRep PCRep message such that a PCE MAY include the LSP object in the PCRep
message if the stateful PCE P2MP capability has been negotiated on a message if the stateful PCE P2MP capability has been negotiated on a
PCEP session between the PCC and a PCE. PCEP session 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:
<response-list>::=<response>[<response-list>] where:
<response>::=<RP> <response-list>::=<response>[<response-list>]
[<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list>::= <response>::=<RP>
[<END-POINTS>]<path>[<end-point-path-pair-list>] [<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<path> ::= (<ERO>|<SERO>) [<path>] <end-point-path-pair-list>::= [<END-POINTS>]
<path>
[<end-point-path-pair-list>]
where: <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 [I-D.ietf-pce-pce-initiated-lsp], PCE
sends a PCInitiate message to a PCC to recommend instantiation of a sends a PCInitiate message to a PCC to recommend instantiation of a
P2P TE LSP, this document extends the format of PCInitiate message P2P TE LSP, this document extends the format of PCInitiate message
for the creation of P2MP TE LSPs but the creation and deletion for the creation of P2MP TE LSPs but the creation and deletion
operations of P2MP TE LSP are same to the P2P TE LSP. operations of P2MP 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:
skipping to change at page 18, line 39 skipping to change at page 18, line 39
format defined in [RFC5440]. format defined in [RFC5440].
7.1. Extension of LSP Object 7.1. Extension of LSP Object
LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce]. LSP Object is defined in Section 7.3 of [I-D.ietf-pce-stateful-pce].
It specifies PLSP-ID to uniquely identify an LSP that is constant for It specifies PLSP-ID to uniquely identify an LSP that is constant for
the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID
identify a P2MP TE LSP uniquely. This document adds the following identify a P2MP TE LSP uniquely. This document adds the following
flags to the LSP Object: flags to the LSP Object:
N (P2MP bit): If the bit is set to 1, it specifies the message is N (P2MP bit - TBD7): If the bit is set to 1, it specifies the
for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a message is for P2MP TE LSP which MUST be set in PCRpt or PCUpd
P2MP TE LSP. message for a P2MP TE LSP.
F (Fragmentation bit): If the bit is set to 1, it specifies the F (Fragmentation bit - TBD8): If the bit is set to 1, it specifies
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
PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is
missing, the PCE will generate an error with error-type 6 (mandatory missing, the PCE will generate an error with error-type 6 (mandatory
object missing) and error-value TBD (P2MP-LSP-IDENTIFIERS TLV object missing) and error-value TBD12 (P2MP-LSP-IDENTIFIER TLV
missing) and close the PCEP session. missing) and close the PCEP session.
The P2MP LSP Identifier TLV MAY be included in the LSP object in The P2MP LSP Identifier TLV MAY be included in the LSP object in
PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value PCUpd message for RSVP-TE signaled P2MP TE LSPs. The special value
of all zeros for this TLV is used to refer to all paths pertaining to of all zeros for this TLV is used to refer to all paths pertaining to
a particular PLSP-ID. a particular PLSP-ID.
There are two P2MP LSP Identifier TLVs, one for IPv4 and one for There are two P2MP LSP Identifier TLVs, one for IPv4 and one for
IPv6. IPv6.
The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the
following figure: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=16 | | Type=TBD9 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address | | IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPV4-P2MP-LSP-IDENTIFIER TLV format Figure 6: IPV4-P2MP-LSP-IDENTIFIER TLV format
The type (16-bit) of the TLV is [TBD] to be assigned by IANA. The The type (16-bit) of the TLV is TBD9 to be assigned by IANA. The
length (16-bit) has a fixed value of 16 octets. The value contains length (16-bit) has a fixed value of 16 octets. The value contains
the following fields: the following fields:
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, IPv4 Tunnel Sender Address: contains the sender node's IPv4 address,
as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
Object. Object.
skipping to change at page 20, line 22 skipping to change at page 20, line 22
P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in P2MP ID: contains the 32-bit 'P2MP ID' identifier defined in
Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION
Object. Object.
The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the
following figure: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=40 | | Type=TBD10 | Length=40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
skipping to change at page 20, line 47 skipping to change at page 20, line 47
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPV6-P2MP-LSP-IDENTIFIER TLV format Figure 7: IPV6-P2MP-LSP-IDENTIFIER TLV format
The type of the TLV is [TBD] to be assigned by IANA. The length The type of the TLV is TBD10 to be assigned by IANA. The length
(16-bit) has a fixed length of 40 octets. The value contains the (16-bit) has a fixed length of 40 octets. The value contains the
following fields: following fields:
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, IPv6 Tunnel Sender Address: contains the sender node's IPv6 address,
as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
Object. Object.
skipping to change at page 21, line 31 skipping to change at page 21, line 31
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 RSVP-TE state of
one or more destinations (leaves) encoded within the END-POINTS one or more destinations (leaves) encoded within the END-POINTS
object for a P2MP TE LSP. It MUST be carried in PCRpt message along object for a P2MP TE LSP. It MUST be carried in PCRpt message along
with END-POINTS object when N bit is set in LSP object. with END-POINTS object when N bit is set in LSP object.
S2LS Object-Class is [TBD]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | O| | Flags | O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.palleti-pce-rfc6006bis] which describes request is similar to [I-D.ietf-pce-rfc6006bis] which describes request and
and response message fragmentation. response message 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.
To indicate P2MP message fragmentation errors associated with a P2MP To indicate P2MP message fragmentation errors associated with a P2MP
Report, a Error-Type (18) and a new error-value TBD is used if a PCE Report, a Error-Type (18) for "P2MP Fragmentation Error" and a new
has not received the last piece of the fragmented message, it should error-value TBD13 is used if a PCE has not received the last piece of
send an error message to the PCC to signal that it has received an the fragmented message, it should send an error message to the PCC to
incomplete message (i.e., "Fragmented Report failure"). signal that it has received an incomplete message (i.e., "Fragmented
Report failure").
8.2. Update Fragmentation Procedure 8.2. Update Fragmentation Procedure
Once the PCE computes and updates a path for some or all leaves in a Once the PCE computes and updates a path for some or all leaves in a
P2MP TE LSP, an update message is sent to the PCC. If the update is P2MP TE LSP, an update message is sent to the PCC. If the update is
too large to fit into a single update message, the PCE will split the too large to fit into a single update message, the PCE will split the
update over multiple messages. Each update message sent by the PCE, update over multiple messages. Each update message sent by the PCE,
except the last one, will have the F-bit set in the LSP object to except the last one, will have the F-bit set in the LSP object to
signify that the update has been fragmented into multiple messages. signify that the update has been fragmented into multiple messages.
In order to identify that a series of update messages represents a In order to identify that a series of update messages represents a
single update, each message will use the same PLSP-ID and SRP-ID- single update, each message will use the same PLSP-ID and SRP-ID-
number. number.
To indicate P2MP message fragmentation errors associated with a P2MP To indicate P2MP message fragmentation errors associated with a P2MP
Update request, a Error-Type (18) and a new error-value TBD is used Update request, a Error-Type (18) for "P2MP Fragmentation Error" and
if a PCC has not received the last piece of the fragmented message, a new error-value TBD14 is used if a PCC has not received the last
it should send an error message to the PCE to signal that it has piece of the fragmented message, it should send an error message to
received an incomplete message (i.e., "Fragmented Update failure"). the PCE to signal that it has received an incomplete message (i.e.,
"Fragmented Update failure").
8.3. PCIntiate Fragmentation Procedure 8.3. PCIntiate Fragmentation Procedure
Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate Once the PCE initiates to set up the P2MP TE LSP, a PCInitiate
message is sent to the PCC. If the PCInitiate is too large to fit message is sent to the PCC. If the PCInitiate is too large to fit
into a single PCInitiate message, the PCE will split the PCInitiate into a single PCInitiate message, the PCE will split the PCInitiate
over multiple messages. Each PCInitiate message sent by the PCE, over multiple messages. Each PCInitiate message sent by the PCE,
except the last one, will have the F-bit set in the LSP object to except the last one, will have the F-bit set in the LSP object to
signify that the PCInitiate has been fragmented into multiple signify that the PCInitiate has been fragmented into multiple
messages. In order to identify that a series of PCInitiate messages messages. In order to identify that a series of PCInitiate messages
represents a single Initiate, each message will use the same PLSP-ID represents a single Initiate, each message will use the same PLSP-ID
(in this case 0) and SRP-ID-number. (in this case 0) and SRP-ID-number.
To indicate P2MP message fragmentation errors associated with a P2MP To indicate P2MP message fragmentation errors associated with a P2MP
PCInitiate, a Error-Type (18) and a new error-value TBD is used if a PCInitiate, a Error-Type (18) for "P2MP Fragmentation Error" and a
PCC has not received the last piece of the fragmented message, it new error-value TBD15 is used if a PCC has not received the last
should send an error message to the PCE to signal that it has piece of the fragmented message, it should send an error message to
received an incomplete message (i.e., "Fragmented Instantiation the PCE to signal that it has received an incomplete message (i.e.,
failure"). "Fragmented Instantiation failure").
9. Non-Support of P2MP TE LSPs for Stateful PCE 9. Non-Support of P2MP TE LSPs for Stateful PCE
The PCEP protocol extensions described in this document for stateful The PCEP protocol extensions described in this document for stateful
PCEs with P2MP capability MUST NOT be used if PCE has not advertised PCEs with P2MP capability MUST NOT be used if PCE has not advertised
its stateful capability with P2MP as per Section 5.2. If the PCEP its stateful capability with P2MP as per Section 5.2. If the PCEP
Speaker on the PCC supports the extensions of this draft (understands Speaker on the PCC supports the extensions of this draft (understands
the P2MP flag in the LSP object) but did not advertise this the P2MP flag in the LSP object) but did not advertise this
capability, then upon receipt of PCUpd message from the PCE, it capability, then upon receipt of PCUpd message from the PCE, it
SHOULD generate a PCErr with error-type 19 (Invalid Operation), SHOULD generate a PCErr with error-type 19 (Invalid Operation),
error-value TBD (Attempted LSP Update Request for P2MP if active error-value TBD17 (Attempted LSP Update Request for P2MP if active
stateful PCE capability for P2MP was not advertised). If the PCEP stateful PCE capability for P2MP was not advertised). If the PCEP
Speaker on the PCE supports the extensions of this draft (understands Speaker on the PCE supports the extensions of this draft (understands
the P2MP flag in the LSP object) but did not advertise this the P2MP flag in the LSP object) but did not advertise this
capability, then upon receipt of a PCRpt message from the PCC, it capability, then upon receipt of a PCRpt message from the PCC, it
SHOULD generate a PCErr with error-type 19 (Invalid Operation), SHOULD generate a PCErr with error-type 19 (Invalid Operation),
error-value TBD (Attempted LSP State Report for P2MP if stateful PCE error-value TBD16 (Attempted LSP State Report for P2MP if stateful
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 [I-D.ietf-pce-stateful-pce]. would act as per [I-D.ietf-pce-stateful-pce].
The PCEP protocol extensions described in this document for PCC or The PCEP protocol extensions described in this document for PCC or
PCE with instantiation capability for P2MP TE LSPs MUST NOT be used PCE with instantiation capability for P2MP TE LSPs MUST NOT be used
if PCC or PCE has not advertised its stateful capability with if PCC or PCE has not advertised its stateful capability with
Instantiation and P2MP capability as per Section 5.2. If the PCEP Instantiation and P2MP capability as per Section 5.2. If the PCEP
Speaker on the PCC supports the extensions of this draft (understands Speaker on the PCC supports the extensions of this draft (understands
the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) but
did not advertise this capability, then upon receipt of PCInitiate did not advertise this capability, then upon receipt of PCInitiate
message from the PCE, it SHOULD generate a PCErr with error-type 19 message from the PCE, it SHOULD generate a PCErr with error-type 19
(Invalid Operation), error-value TBD (Attempted LSP Instantiation (Invalid Operation), error-value TBD18 (Attempted LSP Instantiation
Request for P2MP if stateful PCE instantiation capability for P2MP Request for P2MP if 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.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], [RFC5440], [I-D.ietf-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce],
and [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol and [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol
extensions defined in this document. In addition, requirements and extensions 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
The PCEP MIB module SHOULD be extended to include advertised P2MP The PCEP YANG module [I-D.ietf-pce-pcep-yang] SHOULD be extended to
stateful capabilities, P2MP synchronization status, and P2MP include advertised P2MP stateful capabilities, P2MP synchronization
delegation status etc. status, and delegation status of P2MP LSP etc. The statistics module
should also count P2MP LSP related data.
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.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], [RFC5440], [I-D.ietf-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce],
and [I-D.ietf-pce-pce-initiated-lsp]. and [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.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], and [I-D.ietf-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], and
[I-D.ietf-pce-pce-initiated-lsp]. [I-D.ietf-pce-pce-initiated-lsp].
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
IANA is requested to allocate new bits in "PCE Capability Flags" IANA is requested to allocate new bits in "PCE Capability Flags"
registry for stateful PCE with P2MP capability as follows: registry for stateful PCE with P2MP capability as follows:
Bit Meaning Reference Bit Meaning Reference
TBD Active Stateful [This I-D] TBD1 Active Stateful [This I-D]
PCE with P2MP PCE with P2MP
TBD Passive Stateful [This I-D] TBD2 Passive Stateful [This I-D]
PCE with P2MP PCE with P2MP
TBD Stateful PCE [This I-D] TBD3 Stateful PCE [This I-D]
Initiation with P2MP Initiation with P2MP
11.2. STATEFUL-PCE-CAPABILITY TLV 11.2. STATEFUL-PCE-CAPABILITY TLV
The following values are defined in this document for the Flags field The STATEFUL-PCE-CAPABILITY TLV is defined in
in the STATEFUL-PCE-CAPABILITY-TLV (defined in [I-D.ietf-pce-stateful-pce] and a registry is requested to be
[I-D.ietf-pce-stateful-pce]) in the OPEN object: created to manage the flags in the TLV. IANA is requested to make
the following allocation in the aforementioned registry.
Bit Description Reference Bit Description Reference
TBD P2MP-CAPABILITY This.I-D TBD4 P2MP-CAPABILITY [This.I-D]
TBD P2MP-LSP-UPDATE- This.I-D TBD5 P2MP-LSP-UPDATE- [This.I-D]
CAPABILITY CAPABILITY
TBD P2MP-LSP- This.I-D TBD6 P2MP-LSP- [This.I-D]
INSTANTIATION- INSTANTIATION-
CAPABILITY CAPABILITY
11.3. Extension of LSP Object 11.3. Extension of LSP Object
This document requests that a registry is created to manage the Flags This document requests that a registry is created to manage the Flags
field of the LSP object (defined in [I-D.ietf-pce-stateful-pce]). field of the LSP object (defined in [I-D.ietf-pce-stateful-pce]).
New values are to be assigned by Standards Action [RFC5226]. Each New values are to be assigned by Standards Action [RFC5226]. Each
bit should be tracked with the following qualities: bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
Bit Description Reference Bit Description Reference
TBD P2MP This.I-D TBD7 P2MP [This.I-D]
TBD Fragmentation This.I-D TBD8 Fragmentation [This.I-D]
11.4. Extension of PCEP-Error Object 11.4. Extension of PCEP-Error Object
A new 19 (recommended values) defined in section 8.5 of A new 19 (recommended values) defined in section 8.5 of
[I-D.ietf-pce-stateful-pce]. The error-type 6 is defined in [I-D.ietf-pce-stateful-pce]. The error-type 6 is defined in
[RFC5440] and error-type 18 in [I-D.palleti-pce-rfc6006bis]. This [RFC5440] and error-type 18 in [I-D.ietf-pce-rfc6006bis]. This
document extend the new Error-Values for those error types for the document extend the new Error-Values for those error types for the
following error conditions: following error conditions:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing 6 Mandatory Object missing
Error-value=TBD: S2LS object missing Error-value=TBD11: S2LS object missing
Error-value=TBD: P2MP-LSP-IDENTIFIER TLV missing Error-value=TBD12: P2MP-LSP-IDENTIFIER TLV missing
18 P2MP Fragmentation Error 18 P2MP Fragmentation Error
Error-value= TBD. Fragmented Report Error-value= TBD13. Fragmented Report
failure failure
Error-value= TBD. Fragmented Update Error-value= TBD14. Fragmented Update
failure failure
Error-value= TBD. Fragmented Instantiation Error-value= TBD15. Fragmented Instantiation
failure failure
19 Invalid Operation 19 Invalid Operation
Error-value= TBD. 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
Error-value= TBD. Attempted LSP Update Request Error-value= TBD17. Attempted LSP Update Request
for P2MP if active stateful PCE capability for P2MP if active stateful PCE capability
for P2MP was not advertised for P2MP was not advertised
Error-value= TBD. Attempted LSP Instantiation Error-value= TBD18. Attempted LSP Instantiation
Request for P2MP if stateful PCE Request for P2MP if stateful PCE
instantiation capability for P2MP was not instantiation capability for P2MP was not
advertised advertised
Referece for all Error-Value above is [This.I-D].
Upon approval of this document, IANA is requested to make the Upon approval of this document, IANA is requested to make the
assignment of a new error value for the existing "PCEP-ERROR Object assignment of a new error value for the existing "PCEP-ERROR Object
Error Types and Values" registry located at Error Types and Values" registry located at
http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object. http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object.
11.5. PCEP TLV Type Indicators 11.5. PCEP TLV Type Indicators
Upon approval of this document, IANA is requested to make the Upon approval of this document, IANA is requested to make the
assignment of a new value for the existing "PCEP TLV Type Indicators" assignment of a new value for the existing "PCEP TLV Type Indicators"
registry located at http://www.iana.org/assignments/pcep/ registry located at http://www.iana.org/assignments/pcep/
pcep.xhtml#pcep-tlv-type-indicators. This document defines the pcep.xhtml#pcep-tlv-type-indicators. This document defines the
following new PCEP TLVs: following new PCEP TLVs:
Value Meaning Reference Value Meaning Reference
TBD P2MP-IPV4-LSP-IDENTIFIERS This.I-D TBD9 P2MP-IPV4-LSP-IDENTIFIERS [This.I-D]
TBD P2MP-IPV6-LSP-IDENTIFIERS This.I-D TBD10 P2MP-IPV6-LSP-IDENTIFIERS [This.I-D]
11.6. PCEP object
IANA is requested to allocate new object-class values and object
types within the "PCEP Objects" sub-registry of the PCEP Numbers
registry, as follows.
Object-Class Value Name Reference
TBD19 S2LS [This.I-D]
Object-Type
1
11.7. S2LS object
This document requests that a new sub-registry, named "S2LS Object
Flag Field", is created within the "Path Computation Element Protocol
(PCEP) Numbers" registry to manage the Flag field of the S2LS
object.New values are to be assigned by Standards Action [RFC5226].
Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
Bit Description Reference
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 link bandwidth. 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],
[I-D.palleti-pce-rfc6006bis] and [I-D.ietf-pce-stateful-pce], and [I-D.ietf-pce-rfc6006bis] and [I-D.ietf-pce-stateful-pce], and
[I-D.ietf-pce-pce-initiated-lsp]. Further [I-D.ietf-pce-pceps] [I-D.ietf-pce-pce-initiated-lsp]. Further [I-D.ietf-pce-pceps]
discusses an experimental approach to provide secure transport for discusses an enhanced approach to provide secure transport for PCEP
PCEP. via Transport Layer Security (TLS).
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 29, line 8 skipping to change at page 30, line 8
January 2008, <http://www.rfc-editor.org/info/rfc5089>. January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-16 (work in progress), September 2016. pce-18 (work in progress), December 2016.
[I-D.ietf-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 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", draft- Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-06 (work in ietf-pce-stateful-sync-optimizations-09 (work in
progress), October 2016. progress), February 2017.
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "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-07 (work in Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
progress), July 2016. progress), March 2017.
[I-D.palleti-pce-rfc6006bis] [I-D.ietf-pce-rfc6006bis]
Palleti, R. and D. Dhody, "Extensions to the Path Zhao, Q., Dhody, D., Palleti, R., King, D., Verhaeghe, F.,
Takeda, T., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Point-to-Multipoint Traffic Engineering Label Switched
Paths", draft-palleti-pce-rfc6006bis-00 (work in Paths", draft-ietf-pce-rfc6006bis-00 (work in progress),
progress), October 2016. March 2017.
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,
<http://www.rfc-editor.org/info/rfc4655>. <http://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 11 skipping to change at page 31, line 11
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[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,
<http://www.rfc-editor.org/info/rfc5671>. <http://www.rfc-editor.org/info/rfc5671>.
[I-D.ietf-pce-stateful-pce-app] [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Zhang, X. and I. Minei, "Applicability of a Stateful Path Stateful Path Computation Element (PCE)", RFC 8051,
Computation Element (PCE)", draft-ietf-pce-stateful-pce- DOI 10.17487/RFC8051, January 2017,
app-07 (work in progress), September 2016. <http://www.rfc-editor.org/info/rfc8051>.
[I-D.ietf-pce-pceps] [I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-10 (work in Transport for PCEP", draft-ietf-pce-pceps-11 (work in
progress), July 2016. progress), January 2017.
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)",
draft-ietf-pce-pcep-yang-02 (work in progress), March
2017.
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
skipping to change at page 31, line 43 skipping to change at page 32, line 43
Yosuke Tanaka Yosuke Tanaka
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
EMail: yosuke.tanaka@ntt.com EMail: yosuke.tanaka@ntt.com
Zafar Ali
Cisco Systems
EMail: zali@cisco.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
EMail: vbeeram@juniper.net EMail: vbeeram@juniper.net
 End of changes. 87 change blocks. 
179 lines changed or deleted 228 lines changed or added

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