draft-ietf-pce-stateful-pce-p2mp-00.txt   draft-ietf-pce-stateful-pce-p2mp-01.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: January 19, 2017 Y. Tanaka Expires: May 2, 2017 Y. Tanaka
NTT Communications NTT Communications
Z. Ali Z. Ali
Cisco Systems Cisco Systems
V. Beeram V. Beeram
Juniper Networks Juniper Networks
July 18, 2016 October 29, 2016
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-00 draft-ietf-pce-stateful-pce-p2mp-01
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 42
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 January 19, 2017. This Internet-Draft will expire on May 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 46 skipping to change at page 3, line 46
[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 [RFC6006]. P2MP TE LSPs are described in [I-D.palleti-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
[I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to [I-D.ietf-pce-stateful-pce-app]. These scenarios apply equally to
P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the P2P and P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] provides the
fundamental extensions needed for stateful PCE to support general 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. [I-D.ietf-pce-pce-initiated-lsp]
provides the an extensions needed for stateful PCE-initiated P2P TE provides the an extensions needed for stateful PCE-initiated P2P TE
LSP. Complementarily, this document focuses on the extensions that LSP. Complementarily, this document focuses on the extensions that
are necessary in order for the deployment of stateful PCEs to support are necessary in order for the deployment of stateful PCEs to support
skipping to change at page 4, line 22 skipping to change at page 4, line 22
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
[RFC6006]. [I-D.palleti-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, [I-D.ietf-pce-stateful-pce-app] presents several use cases,
demonstrating scenarios that benefit from the deployment of a demonstrating scenarios that benefit from the deployment of a
stateful PCE including optimization, recovery, etc which are equally stateful PCE including optimization, recovery, etc which are equally
applicable to P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] defines the applicable to P2MP TE LSPs. [I-D.ietf-pce-stateful-pce] defines the
extensions to PCEP for P2P TE LSPs. Complementarily, this document extensions to PCEP for P2P TE LSPs. Complementarily, this document
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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 - 1 bit): If set to 1 by a PCC,
the P Flag indicates that the PCC allows instantiation of an P2MP 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 that the 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-INSTANTIATION- PCE supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION-
CAPABILITY flag must be set by both PCC and PCE in order to CAPABILITY flag must be set by both PCC and PCE in order to
support PCE-initiated P2MP LSP instantiation. 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 [RFC6006]. via mechanisms as described in [I-D.palleti-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 39 skipping to change at page 8, line 39
[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 [RFC6006] LSPs is described in Section 3.4 and Section 3.5 of
respectively. [I-D.palleti-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 9, line 52 skipping to change at page 9, line 52
5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate
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 [RFC6006], Section 6.2 for P2MP TE LSP extensions. As defined in
leaf type = 1 for adding of new leaves, leaf type = 2 for pruning of
old leaves of P2MP END-POINTS Object are used in PCUpd message. [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
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
and error codes remains unchanged. and error codes remains unchanged.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report> <state-report-list> ::= <state-report>
[<state-report-list>] [<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<end-point-path-pair-list> <end-point-intended-path-pair-list>
<attribute-list> [<actual_attribute_list>
<end-point-actual-path-pair-list>]
<intended-attribute-list>
Where: Where:
<end-point-path-pair-list>::= <end-point-intended-path-pair-list>::=
[<END-POINTS>] [<END-POINTS>]
[<S2LS>] [<S2LS>]
<intended_path> <intended_path>
[<actual_path>] [<end-point-intended-path-pair-list>]
[<end-point-path-pair-list>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
<actual_path>
[<end-point-actual-path-pair-list>]
<intended_path> ::= (<ERO>|<SERO>) <intended_path> ::= (<ERO>|<SERO>)
[<intended_path>] [<intended_path>]
<actual_path> ::= (<RRO>|<SRRO>) <actual_path> ::= (<RRO>|<SRRO>)
[<actual_path>] [<actual_path>]
<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
signaled values of the <BANDWIDTH> and <metric-lists>
objects defined in [RFC5440].
The P2MP END-POINTS object defined in [RFC6006] is mandatory for The P2MP END-POINTS object defined in [I-D.palleti-pce-rfc6006bis] is
specifying address of P2MP leaves grouped based on leaf types. mandatory for specifying address of P2MP leaves grouped based on leaf
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, where
as for non-delegated P2MP TE LSP, leaf-type = 4 is used. as for non-delegated P2MP TE LSP, leaf-type = 4 is used.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request> <update-request-list> ::= <update-request>
[<update-request-list>] [<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
<end-point-path-pair-list> <end-point-path-pair-list>
<attribute-list>
<attribute-list>
Where: Where:
<end-point-path-pair-list>::= <end-point-path-pair-list>::=
[<END-POINTS>] [<END-POINTS>]
<path> <intended_path>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) <intended_path> ::= (<ERO>|<SERO>)
[<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 Note that we preserve compatibility with the
[I-D.ietf-pce-stateful-pce] definition of <update-request>. [I-D.ietf-pce-stateful-pce] definition of <update-request>.
The PCC MAY use the make-before-break or sub-group-based procedures The PCC MAY use the make-before-break or sub-group-based procedures
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 [RFC6006], PCReq message is used for a P2MP As per Section 3.4 of [I-D.palleti-pce-rfc6006bis], PCReq message is
path computation request. This document extends the PCReq message used for a P2MP path computation request. This document extends the
such that a PCC MAY include the LSP object in the PCReq message if PCReq message such that a PCC MAY include the LSP object in the PCReq
the stateful PCE P2MP capability has been negotiated on a PCEP message if the stateful PCE P2MP capability has been negotiated on a
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>
<request> [<svec-list>]
where: <request-list>
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
where: where:
<end-point-rro-pair-list>::=<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<BANDWIDTH>][<RRO-List>] <svec-list>::=<SVEC>
<metric-list>::=<METRIC>[<metric-list>] [<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
where:
<end-point-rro-pair-list>::=
<END-POINTS>[<RRO-List>[<BANDWIDTH>]]
[<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 [RFC6006], PCRep message is used for a P2MP As per Section 3.5 of [I-D.palleti-pce-rfc6006bis], PCRep message is
path computation reply. This document extends the PCRep message such used for a P2MP path computation reply. This document extends the
that a PCE MAY include the LSP object in the PCRep message if the PCRep message such that a PCE MAY include the LSP object in the PCRep
stateful PCE P2MP capability has been negotiated on a PCEP session message if the stateful PCE P2MP capability has been negotiated on a
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> <response-list>
<response>::=<RP> where:
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where: <response-list>::=<response>[<response-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>]
<attribute-list>::=[<LSP>] <path> ::= (<ERO>|<SERO>) [<path>]
[<OF>]
[<LSPA>] where:
[<BANDWIDTH>]
[<metric-list>] <attribute-list>::=[<OF>]
[<IRO>] [<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<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 16, line 27 skipping to change at page 16, line 27
<end-point-path-pair-list> <end-point-path-pair-list>
[<attribute-list>] [<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP> <PCE-initiated-lsp-deletion> ::= <SRP>
<LSP> <LSP>
Where: Where:
<end-point-path-pair-list>::= <end-point-path-pair-list>::=
[<END-POINTS>] [<END-POINTS>]
<path> <intended_path>
[<end-point-path-pair-list>] [<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) <intended_path> ::= (<ERO>|<SERO>)
[<path>] [<intended_path>]
<attribute-list> is defined in [RFC5440] and extended <attribute-list> is defined in [RFC5440] and extended
by PCEP extensions. by PCEP extensions.
The PCInitiate message with an LSP object with N bit (P2MP) set is The PCInitiate message with an LSP object with N bit (P2MP) set is
used to convey operation on a P2MP TE LSP. The SRP object is used to used to convey operation on a P2MP TE LSP. The SRP object is used to
correlate between initiation requests sent by the PCE and the error correlate between initiation requests sent by the PCE and the error
reports and state reports sent by the PCC as described in reports and state reports sent by the PCC as described in
[I-D.ietf-pce-stateful-pce]. [I-D.ietf-pce-stateful-pce].
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 [RFC6006] which describes request and response message is similar to [I-D.palleti-pce-rfc6006bis] which describes request
fragmentation. and 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.
skipping to change at page 24, line 32 skipping to change at page 24, line 32
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 TBD (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], [RFC6006], [I-D.ietf-pce-stateful-pce], and [RFC5440], [I-D.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce],
[I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol extensions and [I-D.ietf-pce-pce-initiated-lsp] apply to PCEP protocol
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
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], [RFC6006], [I-D.ietf-pce-stateful-pce], and [RFC5440], [I-D.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce],
[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],
[RFC6006], [I-D.ietf-pce-stateful-pce], and [I-D.palleti-pce-rfc6006bis], [I-D.ietf-pce-stateful-pce], and
[I-D.ietf-pce-pce-initiated-lsp]. [I-D.ietf-pce-pce-initiated-lsp].
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"
skipping to change at page 26, line 44 skipping to change at page 26, line 44
Bit Description Reference Bit Description Reference
TBD P2MP This.I-D TBD P2MP This.I-D
TBD Fragmentation This.I-D TBD 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 [RFC6006]. This document extend the [RFC5440] and error-type 18 in [I-D.palleti-pce-rfc6006bis]. This
new Error-Values for those error types for the following error document extend the new Error-Values for those error types for the
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=TBD: S2LS object missing
Error-value=TBD: P2MP-LSP-IDENTIFIER TLV missing Error-value=TBD: P2MP-LSP-IDENTIFIER TLV missing
18 P2MP Fragmentation Error 18 P2MP Fragmentation Error
Error-value= TBD. Fragmented Report Error-value= TBD. Fragmented Report
failure failure
Error-value= TBD. Fragmented Update Error-value= TBD. Fragmented Update
failure failure
skipping to change at page 28, line 12 skipping to change at page 28, line 12
TBD P2MP-IPV4-LSP-IDENTIFIERS This.I-D TBD P2MP-IPV4-LSP-IDENTIFIERS This.I-D
TBD P2MP-IPV6-LSP-IDENTIFIERS This.I-D TBD P2MP-IPV6-LSP-IDENTIFIERS 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 link bandwidth. 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], [RFC6006] and relevant security requirements of [RFC5440],
[I-D.ietf-pce-stateful-pce], and [I-D.ietf-pce-pce-initiated-lsp]. [I-D.palleti-pce-rfc6006bis] and [I-D.ietf-pce-stateful-pce], and
Further [I-D.ietf-pce-pceps] discusses an experimental approach to [I-D.ietf-pce-pce-initiated-lsp]. Further [I-D.ietf-pce-pceps]
provide secure transport for PCEP. discusses an experimental approach to provide secure transport for
PCEP.
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 5 skipping to change at page 29, line 5
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
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>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
<http://www.rfc-editor.org/info/rfc6006>.
[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-14 (work in progress), March 2016. pce-16 (work in progress), September 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-05 (work in ietf-pce-stateful-sync-optimizations-06 (work in
progress), April 2016. progress), October 2016.
[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-06 (work in Model", draft-ietf-pce-pce-initiated-lsp-07 (work in
progress), July 2016. progress), July 2016.
[I-D.palleti-pce-rfc6006bis]
Palleti, R. and D. Dhody, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", draft-palleti-pce-rfc6006bis-00 (work in
progress), October 2016.
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,
June 2007, <http://www.rfc-editor.org/info/rfc4857>. June 2007, <http://www.rfc-editor.org/info/rfc4857>.
skipping to change at page 30, line 14 skipping to change at page 30, line 14
[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] [I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of a Stateful Path Zhang, X. and I. Minei, "Applicability of a Stateful Path
Computation Element (PCE)", draft-ietf-pce-stateful-pce- Computation Element (PCE)", draft-ietf-pce-stateful-pce-
app-06 (work in progress), July 2016. app-07 (work in progress), September 2016.
[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-10 (work in
progress), July 2016. progress), July 2016.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
 End of changes. 45 change blocks. 
98 lines changed or deleted 127 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/