draft-ietf-pce-rfc6006bis-02.txt   draft-ietf-pce-rfc6006bis-03.txt 
PCE Working Group Q. Zhao PCE Working Group Q. Zhao
Internet-Draft D. Dhody, Ed. Internet-Draft D. Dhody, Ed.
Intended status: Standards Track R. Palleti Intended status: Standards Track R. Palleti
Obsoletes: 6006 (if approved) Huawei Technology Obsoletes: 6006 (if approved) Huawei Technology
Expires: October 12, 2017 D. King Expires: January 04, 2018 D. King
Old Dog Consulting Old Dog Consulting
April 10, 2017 July 03, 2017
Extensions to Extensions to
the Path Computation Element Communication Protocol (PCEP) the Path Computation Element Communication Protocol (PCEP)
for Point-to-Multipoint Traffic Engineering Label Switched Paths for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-rfc6006bis-02 draft-ietf-pce-rfc6006bis-03
Abstract Abstract
Point-to-point Multiprotocol Label Switching (MPLS) and Generalized Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
be established using signaling techniques, but their paths may first be established using signaling techniques, but their paths may first
need to be determined. The Path Computation Element (PCE) has been need to be determined. The Path Computation Element (PCE) has been
identified as an appropriate technology for the determination of the identified as an appropriate technology for the determination of the
paths of point-to-multipoint (P2MP) TE LSPs. paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE communication Protocol This document describes extensions to the PCE communication Protocol
(PCEP) to handle requests and responses for the computation of paths (PCEP) to handle requests and responses for the computation of paths
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 September 11, 2017. This Internet-Draft will expire on January 04, 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 9, line 17 skipping to change at page 9, line 17
same as the SRRO defined in [RFC4873]. same as the SRRO defined in [RFC4873].
The SERO and SRRO are used to report the route of an existing TE LSP The SERO and SRRO are used to report the route of an existing TE LSP
for which a reoptimization is desired. The format and content of the for which a reoptimization is desired. The format and content of the
SERO and SRRO are defined in [RFC4875]. SERO and SRRO are defined in [RFC4875].
A new PCEP object class and type are requested for SERO and SRRO. A new PCEP object class and type are requested for SERO and SRRO.
Object-Class Value 29 Object-Class Value 29
Name SERO Name SERO
Object-Type 1: SERO Object-Type 0: Reserved
1: SERO
2-15: Unassigned 2-15: Unassigned
Reference RFC 6006 Reference [This I-D]
Object-Class Value 30 Object-Class Value 30
Name SRRO Name SRRO
Object-Type 1: SRRO Object-Type 0: Reserved
1: SRRO
2-15: Unassigned 2-15: Unassigned
Reference RFC 6006 Reference [This I-D]
The IANA assignment is documented in Section 6.5 ("PCEP Objects"). The IANA assignment is documented in Section 6.5 ("PCEP Objects").
Since the explicit path is available for immediate signaling by the Since the explicit path is available for immediate signaling by the
MPLS or GMPLS control plane, the meanings of all of the sub-objects MPLS or GMPLS control plane, the meanings of all of the sub-objects
and fields in this object are identical to those defined for the ERO. and fields in this object are identical to those defined for the ERO.
3.3. P2MP Path Computation Request/Reply Message Extensions 3.3. P2MP Path Computation Request/Reply Message Extensions
This document extends the existing P2P RP (Request Parameters) object This document extends the existing P2P RP (Request Parameters) object
skipping to change at page 18, line 16 skipping to change at page 18, line 16
If a PCE receives a P2MP request and the PCE does not understand the If a PCE receives a P2MP request and the PCE does not understand the
P2MP flag in the RP object, and therefore the PCEP P2MP extensions, P2MP flag in the RP object, and therefore the PCEP P2MP extensions,
then the PCE SHOULD reject the request. then the PCE SHOULD reject the request.
3.9. P2MP TE Path Reoptimization Request 3.9. P2MP TE Path Reoptimization Request
A reoptimization request for a P2MP TE path is specified by the use A reoptimization request for a P2MP TE path is specified by the use
of the R-bit within the RP object as defined in [RFC5440] and is of the R-bit within the RP object as defined in [RFC5440] and is
similar to the reoptimization request for a P2P TE path. The only similar to the reoptimization request for a P2P TE path. The only
difference is that the user MUST insert the list of RROs and SRROs difference is that the PCC MUST insert the list of RROs and SRROs
after each type of END-POINTS in the PCReq message, as described in after each type of END-POINTS in the PCReq message, as described in
the "Request Message Format" section (Section 3.4) of this document. the "Request Message Format" section (Section 3.4) of this document.
An example of a reoptimization request and subsequent PCReq message An example of a reoptimization request and subsequent PCReq message
is described below: is described below:
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
END-POINTS for leaf type 3 END-POINTS for leaf type 3
RRO list RRO list
skipping to change at page 19, line 8 skipping to change at page 19, line 8
RRO list RRO list
END-POINTS for leaf type 4 END-POINTS for leaf type 4
RRO list RRO list
OF (optional) OF (optional)
Figure 6. PCReq Message Example 2 for Optimization Figure 6. PCReq Message Example 2 for Optimization
3.10. Adding and Pruning Leaves to/from the P2MP Tree 3.10. Adding and Pruning Leaves to/from the P2MP Tree
When adding new leaves to or removing old leaves from the existing When adding new leaves to or removing old leaves from the existing
P2MP tree, by supplying a list of existing leaves, it SHOULD be P2MP tree, by supplying a list of existing leaves, it is possible to
possible to optimize the existing P2MP tree. This section explains optimize the existing P2MP tree. This section explains the methods
the methods for adding new leaves to or removing old leaves from the for adding new leaves to or removing old leaves from the existing
existing P2MP tree. P2MP tree.
To add new leaves, the user MUST build a P2MP request using END- To add new leaves, the PCC MUST build a P2MP request using END-
POINTS with leaf type 1. POINTS with leaf type 1.
To remove old leaves, the user must build a P2MP request using END- To remove old leaves, the PCC MUST build a P2MP request using END-
POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE
MUST send an error type 17, value=1: The PCE is not capable of MUST send an error type 17, value=1: The PCE is not capable of
satisfying the request due to no END-POINTS with leaf type 2. satisfying the request due to no END-POINTS with leaf type 2.
When adding new leaves to or removing old leaves from the existing When adding new leaves to or removing old leaves from the existing
P2MP tree, the PCC must also provide the list of old leaves, if any, P2MP tree, the PCC MUST also provide the list of old leaves, if any,
including END-POINTS with leaf type 3, leaf type 4, or both. New including END-POINTS with leaf type 3, leaf type 4, or both. New
PCEP-ERROR objects and types are necessary for reporting when certain PCEP-ERROR objects and types are necessary for reporting when certain
conditions are not satisfied (i.e., when there are no END-POINTS with conditions are not satisfied (i.e., when there are no END-POINTS with
leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1
or 2). A generic "Inconsistent END-POINT" error will be used if a or 2). A generic "Inconsistent END-POINT" error will be used if a
PCC receives a request that has an inconsistent END-POINT (i.e., if a PCC receives a request that has an inconsistent END-POINT (i.e., if a
leaf specified as type 1 already exists). These IANA assignments are leaf specified as type 1 already exists). These IANA assignments are
documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this
document. document.
For old leaves, the user MUST provide the old path as a list of RROs For old leaves, the PCC MUST provide the old path as a list of RROs
that immediately follows each END-POINTS object. This document that immediately follows each END-POINTS object. This document
specifies error values when specific conditions are not satisfied. specifies error values when specific conditions are not satisfied.
The following examples demonstrate full and partial reoptimization of The following examples demonstrate full and partial reoptimization of
existing P2MP LSPs: existing P2MP LSPs:
Case 1: Adding leaves with full reoptimization of existing paths Case 1: Adding leaves with full reoptimization of existing paths
Common Header Common Header
RP with P2MP flag/R-bit set RP with P2MP flag/R-bit set
skipping to change at page 36, line 5 skipping to change at page 35, line 34
Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan
Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean
Turner for their valuable comments and input on the RFC 6006. Turner for their valuable comments and input on the RFC 6006.
Thanks to Deborah Brungard for handling of related errata on the RFC Thanks to Deborah Brungard for handling of related errata on the RFC
6006. 6006.
Authors would like to thank Jonathan Hardwick and Adrian Farrel for Authors would like to thank Jonathan Hardwick and Adrian Farrel for
providing review comments with suggested text for this document. providing review comments with suggested text for this document.
Thanks to Jonathan Hardwick for being the document shepherd and
provide comments and guidance.
Thanks to Ben Niven-Jenkins for RTGDIR reviews.
Thanks to Deborah Brungard for being the responsible AD and guiding
the authors.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
 End of changes. 16 change blocks. 
18 lines changed or deleted 28 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/