draft-ietf-pce-stateful-pce-p2mp-06.txt   draft-ietf-pce-stateful-pce-p2mp-07.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: September 5, 2018 Y. Tanaka Expires: October 26, 2018 Y. Tanaka
NTT Communications NTT Communications
V. Beeram V. Beeram
Juniper Networks Juniper Networks
March 4, 2018 April 24, 2018
Path Computation Element (PCE) Protocol Extensions for Stateful PCE Path Computation Element (PCE) Protocol Extensions for Stateful PCE
usage for Point-to-Multipoint Traffic Engineering Label Switched Paths usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-stateful-pce-p2mp-06 draft-ietf-pce-stateful-pce-p2mp-07
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 Label Switched Paths (LSPs). This document to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document
provides extensions required for Path Computation Element provides extensions required for Path Computation Element
Communication Protocol (PCEP) so as to enable the usage of a stateful Communication Protocol (PCEP) so as to enable the usage of a stateful
PCE capability in supporting P2MP TE LSPs. PCE capability in supporting P2MP TE LSPs.
skipping to change at page 1, line 40 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2018. This Internet-Draft will expire on October 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4 3. Supporting P2MP TE LSP for Stateful PCE . . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5
4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5
5. Architectural Overview of Protocol Extensions . . . . . . . . 5 5. Architectural Overview of Protocol Extensions . . . . . . . . 6
5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6
5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 6
5.3. IGP Extensions for Stateful PCE P2MP Capabilities 5.3. IGP Extensions for Stateful PCE P2MP Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 7 Advertisement . . . . . . . . . . . . . . . . . . . . . . 7
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8
5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 8 5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 8
5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9 5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9
5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9 5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9
5.6.3.1. P2MP TE LSP Instantiation . . . . . . . . . . . . 9 5.6.3.1. P2MP TE LSP Instantiation . . . . . . . . . . . . 9
5.6.3.2. P2MP TE LSP Deletion . . . . . . . . . . . . . . 9 5.6.3.2. P2MP TE LSP Deletion . . . . . . . . . . . . . . 9
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.6.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 17 6.6.1. P2MP TE LSP Update Request . . . . . . . . . . . . . 17
6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17 6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17
6.7. Adding and Pruning Leaves to/from the P2MP Tree . . . . . 18
7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 18 7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 18
7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 18 7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 18
7.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 19 7.2. P2MP-LSP-IDENTIFIER TLV . . . . . . . . . . . . . . . . . 19
7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 22 8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23
8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 22 8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23
8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23 8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23
8.3. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 23 8.3. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 24
9. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 24
9. Non-Support of P2MP TE LSPs for Stateful PCE . . . . . . . . 23 10. Manageability Considerations . . . . . . . . . . . . . . . . 25
10. Manageability Considerations . . . . . . . . . . . . . . . . 24 10.1. Control of Function and Policy . . . . . . . . . . . . . 25
10.1. Control of Function and Policy . . . . . . . . . . . . . 24 10.2. Information and Data Models . . . . . . . . . . . . . . 25
10.2. Information and Data Models . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . 26
10.6. Impact On Network Operations . . . . . . . . . . . . . . 25 10.6. Impact On Network Operations . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 25 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26
11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26
11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 26 11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27
11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27
11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28
11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 27 11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 28
11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 28 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.1. Normative References . . . . . . . . . . . . . . . . . . 29 14.1. Normative References . . . . . . . . . . . . . . . . . . 30
14.2. Informative References . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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
skipping to change at page 6, line 49 skipping to change at page 7, line 5
During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231], During PCEP Initialization Phase, as per Section 7.1.1 of [RFC8231],
PCEP speakers advertises Stateful capability via Stateful PCE PCEP speakers advertises Stateful capability via Stateful PCE
Capability TLV in open message. Various flags are defined for the Capability TLV in open message. Various flags are defined for the
STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in
[RFC8281] and [RFC8232]. [RFC8281] and [RFC8232].
Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY),
and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document:
N (P2MP-CAPABILITY bit - TBD4): if set to 1 by a PCC, the N Flag N (P2MP-CAPABILITY bit): if set to 1 by a PCC, the N Flag indicates
indicates that the PCC is willing to send P2MP LSP State Reports that the PCC is willing to send P2MP LSP State Reports whenever
whenever P2MP LSP parameters or operational status changes.; if P2MP LSP parameters or operational status changes.; if set to 1 by
set to 1 by a PCE, the N Flag indicates that the PCE is interested a PCE, the N Flag indicates that the PCE is interested in
in receiving LSP State Reports whenever LSP parameters or receiving LSP State Reports whenever LSP parameters or operational
operational status changes. The P2MP-CAPABILITY Flag must be status changes. The P2MP-CAPABILITY Flag must be advertised by
advertised by both a PCC and a PCE for PCRpt messages P2MP both a PCC and a PCE for PCRpt messages P2MP extension to be
extension to be allowed on a PCEP session. allowed on a PCEP session.
M (P2MP-LSP-UPDATE-CAPABILITY bit - TBD5): if set to 1 by a PCC, the M (P2MP-LSP-UPDATE-CAPABILITY bit): if set to 1 by a PCC, the M Flag
M Flag indicates that the PCC allows modification of P2MP LSP indicates that the PCC allows modification of P2MP LSP parameters;
parameters; if set to 1 by a PCE, the M Flag indicates that the if set to 1 by a PCE, the M Flag indicates that the PCE is capable
PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- of updating P2MP LSP parameters. The P2MP-LSP-UPDATE-CAPABILITY
UPDATE-CAPABILITY Flag must be advertised by both a PCC and a PCE Flag must be advertised by both a PCC and a PCE for PCUpd messages
for PCUpd messages P2MP extension to be allowed on a PCEP session. P2MP extension to be allowed on a PCEP session.
P (P2MP-LSP-INSTANTIATION-CAPABILITY bit - TBD6): If set to 1 by a P (P2MP-LSP-INSTANTIATION-CAPABILITY bit): If set to 1 by a PCC, the
PCC, the P Flag indicates that the PCC allows instantiation of an P Flag indicates that the PCC allows instantiation of an P2MP LSP
P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE
that the PCE supports P2MP LSP instantiation. The P2MP-LSP- supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION-
INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in CAPABILITY flag must be set by both PCC and PCE in order to
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 [RFC8306]. via mechanisms as described in [RFC8306].
5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. Extensions for the consists of utilizing IGP advertisements. Extensions for the
skipping to change at page 8, line 6 skipping to change at page 8, line 9
reference: reference:
Type: 5 Type: 5
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 (early allocated by IANA) for the stateful PCE
with P2MP as follows:
Bit Capability Bit Capability
TBD1 Active Stateful PCE with P2MP 13 Active Stateful PCE with P2MP
TBD2 Passive Stateful PCE with P2MP 14 Passive Stateful PCE with P2MP
TBD3 PCE-Initiation with P2MP 15 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
skipping to change at page 12, line 29 skipping to change at page 12, line 29
report> is preserved. At least one instance of <END-POINTS> MUST be report> is preserved. At least one instance of <END-POINTS> MUST be
present in this message for P2MP LSP. present in this message for P2MP LSP.
During state synchronization, the PCRpt message reports the status of During state synchronization, the PCRpt message reports the status of
the full P2MP TE LSP. the full P2MP TE LSP.
The S2LS object MUST be carried in PCRpt message along with END- The S2LS object MUST be carried in PCRpt message along with END-
POINTS object when N (P2MP) bit is set in LSP object for P2MP TE LSP. POINTS object when N (P2MP) bit is set in LSP object for P2MP TE LSP.
If the S2LS object is missing, the receiving PCE MUST send a PCErr If the S2LS object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error- message with Error-type=6 (Mandatory Object missing) and Error-
value=TBD11 (S2LS object missing). If the END-POINTS object is value=13 (early allocated by IANA) (S2LS object missing). If the
missing, the receiving PCE MUST send a PCErr message with Error- END-POINTS object is missing, the receiving PCE MUST send a PCErr
type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS message with Error-type=6 (Mandatory Object missing) and Error-
object missing) (defined in [RFC5440]. value=3 (END-POINTS object missing) (defined in [RFC5440].
6.2. The PCUpd Message 6.2. The PCUpd Message
As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P As per Section 6.2 of [RFC8231], PCUpd message is used to update P2P
TE LSP attributes. This document extends the PCUpd message in TE LSP attributes. This document extends the PCUpd message in
updating the attributes of P2MP TE LSP. updating the attributes of P2MP TE LSP.
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
skipping to change at page 18, line 26 skipping to change at page 18, line 26
Common Header Common Header
LSP with P2MP flag set LSP with P2MP flag set
END-POINTS for leaf type 4 END-POINTS for leaf type 4
S2LS (O=ACTIVE) S2LS (O=ACTIVE)
ERO list ERO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
S2LS (O=DOWN) S2LS (O=DOWN)
ERO list ERO list
6.7. Adding and Pruning Leaves to/from the P2MP Tree
Section 3.10 of [RFC8306] defines the error-handling procedures when
adding new leaves to or removing old leaves from the existing P2MP
tree for PCReq message. The same error handling and error-codes are
also applicable to the stateful PCE messages as described in this
document.
7. PCEP Object Extensions 7. PCEP Object Extensions
The PCEP TLV defined in this document is compliant with the PCEP TLV The PCEP TLV defined in this document is compliant with the PCEP TLV
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 [RFC8231]. It specifies LSP Object is defined in Section 7.3 of [RFC8231]. It specifies
PLSP-ID to uniquely identify an LSP that is constant for the life PLSP-ID to uniquely identify an LSP that is constant for the life
time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify
a P2MP TE LSP uniquely. This document adds the following flags to a P2MP TE LSP uniquely. This document adds the following flags to
the LSP Object: the LSP Object:
N (P2MP bit - TBD7): If the bit is set to 1, it specifies the N (P2MP bit): If the bit is set to 1, it specifies the message is
message is for P2MP TE LSP which MUST be set in PCRpt, PCUpd, or for P2MP TE LSP which MUST be set in PCRpt, PCUpd, or PCInitiate
PCInitiate message for a P2MP TE LSP. message for a P2MP TE LSP.
F (Fragmentation bit - TBD8): If the bit is set to 1, it specifies F (Fragmentation bit): If the bit is set to 1, it specifies the
the message is fragmented. 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 TBD12 (P2MP-LSP-IDENTIFIER TLV object missing) and error-value 14 (early allocated by IANA) (P2MP-
missing) and close the PCEP session. LSP-IDENTIFIER TLV 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=TBD9 | Length=16 | | Type=32 | 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 TBD9 to be assigned by IANA. The The type (16-bit) of the TLV is 32 (early allocated 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 21, line 8
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=TBD10 | Length=40 | | Type=33 | 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 21, line 33
+ (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 TBD10 to be assigned by IANA. The length The type of the TLV is 33 (early allocated 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 22, line 16
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 state of one or The S2LS (Source-to-Leaves) Object is used to report state of one or
more destinations (leaves) encoded within the END-POINTS object for a more destinations (leaves) encoded within the END-POINTS object for a
P2MP TE LSP. It MUST be carried in PCRpt message along with END- P2MP TE LSP. It MUST be carried in PCRpt message along with END-
POINTS object when N bit is set in LSP object. POINTS object when N bit is set in LSP object.
S2LS Object-Class is TBD19. S2LS Object-Class is 41 (Early allocated by IANA).
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 47 skipping to change at page 23, line 34
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) for "P2MP Fragmentation Error" and a new Report, a Error-Type (18) for "P2MP Fragmentation Error" and a new
error-value TBD13 is used if a PCE has not received the last piece of error-value 2 (early allocated by IANA) is used if a PCE has not
the fragmented message, it should send an error message to the PCC to received the last piece of the fragmented message, it should send an
signal that it has received an incomplete message (i.e., "Fragmented error message to the PCC to signal that it has received an incomplete
Report failure"). 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) for "P2MP Fragmentation Error" and Update request, a Error-Type (18) for "P2MP Fragmentation Error" and
a new error-value TBD14 is used if a PCC has not received the last a new error-value 3 (early allocated by IANA) is used if a PCC has
piece of the fragmented message, it should send an error message to not received the last piece of the fragmented message, it should send
the PCE to signal that it has received an incomplete message (i.e., an error message to the PCE to signal that it has received an
"Fragmented Update failure"). 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) for "P2MP Fragmentation Error" and a PCInitiate, a Error-Type (18) for "P2MP Fragmentation Error" and a
new error-value TBD15 is used if a PCC has not received the last new error-value 4 (early allocated by IANA) is used if a PCC has not
piece of the fragmented message, it should send an error message to received the last piece of the fragmented message, it should send an
the PCE to signal that it has received an incomplete message (i.e., error message to the PCE to signal that it has received an incomplete
"Fragmented Instantiation failure"). message (i.e., "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 TBD17 (Attempted LSP Update Request for P2MP if active error-value 12 (early allocated by IANA) (Attempted LSP Update
stateful PCE capability for P2MP was not advertised). If the PCEP Request for P2MP if active stateful PCE capability for P2MP was not
Speaker on the PCE supports the extensions of this draft (understands advertised). If the PCEP Speaker on the PCE supports the extensions
the P2MP flag in the LSP object) but did not advertise this of this draft (understands the P2MP flag in the LSP object) but did
capability, then upon receipt of a PCRpt message from the PCC, it not advertise this capability, then upon receipt of a PCRpt message
SHOULD generate a PCErr with error-type 19 (Invalid Operation), from the PCC, it SHOULD generate a PCErr with error-type 19 (Invalid
error-value TBD16 (Attempted LSP State Report for P2MP if stateful Operation), error-value 11 (early allocated by IANA) (Attempted LSP
PCE capability for P2MP was not advertised) and it will terminate the State Report for P2MP if stateful PCE capability for P2MP was not
PCEP session. advertised) and it will terminate the PCEP session.
If a Stateful PCE receives a P2MP TE LSP report message and the PCE If a Stateful PCE receives a P2MP TE LSP report message and the PCE
does not understand the P2MP flag in the LSP object, and therefore does not understand the P2MP flag in the LSP object, and therefore
the PCEP extensions described in this document, then the Stateful PCE the PCEP extensions described in this document, then the Stateful PCE
would act as per [RFC8231]. would act as per [RFC8231].
The PCEP extensions described in this document for PCC or PCE with The PCEP extensions described in this document for PCC or PCE with
instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or
PCE has not advertised its stateful capability with Instantiation and PCE has not advertised its stateful capability with Instantiation and
P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC
supports the extensions of this draft (understands the P (P2MP-LSP- supports the extensions of this draft (understands the P (P2MP-LSP-
INSTANTIATION-CAPABILITY) flag) but did not advertise this INSTANTIATION-CAPABILITY) flag) but did not advertise this
capability, then upon receipt of PCInitiate message from the PCE, it capability, then upon receipt of PCInitiate 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 TBD18 (Attempted LSP Instantiation Request for P2MP if error-value 13 (early allocated by IANA) (Attempted LSP Instantiation
stateful PCE instantiation capability for P2MP was not advertised). Request for P2MP if stateful PCE instantiation capability for P2MP
was not advertised).
10. Manageability Considerations 10. Manageability Considerations
All manageability requirements and considerations listed in All manageability requirements and considerations listed in
[RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP protocol [RFC5440], [RFC8306], [RFC8231], and [RFC8281] 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
skipping to change at page 25, line 32 skipping to change at page 26, line 20
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],
[RFC8306], [RFC8231], and [RFC8281]. [RFC8306], [RFC8231], and [RFC8281].
Stateful PCE feature for P2MP LSP would help with network operations. Stateful PCE feature for P2MP LSP would help with network operations.
11. IANA Considerations 11. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA to confirm the early allocation of the
protocol elements defined in this document. code-points for the 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 the OSPF Parameters "PCE IANA is requested to confirm the early allocation for the new bits in
Capability Flags" registry, as follows: the OSPF Parameters "PCE Capability Flags" registry, as follows:
Bit Meaning Reference Bit Meaning Reference
TBD1 Active Stateful [This I-D] 13 Active Stateful [This I-D]
PCE with P2MP PCE with P2MP
TBD2 Passive Stateful [This I-D] 14 Passive Stateful [This I-D]
PCE with P2MP PCE with P2MP
TBD3 Stateful PCE [This I-D] 15 Stateful PCE [This I-D]
Initiation with P2MP Initiation with P2MP
11.2. STATEFUL-PCE-CAPABILITY TLV 11.2. STATEFUL-PCE-CAPABILITY TLV
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and a The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and a
registry is requested to be created to manage the flags in the TLV. registry was created to manage the flags in the TLV. IANA is
IANA is requested to make the following allocations in the requested to confirm the early allocation of the following code-
aforementioned registry. points in the aforementioned registry.
Bit Description Reference Bit Description Reference
TBD4 P2MP-CAPABILITY [This I-D] 25 P2MP-CAPABILITY [This I-D]
TBD5 P2MP-LSP-UPDATE- [This I-D] 24 P2MP-LSP-UPDATE- [This I-D]
CAPABILITY CAPABILITY
TBD6 P2MP-LSP- [This I-D] 23 P2MP-LSP- [This I-D]
INSTANTIATION- INSTANTIATION-
CAPABILITY CAPABILITY
11.3. LSP Object 11.3. LSP Object
The LSP object is defined in [RFC8231] and a registry is created to The LSP object is defined in [RFC8231] and a registry was created to
manage the Flags field of the LSP object. manage the Flags field of the LSP object.
IANA is requested to make the following allocations in the IANA is requested to confirm the early allocation of the following
aforementioned registry. code-points in the aforementioned registry.
Bit Description Reference Bit Description Reference
TBD7 P2MP [This I-D] 3 P2MP [This I-D]
TBD8 Fragmentation [This I-D] 2 Fragmentation [This I-D]
11.4. PCEP-Error Object 11.4. PCEP-Error Object
IANA is requested to allocate new error values within the "PCEP-ERROR IANA is requested to confirm the early allocation of the new error
Object Error Types and Values" sub-registry of the PCEP Numbers values within the "PCEP-ERROR Object Error Types and Values" sub-
registry, as follows: registry of the PCEP Numbers registry, as follows:
Error-Type Meaning Error-Type Meaning
6 Mandatory Object missing [RFC5440] 6 Mandatory Object missing [RFC5440]
Error-value=TBD11: S2LS object missing Error-value=13: S2LS object missing
Error-value=TBD12: P2MP-LSP-IDENTIFIER TLV missing Error-value=14: P2MP-LSP-IDENTIFIER TLV missing
18 P2MP Fragmentation Error [RFC8306] 18 P2MP Fragmentation Error [RFC8306]
Error-value= TBD13. Fragmented Report Error-value= 2. Fragmented Report
failure failure
Error-value= TBD14. Fragmented Update Error-value= 3. Fragmented Update
failure failure
Error-value= TBD15. Fragmented Instantiation Error-value= 4. Fragmented Instantiation
failure failure
19 Invalid Operation [RFC8231] 19 Invalid Operation [RFC8231]
Error-value= TBD16. Attempted LSP State Report Error-value= 11. 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= TBD17. Attempted LSP Update Request Error-value= 12. 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= TBD18. Attempted LSP Instantiation Error-value= 13. 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
Reference for all new Error-Value above is [This I-D]. Reference for all new Error-Value above is [This I-D].
11.5. PCEP TLV Type Indicators 11.5. PCEP TLV Type Indicators
IANA is requested to make the assignment of a new value for the IANA is requested to confirm the early allocation of the following
existing "PCEP TLV Type Indicators" registry as follows: code-points in the existing "PCEP TLV Type Indicators" registry as
follows:
Value Meaning Reference Value Meaning Reference
TBD9 P2MP-IPV4-LSP-IDENTIFIERS [This I-D] 32 P2MP-IPV4-LSP-IDENTIFIERS [This I-D]
TBD10 P2MP-IPV6-LSP-IDENTIFIERS [This I-D] 33 P2MP-IPV6-LSP-IDENTIFIERS [This I-D]
11.6. PCEP object 11.6. PCEP object
IANA is requested to allocate new object-class values and object IANA is requested to confirm the early allocation for the new object-
types within the "PCEP Objects" sub-registry of the PCEP Numbers class values and object types within the "PCEP Objects" sub-registry
registry, as follows. of the PCEP Numbers registry, as follows.
Object-Class Value Name Reference Object-Class Value Name Reference
TBD19 S2LS [This.I-D] 41 S2LS [This.I-D]
Object-Type Object-Type
0: Reserved 0: Reserved
1: S2LS 1: S2LS
11.7. S2LS object 11.7. S2LS object
This document requests that a new sub-registry, named "S2LS Object This document requests that a new sub-registry, named "S2LS Object
Flag Field", is created within the "Path Computation Element Protocol Flag Field", is created within the "Path Computation Element Protocol
(PCEP) Numbers" registry to manage the Flag field of the S2LS (PCEP) Numbers" registry to manage the Flag field of the S2LS
object.New values are to be assigned by Standards Action [RFC8126]. object.New values are to be assigned by Standards Action [RFC8126].
skipping to change at page 31, line 37 skipping to change at page 32, line 37
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-06 (work in progress), January 2018. yang-07 (work in progress), March 2018.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Granpark Tower Granpark Tower
3-4-1 Shibaura, Minato-ku 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118 Tokyo 108-8118
Japan Japan
 End of changes. 55 change blocks. 
132 lines changed or deleted 143 lines changed or added

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