draft-ietf-pce-stateful-pce-p2mp-03.txt   draft-ietf-pce-stateful-pce-p2mp-04.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: November 14, 2017 Y. Tanaka Expires: January 3, 2018 Y. Tanaka
NTT Communications NTT Communications
V. Beeram V. Beeram
Juniper Networks Juniper Networks
May 13, 2017 July 2, 2017
Path Computation Element (PCE) Protocol Extensions for Stateful PCE Path Computation Element (PCE) Protocol Extensions for Stateful PCE
usage for Point-to-Multipoint Traffic Engineering Label Switched Paths usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-stateful-pce-p2mp-03 draft-ietf-pce-stateful-pce-p2mp-04
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 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 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 November 14, 2017. This Internet-Draft will expire on January 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 38 skipping to change at page 4, line 38
benefit from the deployment of a stateful PCE including optimization, benefit from the deployment of a stateful PCE including optimization,
recovery, etc which are equally applicable to P2MP TE LSPs. recovery, etc which are equally applicable to P2MP TE LSPs.
[I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE [I-D.ietf-pce-stateful-pce] defines the extensions to PCEP for P2P TE
LSPs. Complementarily, this document focuses on the extensions that LSPs. 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
P2MP TE LSPs. P2MP TE LSPs.
In addition to that, the stateful nature of a PCE simplifies the In addition to that, the stateful nature of a PCE simplifies the
information conveyed in PCEP messages since it is possible to refer information conveyed in PCEP messages since it is possible to refer
to the LSPs via PLSP-ID ([I-D.ietf-pce-stateful-pce]). For P2MP this to the LSPs via PLSP-ID ([I-D.ietf-pce-stateful-pce]). For P2MP this
is an added advantage, where the size of message is much larger. is an added advantage, where the size of message is much larger. In
Incase of stateless PCE, a modification of P2MP tree requires case of stateless PCE, a modification of P2MP tree requires encoding
encoding of all leaves along with the paths in PCReq message, but of all leaves along with the paths in PCReq message, but using a
using a stateful PCE with P2MP capability, the PCEP message can be stateful PCE with P2MP capability, the PCEP message can be used to
used to convey only the modifications (the other information can be convey only the modifications (the other information can be retrieved
retrieved from the P2MP LSP identifier in the LSP database (LSPDB)). from the P2MP LSP identifier in the LSP database (LSPDB)).
In environments where the P2MP TE LSP placement needs to change in In environments where the P2MP TE LSP placement needs to change in
response to application demands, it is useful to support dynamic response to application demands, it is useful to support dynamic
creation and tear down of P2MP TE LSPs. The ability for a PCE to creation and tear down of P2MP TE LSPs. The ability for a PCE to
trigger the creation of P2MP TE LSPs on demand can be seamlessly trigger the creation of P2MP TE LSPs on demand can be seamlessly
integrated into a controller-based network architecture, where integrated into a controller-based network architecture, where
intelligence in the controller can determine when and where to set up intelligence in the controller can determine when and where to set up
paths. Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further paths. Section 3 of [I-D.ietf-pce-pce-initiated-lsp] further
describes the motivation behind the PCE-Initiation capability, which describes the motivation behind the PCE-Initiation capability, which
are equally applicable for P2MP TE LSPs. are equally applicable for P2MP TE LSPs.
skipping to change at page 8, line 51 skipping to change at page 8, line 51
LSP operations for passive stateful PCE described in Section 5.8.1 of LSP operations for passive stateful PCE described in Section 5.8.1 of
[I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well. [I-D.ietf-pce-stateful-pce] are applicable for P2MP TE LSPs as well.
The Path Computation Request and Response message format for P2MP TE The Path Computation Request and Response message format for P2MP TE
LSPs is described in Section 3.4 and Section 3.5 of LSPs is described in Section 3.4 and Section 3.5 of
[I-D.ietf-pce-rfc6006bis] respectively. [I-D.ietf-pce-rfc6006bis] respectively.
The Request and Response message for P2MP TE LSPs are extended to The Request and Response message for P2MP TE LSPs are extended to
support encoding of LSP object, so that it is possible to refer to a support encoding of LSP object, so that it is possible to refer to a
LSP with a unique identifier and simplify the PCEP message exchange. LSP with a unique identifier and simplify the PCEP message exchange.
For example, incase of modification of one leaf in a P2MP tree, there For example, in case of modification of one leaf in a P2MP tree,
should be no need to carry the full P2MP tree in PCReq message. there should be no need to carry the full P2MP tree in PCReq message.
The extension for the Request and Response message for passive The extension for the Request and Response message for passive
stateful operations on P2MP TE LSPs are described in Section 6.3 and stateful operations on P2MP TE LSPs are described in Section 6.3 and
Section 6.4. The extension for the Path Computation LSP State Report Section 6.4. The extension for the Path Computation LSP State Report
(PCRpt) message is described in Section 6.1. (PCRpt) message is described in Section 6.1.
5.6.2. Active Stateful PCE 5.6.2. Active Stateful PCE
LSP operations for active stateful PCE described in Section 5.8.2 of LSP operations for active stateful PCE described in Section 5.8.2 of
[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.
skipping to change at page 10, line 8 skipping to change at page 10, line 8
The deletion operation of P2MP TE LSP is same as defined in section The deletion operation of P2MP TE LSP is same as defined in section
5.4 of [I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate 5.4 of [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 as per Section 6.2 for
Section 6.2 for P2MP TE LSP extensions. As defined in P2MP TE LSP extensions. As defined in [I-D.ietf-pce-rfc6006bis],
[I-D.ietf-pce-rfc6006bis], leaf type = 1 for adding of new leaves, leaf type = 1 for adding of new leaves, leaf type = 2 for pruning of
leaf type = 2 for pruning of old leaves of P2MP END-POINTS Object are old leaves of P2MP END-POINTS Object are used in PCUpd message.
used in PCUpd message.
PCC MAY use the Incremental State Update mechanims as described in PCC MAY use the Incremental State Update mechanism as described in
[RFC4875] to signal adding and pruning of leaves. [RFC4875] to signal adding and pruning of leaves.
5.6.3.4. P2MP TE LSP Delegation and Cleanup 5.6.3.4. P2MP TE LSP Delegation and Cleanup
P2MP TE LSP delegation and cleanup operations are same as defined in P2MP TE LSP delegation and cleanup operations are same as defined in
section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing
and error codes remains unchanged. and error codes remains unchanged.
6. PCEP Message Extensions 6. PCEP Message Extensions
skipping to change at page 27, line 28 skipping to change at page 27, 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= TBD17. Attempted LSP Update Request Error-value= TBD17. Attempted LSP Update Request
for P2MP if active stateful PCE capability for P2MP if active stateful PCE capability
for P2MP was not advertised for P2MP was not advertised
Error-value= TBD18. Attempted LSP Instantiation Error-value= TBD18. Attempted LSP Instantiation
Request for P2MP if stateful PCE Request for P2MP if stateful PCE
instantiation capability for P2MP was not instantiation capability for P2MP was not
advertised advertised
Referece for all 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 make the assignment of a new value for the
existing "PCEP TLV Type Indicators" registry as follows: existing "PCEP TLV Type Indicators" registry as follows:
Value Meaning Reference Value Meaning Reference
TBD9 P2MP-IPV4-LSP-IDENTIFIERS [This I-D] TBD9 P2MP-IPV4-LSP-IDENTIFIERS [This I-D]
TBD10 P2MP-IPV6-LSP-IDENTIFIERS [This I-D] TBD10 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 allocate new object-class values and object
types within the "PCEP Objects" sub-registry of the PCEP Numbers types within the "PCEP Objects" sub-registry of the PCEP Numbers
registry, as follows. registry, as follows.
Object-Class Value Name Reference Object-Class Value Name Reference
TBD19 S2LS [This.I-D] TBD19 S2LS [This.I-D]
Object-Type Object-Type
1 0: Reserved
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 [RFC5226]. object.New values are to be assigned by Standards Action [RFC8126].
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following values are defined in this document: The following values are defined in this document:
skipping to change at page 29, line 42 skipping to change at page 29, line 42
January 2008, <http://www.rfc-editor.org/info/rfc5089>. January 2008, <http://www.rfc-editor.org/info/rfc5089>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-18 (work in progress), December 2016. pce-21 (work in progress), June 2017.
[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-10 (work in ietf-pce-stateful-sync-optimizations-10 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-09 (work in Model", draft-ietf-pce-pce-initiated-lsp-10 (work in
progress), March 2017. progress), June 2017.
[I-D.ietf-pce-rfc6006bis] [I-D.ietf-pce-rfc6006bis]
Zhao, Q., Dhody, D., Palleti, R., and D. King, "Extensions Zhao, Q., Dhody, D., Palleti, R., and D. King, "Extensions
to the Path Computation Element Communication Protocol to the Path Computation Element Communication Protocol
(PCEP) for Point-to-Multipoint Traffic Engineering Label (PCEP) for Point-to-Multipoint Traffic Engineering Label
Switched Paths", draft-ietf-pce-rfc6006bis-02 (work in Switched Paths", draft-ietf-pce-rfc6006bis-02 (work in
progress), April 2017. progress), April 2017.
14.2. Informative References 14.2. Informative References
skipping to change at page 30, line 36 skipping to change at page 30, line 36
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>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>. <http://www.rfc-editor.org/info/rfc4875>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009, DOI 10.17487/RFC5671, October 2009,
<http://www.rfc-editor.org/info/rfc5671>. <http://www.rfc-editor.org/info/rfc5671>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<http://www.rfc-editor.org/info/rfc8051>. <http://www.rfc-editor.org/info/rfc8051>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
[I-D.ietf-pce-pceps] [I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-12 (work in Transport for PCEP", draft-ietf-pce-pceps-14 (work in
progress), April 2017. progress), May 2017.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j. Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)", Computation Element Communications Protocol (PCEP)",
draft-ietf-pce-pcep-yang-02 (work in progress), March draft-ietf-pce-pcep-yang-05 (work in progress), June 2017.
2017.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
Granpark Tower Granpark Tower
3-4-1 Shibaura, Minato-ku 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118 Tokyo 108-8118
Japan Japan
 End of changes. 17 change blocks. 
33 lines changed or deleted 32 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/