draft-ietf-pce-stateful-pce-p2mp-09.txt   draft-ietf-pce-stateful-pce-p2mp-10.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: August 10, 2019 Y. Tanaka Expires: August 15, 2019 Y. Tanaka
NTT Communications NTT Communications
V. Beeram V. Beeram
Juniper Networks Juniper Networks
February 6, 2019 February 11, 2019
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-09 draft-ietf-pce-stateful-pce-p2mp-10
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 August 10, 2019. This Internet-Draft will expire on August 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 51 skipping to change at page 2, line 51
6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.6.1. P2MP TE LSPs Update Request . . . . . . . . . . . . . 17 6.6.1. P2MP TE LSPs Update Request . . . . . . . . . . . . . 17
6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17 6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17
6.6.3. P2MP TE LSPs Initiation Request . . . . . . . . . . . 18 6.6.3. P2MP TE LSPs Initiation Request . . . . . . . . . . . 18
7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 19 7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 19
7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 19 7.1. Extension of LSP Object . . . . . . . . . . . . . . . . . 19
7.2. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . . . 19 7.2. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . . . 19
7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23 8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23
8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23 8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23
8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 24 8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23
8.3. PCIntiate Fragmentation Procedure . . . . . . . . . . . . 24 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 . . . . . . . . 24
10. Manageability Considerations . . . . . . . . . . . . . . . . 25 10. Manageability Considerations . . . . . . . . . . . . . . . . 25
10.1. Control of Function and Policy . . . . . . . . . . . . . 25 10.1. Control of Function and Policy . . . . . . . . . . . . . 25
10.2. Information and Data Models . . . . . . . . . . . . . . 25 10.2. Information and Data Models . . . . . . . . . . . . . . 25
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 26 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 26 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 26
10.5. Requirements On Other Protocols . . . . . . . . . . . . 26 10.5. Requirements On Other Protocols . . . . . . . . . . . . 26
10.6. Impact On Network Operations . . . . . . . . . . . . . . 26 10.6. Impact On Network Operations . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26 11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26
11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 27 11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26
11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27 11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27
11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 28 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 27
11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 29 11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28
11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 29 11.6. PCEP object . . . . . . . . . . . . . . . . . . . . . . 29
11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 29 11.7. S2LS object . . . . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.1. Normative References . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 30
14.2. Informative References . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
skipping to change at page 19, line 34 skipping to change at page 19, line 34
that the LSP is fragmented and this is not the last piece of the that the LSP is fragmented and this is not the last piece of the
fragmented LSP. The receiver needs to wait for additional fragmented LSP. The receiver needs to wait for additional
fragments until it receives an LSP with the same PLSP-ID and with fragments until it receives an LSP with the same PLSP-ID and with
the F-bit set to 0. See Section 8 for further details. the F-bit set to 0. See Section 8 for further details.
E (ERO-compression flag - 1 bit): If the E flag is set to 1, it E (ERO-compression flag - 1 bit): If the E flag is set to 1, it
indicates the route is in compressed format (that is, Secondary indicates the route is in compressed format (that is, Secondary
Explicit Route Object (SERO) and Secondary Record Route Object Explicit Route Object (SERO) and Secondary Record Route Object
(SRRO) objects [RFC8306] are in use). (SRRO) objects [RFC8306] are in use).
The N flag is used in a PCRpt, PCUpd, or PCInitiate message to The flags defined in this section (N, F, E flags) are used in PCRpt,
indicate a P2MP TE LSP. In case of PCReq and PCRep, the N flag in PCUpd, or PCInitiate message. In case of PCReq and PCRep message,
the RP (Request Parameters) object ([RFC8231]) is used to indicate these flags have no meaning and thus MUST be ignored. The
P2MP path computation. The N flag in the LSP object MUST also be set corresponding flags in the RP (Request Parameters) object are used as
if the N flag in the RP object is set. If there is mis-match between described in [RFC8231].
the N flag in the RP and the LSP object in PCReq or PCRep message,
the PCEP speaker MUST generate an error with error-type 10
("Reception of an invalid object") and error-value TBD1 (to be
allocated by IANA) ("Mis-match of N flag in RP and LSP object").
7.2. P2MP-LSP-IDENTIFIERS TLV 7.2. P2MP-LSP-IDENTIFIERS TLV
If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is If the N bit is set on a PCRpt but the P2MP-LSP-IDENTIFIER TLV is
absent, the PCE MUST respond with a PCErr message carrying error-type absent, the PCE MUST respond with a PCErr message carrying error-type
6 ("mandatory object missing") and error-value 14 (early allocated by 6 ("mandatory object missing") and error-value 14 (early allocated by
IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session. IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session.
The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the
PCUpd message for P2MP TE LSPs. The special value of all zeros for PCUpd message for P2MP TE LSPs. The special value of all zeros for
skipping to change at page 23, line 12 skipping to change at page 23, line 8
Unassigned bits are reserved for future uses. They MUST be set to 0 Unassigned bits are reserved for future uses. They MUST be set to 0
on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on receipt.
When N flag is set in LSP object then the O field in LSP object When N flag is set in LSP object then the O field in LSP object
represents the operational status of the full P2MP TE LSP and the O represents the operational status of the full P2MP TE LSP and the O
field in S2LS object represents the operational status of a group of field in S2LS object represents the operational status of a group of
destinations encoded within the END-POINTS object. If there is a destinations encoded within the END-POINTS object. If there is a
conflict between the O field in the LSP and the S2LS object (for conflict between the O field in the LSP and the S2LS object (for
example, O field in LSP corresponds to down whereas the O field in example, O field in LSP corresponds to down whereas the O field in
S2LS is up), the PCEP speaker MUST generate an error with error-type S2LS is up), the PCEP speaker MUST generate an error with error-type
10 ("Reception of an invalid object") and error-value TBD2 (to be 10 ("Reception of an invalid object") and error-value TBD1 (to be
allocated by IANA) ("Mis-match of O field in S2LS and LSP object"). allocated by IANA) ("Mis-match of O field in S2LS and LSP object").
Future documents might define optional TLVs that could be included in Future documents might define optional TLVs that could be included in
the S2LS Object. the S2LS Object.
8. Message Fragmentation 8. Message Fragmentation
The total PCEP message length, including the common header, is The total PCEP message length, including the common header, is
(2^16)-1 bytes. In certain scenarios the P2MP report and update (2^16)-1 bytes. In certain scenarios the P2MP report and update
request may not fit into a single PCEP message (e.g. initial report request may not fit into a single PCEP message (e.g. initial report
skipping to change at page 26, line 41 skipping to change at page 26, line 35
This document requests IANA to confirm the early allocation of the This document requests IANA to confirm the early allocation of the
code-points for 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 confirm the early allocation for the new bits in IANA is requested to confirm the early allocation for the new bits in
the OSPF Parameters "PCE Capability Flags" registry, as follows: the OSPF Parameters "PCE Capability Flags" registry, as follows:
Bit Meaning Reference Bit Meaning Reference
13 Active Stateful [This I-D] 13 Active Stateful [This.I-D]
PCE with P2MP PCE with P2MP
14 Passive Stateful [This I-D] 14 Passive Stateful [This.I-D]
PCE with P2MP PCE with P2MP
15 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 was created to manage the flags in the TLV. IANA is registry was created to manage the flags in the TLV. IANA is
requested to confirm the early allocation of the following code- requested to confirm the early allocation of the following code-
points in the aforementioned registry. points in the aforementioned registry.
Bit Description Reference Bit Description Reference
25 P2MP-CAPABILITY [This I-D] 25 P2MP-CAPABILITY [This.I-D]
24 P2MP-LSP-UPDATE- [This I-D] 24 P2MP-LSP-UPDATE- [This.I-D]
CAPABILITY CAPABILITY
23 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 was 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 confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code-points in the aforementioned registry. code-points in the aforementioned registry.
Bit Description Reference Bit Description Reference
3 P2MP [This I-D] 3 P2MP [This.I-D]
2 Fragmentation [This I-D] 2 Fragmentation [This.I-D]
Additionally, IANA is requested to allocate an additional code-point Additionally, IANA is requested to allocate an additional code-point
in this registry. in this registry.
Bit Description Reference Bit Description Reference
TBD ERO-compression [This I-D] TBD ERO-compression [This.I-D]
11.4. PCEP-Error Object 11.4. PCEP-Error Object
IANA is requested to confirm the early allocation of the new error IANA is requested to confirm the early allocation of the new error
values within the "PCEP-ERROR Object Error Types and Values" sub- values within the "PCEP-ERROR Object Error Types and Values" sub-
registry of the PCEP Numbers 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=13: S2LS object missing Error-value=13: S2LS object missing
skipping to change at page 28, line 34 skipping to change at page 28, line 28
for P2MP if stateful PCE capability for P2MP if stateful PCE capability
for P2MP was not advertised for P2MP was not advertised
Error-value= 12. 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= 13. 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].
Additionally, IANA is requested to allocate additional code-points in Additionally, IANA is requested to allocate an additional code-point
this registry. in this registry.
Error-Type Meaning Error-Type Meaning
10 Reception of an invalid object [RFC5440] 10 Reception of an invalid object [RFC5440]
Error-value=TBD1: Mis-match of N flag in RP and Error-value=TBD1: Mis-match of O field in S2LS
LSP object
Error-value=TBD2: Mis-match of O field in S2LS
and LSP object and LSP object
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 confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code-points in the existing "PCEP TLV Type Indicators" registry as code-points in the existing "PCEP TLV Type Indicators" registry as
follows: follows:
Value Meaning Reference Value Meaning Reference
32 P2MP-IPV4-LSP-IDENTIFIERS [This I-D] 32 P2MP-IPV4-LSP-IDENTIFIERS [This.I-D]
33 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 confirm the early allocation for the new object- IANA is requested to confirm the early allocation for the new object-
class values and object types within the "PCEP Objects" sub-registry class values and object types within the "PCEP Objects" sub-registry
of the PCEP Numbers registry, as follows. of the PCEP Numbers registry, as follows.
Object-Class Value Name Reference Object-Class Value Name Reference
41 S2LS [This.I-D] 41 S2LS [This.I-D]
 End of changes. 23 change blocks. 
40 lines changed or deleted 34 lines changed or added

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