draft-ietf-pce-rfc6006bis-03.txt   draft-ietf-pce-rfc6006bis-04.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: January 04, 2018 D. King Expires: March 30, 2018 D. King
Old Dog Consulting Old Dog Consulting
July 03, 2017 September 26, 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-03 draft-ietf-pce-rfc6006bis-04
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.
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 January 04, 2018. This Internet-Draft will expire on March 30, 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 2, line 34 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology ................................................4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language ......................................5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. PCC-PCE Communication Requirements ..............................5 2. PCC-PCE Communication Requirements . . . . . . . . . . . . . . 5
3. Protocol Procedures and Extensions ..............................6 3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 6
3.1. P2MP Capability Advertisement ..............................6 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 6
3.1.1. P2MP Computation TLV in the Existing PCE 3.1.1. P2MP Computation TLV in the Existing PCE Discovery
Discovery Protocol ..................................6 Protocol . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Open Message Extension ..............................7 3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 8
3.2. Efficient Presentation of P2MP LSPs ........................7 3.2. Efficient Presentation of P2MP LSPs . . . . . . . . . . . 8
3.3. P2MP Path Computation Request/Reply Message Extensions .....8 3.3. P2MP Path Computation Request/Reply Message Extensions . . 9
3.3.1. The Extension of the RP Object ......................8 3.3.1. The Extension of the RP Object . . . . . . . . . . . . 9
3.3.2. The New P2MP END-POINTS Object ......................9 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 10
3.4. Request Message Format ....................................12 3.4. Request Message Format . . . . . . . . . . . . . . . . . . 13
3.5. Reply Message Format ......................................12 3.5. Reply Message Format . . . . . . . . . . . . . . . . . . . 14
3.6. P2MP Objective Functions and Metric Types .................13 3.6. P2MP Objective Functions and Metric Types . . . . . . . . 15
3.6.1. New Objective Functions ............................13 3.6.1. New Objective Functions . . . . . . . . . . . . . . . 15
3.6.2. New Metric Object Types ............................14 3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 16
3.7. Non-Support of P2MP Path Computation ......................14 3.7. Non-Support of P2MP Path Computation . . . . . . . . . . . 16
3.8. Non-Support by Back-Level PCE Implementations .............15 3.8. Non-Support by Back-Level PCE Implementations . . . . . . 18
3.9. P2MP TE Path Reoptimization Request .......................15 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . . 18
3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16 3.10. Adding and Pruning Leaves to/from the P2MP Tree . . . . . 19
3.11. Discovering Branch Nodes .................................19 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . 22
3.11.1. Branch Node Object ................................19 3.11.1. Branch Node Object . . . . . . . . . . . . . . . . . 22
3.12. Synchronization of P2MP TE Path Computation Requests .....19 3.12. Synchronization of P2MP TE Path Computation Requests . . 22
3.13. Request and Response Fragmentation .......................20 3.13. Request and Response Fragmentation . . . . . . . . . . . 23
3.13.1. Request Fragmentation Procedure ...................21 3.13.1. Request Fragmentation Procedure . . . . . . . . . . . 24
3.13.2. Response Fragmentation Procedure ..................21 3.13.2. Response Fragmentation Procedure . . . . . . . . . . 24
3.13.3. Fragmentation Examples ............................21 3.13.3. Fragmentation Examples . . . . . . . . . . . . . . . 24
3.14. UNREACH-DESTINATION Object ...............................22 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . 25
3.15. P2MP PCEP-ERROR Objects and Types ........................23 3.15. P2MP PCEP-ERROR Objects and Types . . . . . . . . . . . . 26
3.16. PCEP NO-PATH Indicator ...................................24 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . 27
4. Manageability Considerations ...................................25 4. Manageability Considerations . . . . . . . . . . . . . . . . . 28
4.1. Control of Function and Policy ............................25 4.1. Control of Function and Policy . . . . . . . . . . . . . . 28
4.2. Information and Data Models ...............................25 4.2. Information and Data Models . . . . . . . . . . . . . . . 28
4.3. Liveness Detection and Monitoring .........................25 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 28
4.4. Verifying Correct Operation ...............................25 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 29
4.5. Requirements for Other Protocols and Functional 4.5. Requirements for Other Protocols and Functional
Components ................................................26 Components . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6. Impact on Network Operation ...............................26 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 30
5. Security Considerations ........................................26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations ............................................27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6.1. PCEP TLV Type Indicators ..................................27 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 31
6.2. Request Parameter Bit Flags ...............................27 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . . 31
6.3. Objective Functions .......................................27 6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 31
6.4. Metric Object Types .......................................27 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . . 32
6.5. PCEP Objects ..............................................28 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 32
6.6. PCEP-ERROR Objects and Types ..............................29 6.6. PCEP-ERROR Objects and Types . . . . . . . . . . . . . . . 33
6.7. PCEP NO-PATH Indicator ....................................30 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 34
6.8. SVEC Object Flag ..........................................30 6.8. SVEC Object Flag . . . . . . . . . . . . . . . . . . . . . 34
6.9. OSPF PCE Capability Flag ..................................30 6.9. OSPF PCE Capability Flag . . . . . . . . . . . . . . . . . 35
7. Acknowledgements ...............................................30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
8. References .....................................................30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References ......................................30 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References ....................................32 8.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Summary of the all Changes from RFC 6006 . . . . . . . 40
Appendix A.1 RBNF Changes from RFC 6006 . . . . . . . . . . . . . 40
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] 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 4, line 33 skipping to change at page 4, line 45
computation for P2MP TE LSPs. One path computation request message computation for P2MP TE LSPs. One path computation request message
from a PCC may request the computation of the whole P2MP TE LSP, or from a PCC may request the computation of the whole P2MP TE LSP, or
the request may be limited to a sub-set of the S2L sub-LSPs. In the the request may be limited to a sub-set of the S2L sub-LSPs. In the
extreme case, the PCC may request the S2L sub-LSPs to be computed extreme case, the PCC may request the S2L sub-LSPs to be computed
individually with it being the PCC's responsibility to decide whether individually with it being the PCC's responsibility to decide whether
to signal individual S2L sub-LSPs or combine the computation results to signal individual S2L sub-LSPs or combine the computation results
to signal the entire P2MP TE LSP. Hence the PCC may use one path to signal the entire P2MP TE LSP. Hence the PCC may use one path
computation request message or may split the request across multiple computation request message or may split the request across multiple
path computation messages. path computation messages.
This document obsoletes RFC 6006 and incorporates all outstanding This document obsoletes [RFC6006] and incorporates all outstanding
Errata: Errata:
o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868. o Erratum with IDs: 3819, 3830, 3836, 4867, 4868 and 4956.
1.1. Terminology All changes from [RFC6006] are listed in Appendix A.
1.1. Terminology
Terminology used in this document: Terminology used in this document:
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
LSR: Label Switching Router. LSR: Label Switching Router.
OF: Objective Function: A set of one or more optimization criteria OF: Objective Function: A set of one or more optimization criteria
used for the computation of a single path (e.g., path cost used for the computation of a single path (e.g., path cost
minimization), or for the synchronized computation of a set of minimization), or for the synchronized computation of a set of
paths (e.g., aggregate bandwidth consumption minimization). paths (e.g., aggregate bandwidth consumption minimization).
skipping to change at page 6, line 8 skipping to change at page 5, line 25
P2MP: Point-to-Multipoint. P2MP: Point-to-Multipoint.
P2P: Point-to-Point. P2P: Point-to-Point.
This document also uses the terminology defined in [RFC4655], This document also uses the terminology defined in [RFC4655],
[RFC4875], and [RFC5440]. [RFC4875], and [RFC5440].
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. PCC-PCE Communication Requirements 2. PCC-PCE Communication Requirements
This section summarizes the PCC-PCE communication requirements for This section summarizes the PCC-PCE communication requirements for
P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system
corresponds to the requirement numbers used in [RFC5862]. corresponds to the requirement numbers used in [RFC5862].
1. The PCC MUST be able to specify that the request is a P2MP path 1. The PCC MUST be able to specify that the request is a P2MP path
computation request. computation request.
skipping to change at page 28, line 40 skipping to change at page 28, line 40
4.2. Information and Data Models 4.2. Information and Data Models
A number of MIB objects have been defined for general PCEP control A number of MIB objects have been defined for general PCEP control
and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies
that MIB objects will be required to support the control and that MIB objects will be required to support the control and
monitoring of the protocol extensions defined in this document. A new monitoring of the protocol extensions defined in this document. A new
document will be required to define MIB objects for PCEP control and document will be required to define MIB objects for PCEP control and
monitoring of P2MP computations. monitoring of P2MP computations.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to also The PCEP YANG model "ietf-pcep" is specified in [I-D.ietf-pce-pcep-
include the P2MP related parameters. yang]. The P2MP capability of a PCEP entity or a configured peer, can
be set using this YANG model. Also the support for P2MP path
computation can be learned using this model. The statistics are
maintained in the model "ietf-pcep-stats" as specified in [I-D.ietf-
pce-pcep-yang]. This YANG model will be required to be augmented to
also include the P2MP related statistics.
4.3. Liveness Detection and Monitoring 4.3. Liveness Detection and Monitoring
There are no additional considerations beyond those expressed in There are no additional considerations beyond those expressed in
[RFC5440], since [RFC5862] does not address any additional [RFC5440], since [RFC5862] does not address any additional
requirements. requirements.
4.4. Verifying Correct Operation 4.4. Verifying Correct Operation
There are no additional requirements beyond those expressed in There are no additional requirements beyond those expressed in
skipping to change at page 30, line 32 skipping to change at page 30, line 32
sent to the PCE, the load on the PCE may also be significantly sent to the PCE, the load on the PCE may also be significantly
increased. increased.
5. Security Considerations 5. Security Considerations
As described in [RFC5862], P2MP path computation requests are more As described in [RFC5862], P2MP path computation requests are more
CPU-intensive and also utilize more link bandwidth. In the event of CPU-intensive and also utilize more link bandwidth. In the event of
an unauthorized P2MP path computation request, or a denial of service an unauthorized P2MP path computation request, or a denial of service
attack, the subsequent PCEP requests and processing may be disruptive attack, the subsequent PCEP requests and processing may be disruptive
to the network. Consequently, it is important that implementations to the network. Consequently, it is important that implementations
conform to the relevant security requirements of [RFC5440] that conform to the relevant security requirements that specifically help
specifically help to minimize or negate unauthorized P2MP path to minimize or negate unauthorized P2MP path computation requests and
computation requests and denial of service attacks. These mechanisms denial of service attacks. These mechanisms include:
include:
o Securing the PCEP session requests and responses using TCP o Securing the PCEP session requests and responses is RECOMMENDED
security techniques (Section 10.2 of [RFC5440]). using TCP security techniques such as TCP Authentication Option
(TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I-
D.ietf-pce-pceps], as per the recommendations and best current
practices in [RFC7525].
o Authenticating the PCEP requests and responses to ensure the o Authenticating the PCEP requests and responses to ensure the
message is intact and sent from an authorized node (Section 10.3 message is intact and sent from an authorized node using TCP-AO or
of [RFC5440]). TLS is RECOMMENDED.
o Providing policy control by explicitly defining which PCCs, via IP o Providing policy control by explicitly defining which PCCs, via IP
access-lists, are allowed to send P2MP path requests to the PCE access-lists, are allowed to send P2MP path requests to the PCE.
(Section 10.6 of [RFC5440]).
PCEP operates over TCP, so it is also important to secure the PCE and PCEP operates over TCP, so it is also important to secure the PCE and
PCC against TCP denial of service attacks. Section 10.7.1 of PCC against TCP denial of service attacks.
[RFC5440] outlines a number of mechanisms for minimizing the risk of
TCP based denial of service attacks against PCEs and PCCs.
PCEP implementations SHOULD consider the additional security provided As stated in [RFC6952], PCEP implementations SHOULD support TCP-AO
by Transport Layer Security (TLS) [I-D.ietf-pce-pceps].
[RFC5925] and not use TCP-MD5 because of the known vulnerabilities
and weakness.
6. IANA Considerations 6. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA IANA maintains a registry of PCEP parameters. A number of IANA
considerations have been highlighted in previous sections of this considerations have been highlighted in previous sections of this
document. IANA made the allocations as per [RFC6006]. document. IANA made the allocations as per [RFC6006].
6.1. PCEP TLV Type Indicators 6.1. PCEP TLV Type Indicators
As described in Section 3.1.2., the P2MP capability TLV allows the As described in Section 3.1.2., the P2MP capability TLV allows the
skipping to change at page 32, line 44 skipping to change at page 32, line 44
Object-Class Value 4 Object-Class Value 4
Name END-POINTS Name END-POINTS
Object-Type 3: IPv4 Object-Type 3: IPv4
4: IPv6 4: IPv6
5-15: Unassigned 5-15: Unassigned
Reference [This I-D] Reference [This I-D]
As described in Section 3.2, Section 3.11.1, and Section 3.14, four As described in Section 3.2, Section 3.11.1, and Section 3.14, four
PCEP Object-Classes and six PCEP Object-Types have been defined. PCEP Object-Classes and six PCEP Object-Types have been defined.
IANA has made an allocations from the "PCEP Objects" sub- registry, IANA has made an allocations from the "PCEP Objects" sub-registry,
where RFC 6006 was the reference. IANA is requested to update the where RFC 6006 was the reference. IANA is requested to update the
reference as follows to point to this document. reference as follows to point to this document.
Also, for the following four PCEP objects, the code-point 0 for the
Object-Type field are marked "Reserved" with reference to Errata ID
4956. IANA is requested to update the reference to point to this
document.
Object-Class Value 28 Object-Class Value 28
Name UNREACH-DESTINATION Name UNREACH-DESTINATION
Object-Type 0: Reserved Object-Type 0: Reserved
1: IPv4 1: IPv4
2: IPv6 2: IPv6
3-15: Unassigned 3-15: Unassigned
Reference [This I-D] Reference [This I-D]
Object-Class Value 29 Object-Class Value 29
Name SERO Name SERO
skipping to change at page 35, line 39 skipping to change at page 35, line 44
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 Thanks to Jonathan Hardwick for being the document shepherd and
provide comments and guidance. provide comments and guidance.
Thanks to Ben Niven-Jenkins for RTGDIR reviews. Thanks to Ben Niven-Jenkins for RTGDIR reviews.
Thanks to Roni Even for GENART reviews.
Thanks to Fred Baker for OPSDIR review.
Thanks to Deborah Brungard for being the responsible AD and guiding Thanks to Deborah Brungard for being the responsible AD and guiding
the authors. the authors.
Thanks to Mirja Kuhlewind, Alvaro Retana, Ben Campbell, Adam Roach,
Benoit Claise, Suresh Krishnan and Eric Rescorla for the IESG review
and comments.
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.
skipping to change at page 37, line 28 skipping to change at page 38, line 28
[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)", (P2MP) MPLS and GMPLS Traffic Engineering (TE)",
RFC 5671, October 2009. RFC 5671, October 2009.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients
(PCC) - Path Computation Element (PCE) Requirements for (PCC) - Path Computation Element (PCE) Requirements for
Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, September 2010. Paths", RFC 6006, September 2010.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
[RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J. [RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J.
Hardwick "PCE communication protocol (PCEP) Management Hardwick "PCE communication protocol (PCEP) Management
Information Base (MIB) Module", RFC 7420, December 2014. Information Base (MIB) Module", RFC 7420, December 2014.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525 May 2015.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[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-yang Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
(work in progress), March 2017. (work in progress), June 2017.
[I-D.ietf-pce-pceps] [I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps (work in Transport for PCEP", draft-ietf-pce-pceps (work in
progress), January 2017. progress), August 2017.
Appendix A. Summary of the RBNF Changes from RFC 6006 Appendix A. Summary of the all Changes from RFC 6006
o Updated the text to use the term "PCC" instead of "user" while
describing the encoding rules in section 3.10.
o Updated the example in figure 7 to explicitly include the RP
object.
o Corrected the description of F-bit in the RP object in section
3.13, as per the errata ID 3836.
o Corrected the description of fragmentation procedure for the
response in section 3.13.2, as per the errata ID 3819.
o Corrected the Error-Type in section 3.15 for fragmentation, as per
the errata ID 3830.
o Updated the references for OSPF Router Information Link State
Advertisement (LSA) [RFC7770] and PCEP-MIB [RFC7420].
o Add updated information and references for PCEP YANG [I-D.ietf-pce-
pcep-yang] and PCEPS [I-D.ietf-pce-pceps].
o Updated security considerations to include TCP-AO and TLS.
o Updated IANA considerations to mark code-point 0 as reserved for
the object type defined in this document, as per the errata ID 4956.
IANA references are also updated to point to this document.
Appendix A.1 RBNF Changes from RFC 6006
o Update to RBNF for Request message format: o Update to RBNF for Request message format:
* Update to the request message to allow for the bundling of * Update to the request message to allow for the bundling of
multiple path computation requests within a single Path multiple path computation requests within a single Path
Computation Request (PCReq) message. Computation Request (PCReq) message.
* Addition of <svec-list> in PCReq message. This object was missed * Addition of <svec-list> in PCReq message. This object was missed
in [RFC6006]. in [RFC6006].
skipping to change at page 38, line 32 skipping to change at page 41, line 12
* Removed the BANDWIDTH Object followed by Record Route Object * Removed the BANDWIDTH Object followed by Record Route Object
(RRO) from <RRO-List>. As BANDWIDTH object doesn't need to follow (RRO) from <RRO-List>. As BANDWIDTH object doesn't need to follow
for each RRO in the <RRO-List>, there already exist BANDWIDTH for each RRO in the <RRO-List>, there already exist BANDWIDTH
object follow <RRO-List> and is backward compatible with object follow <RRO-List> and is backward compatible with
[RFC5440]. [RFC5440].
* Update to the <end-point-rro-pair-list>, to allow optional * Update to the <end-point-rro-pair-list>, to allow optional
BANDWIDTH object only if <RRO-List> is included. BANDWIDTH object only if <RRO-List> is included.
* Errata ID: 4867
o Update the RBNF for Reply message format: o Update the RBNF for Reply message format:
* Update to the reply message to allow for bundling of multiple * Update to the reply message to allow for bundling of multiple
path computation requests within a single Path Computation Reply path computation replies within a single Path Computation Reply
(PCRep) message. (PCRep) message.
* Addition of the UNREACH-DESTINATION in PCRep message. This * Addition of the UNREACH-DESTINATION in PCRep message. This
object was missed in [RFC6006]. object was missed in [RFC6006].
* Errata ID: 4868
Contributors Contributors
Fabien Verhaeghe Fabien Verhaeghe
Thales Communication France Thales Communication France
160 Bd Valmy 92700 Colombes 160 Bd Valmy 92700 Colombes
France France
EMail: fabien.verhaeghe@gmail.com EMail: fabien.verhaeghe@gmail.com
Tomonori Takeda Tomonori Takeda
NTT Corporation NTT Corporation
skipping to change at page 39, line 38 skipping to change at page 42, line 23
Mohamad Chaitou Mohamad Chaitou
France France
EMail: mohamad.chaitou@gmail.com EMail: mohamad.chaitou@gmail.com
Udayasree Palle Udayasree Palle
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: udayasree.palle@huawei.com EMail: udayasreereddy@gmail.com
Authors' Addresses Authors' Addresses
Quintin Zhao Quintin Zhao
Huawei Technology Huawei Technology
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US US
EMail: quintin.zhao@huawei.com EMail: quintin.zhao@huawei.com
Dhruv Dhody Dhruv Dhody
 End of changes. 31 change blocks. 
87 lines changed or deleted 163 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/