draft-ietf-pce-stateful-path-protection-08.txt   draft-ietf-pce-stateful-path-protection-09.txt 
PCE Working Group H. Ananthakrishnan PCE Working Group H. Ananthakrishnan
Internet-Draft Netflix Internet-Draft Netflix
Intended status: Standards Track S. Sivabalan Intended status: Standards Track S. Sivabalan
Expires: February 1, 2020 Cisco Expires: March 2, 2020 Cisco
C. Barth C. Barth
Juniper Networks Juniper Networks
I. Minei I. Minei
Google, Inc Google, Inc
M. Negi M. Negi
Huawei Technologies Huawei Technologies
July 31, 2019 August 30, 2019
PCEP Extensions for Associating Working and Protection LSPs with PCEP Extensions for Associating Working and Protection LSPs with
Stateful PCE Stateful PCE
draft-ietf-pce-stateful-path-protection-08 draft-ietf-pce-stateful-path-protection-09
Abstract Abstract
An active stateful Path Computation Element (PCE) is capable of An active stateful Path Computation Element (PCE) is capable of
computing as well as controlling via Path Computation Element computing as well as controlling via Path Computation Element
Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Communication Protocol (PCEP) Multiprotocol Label Switching Traffic
Engineering Label Switched Paths (MPLS LSP). Furthermore, it is also Engineering Label Switched Paths (MPLS LSP). Furthermore, it is also
possible for an active stateful PCE to create, maintain, and delete possible for an active stateful PCE to create, maintain, and delete
LSPs. This document describes PCEP extension to associate two or LSPs. This document describes PCEP extension to associate two or
more LSPs to provide end-to-end path protection. more LSPs to provide end-to-end path protection.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 February 1, 2020. This Internet-Draft will expire on March 2, 2020.
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 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Path Protection Association Type . . . . . . . . . . . . 5 3.1. Path Protection Association Type . . . . . . . . . . . . 5
3.2. Path Protection Association TLV . . . . . . . . . . . . . 6 3.2. Path Protection Association TLV . . . . . . . . . . . . . 5
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7 4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7
4.2. PCC-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 4.2. PCC-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7
4.3. PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 4.3. PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 8 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 7
4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9
6.2. PPAG TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. PPAG TLV . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Manageability Considerations . . . . . . . . . . . . . . . . 11 8. Manageability Considerations . . . . . . . . . . . . . . . . 11
8.1. Control of Function and Policy . . . . . . . . . . . . . 11 8.1. Control of Function and Policy . . . . . . . . . . . . . 11
8.2. Information and Data Models . . . . . . . . . . . . . . . 11 8.2. Information and Data Models . . . . . . . . . . . . . . . 11
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12
8.6. Impact On Network Operations . . . . . . . . . . . . . . 12 8.6. Impact On Network Operations . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 5, line 27 skipping to change at page 5, line 27
Type" of value TBD1. A PPAG can have one working LSP and/or one or Type" of value TBD1. A PPAG can have one working LSP and/or one or
more protection LSPs. The source, destination and Tunnel ID (as more protection LSPs. The source, destination and Tunnel ID (as
carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per carried in LSP-IDENTIFIERS TLV [RFC8231], with description as per
[RFC3209]) of all LSPs within a PPAG MUST be the same. As per [RFC3209]) of all LSPs within a PPAG MUST be the same. As per
[RFC3209], TE tunnel is used to associate a set of LSPs during [RFC3209], TE tunnel is used to associate a set of LSPs during
reroute or to spread a traffic trunk over multiple paths. reroute or to spread a traffic trunk over multiple paths.
The format of the Association object used for PPAG is specified in The format of the Association object used for PPAG is specified in
[I-D.ietf-pce-association-group]. [I-D.ietf-pce-association-group].
This document defines a new Association type, the "Path Protection
Association Type", value will be assigned by IANA (TBD1).
[I-D.ietf-pce-association-group] specifies the mechanism for the [I-D.ietf-pce-association-group] specifies the mechanism for the
capability advertisement of the Association types supported by a PCEP capability advertisement of the Association types supported by a PCEP
speaker by defining a ASSOC-Type-List TLV to be carried within an speaker by defining a ASSOC-Type-List TLV to be carried within an
OPEN object. This capability exchange for the Association type OPEN object. This capability exchange for the Association type
described in this document (i.e. Path Protection Association Type) described in this document (i.e. Path Protection Association Type)
MAY be done before using the policy association, i.e., the PCEP MAY be done before using the policy association, i.e., the PCEP
speaker MAY include the Path Protection Association Type (TBD1) in speaker MAY include the Path Protection Association Type (TBD1) in
the ASSOC-Type-List TLV before using the PPAG in the PCEP messages. the ASSOC-Type-List TLV before using the PPAG in the PCEP messages.
This Association type is dynamic in nature and created by the PCC or This Association type is dynamic in nature and created by the PCC or
skipping to change at page 6, line 16 skipping to change at page 6, line 8
The Path Protection Association TLV is an optional TLV for use with The Path Protection Association TLV is an optional TLV for use with
the Path Protection Association Type. The Path Protection the Path Protection Association Type. The Path Protection
Association TLV MUST NOT be present more than once. If it appears Association TLV MUST NOT be present more than once. If it appears
more than once, only the first occurrence is processed and any others more than once, only the first occurrence is processed and any others
MUST be ignored. MUST be ignored.
The Path Protection Association TLV follows the PCEP TLV format of The Path Protection Association TLV follows the PCEP TLV format of
[RFC5440]. [RFC5440].
The type (16 bits) of the TLV is to be assigned by IANA. The length The type (16 bits) of the TLV is TBD2. The length field (16 bit) has
field (16 bit) has a fixed value of 4. a fixed value of 4.
The value comprises of a single field, the Path Protection The value comprises of a single field, the Path Protection
Association Flags (32 bits), where each bit represents a flag option. Association Flags (32 bits), where each bit represents a flag option.
The format of the Path Protection Association TLV (Figure 1) is as The format of the Path Protection Association TLV (Figure 1) is as
follows: follows:
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 = TBD2 | Length | | Type = TBD2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Path Protection Association Flags |S|P| | PT | Path Protection Association Flags |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Path Protection Association TLV format Figure 1: Path Protection Association TLV format
Path Protection Association Flags (32 bits) - The following flags are Path Protection Association Flags (32 bits) - The following flags are
currently defined - currently defined -
Protecting (P): 1 bit - This bit is as defined in Section 14.1 of Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
skipping to change at page 8, line 15 skipping to change at page 8, line 4
4.4. Session Termination 4.4. Session Termination
As per [I-D.ietf-pce-association-group] the association information As per [I-D.ietf-pce-association-group] the association information
is cleared along with the LSP state information. When a PCEP session is cleared along with the LSP state information. When a PCEP session
is terminated, after expiry of State Timeout Interval at the PCC, the is terminated, after expiry of State Timeout Interval at the PCC, the
LSP state associated with that PCEP session is reverted to operator- LSP state associated with that PCEP session is reverted to operator-
defined default parameters or behaviors as per [RFC8231]. The same defined default parameters or behaviors as per [RFC8231]. The same
procedure is also followed for the association information. On procedure is also followed for the association information. On
session termination at the PCE, when the LSP state reported by PCC is session termination at the PCE, when the LSP state reported by PCC is
cleared, the association information is also cleared as per cleared, the association information is also cleared as per
[I-D.ietf-pce-association-group]. Where there are no LSPs in a [I-D.ietf-pce-association-group]. Where there are no LSPs in a
association group, the association is considered to be deleted. association group, the association is considered to be deleted.
4.5. Error Handling 4.5. Error Handling
As per the processing rules specified in section 5.4 of As per the processing rules specified in section 5.4 of
[I-D.ietf-pce-association-group], if a PCEP speaker does not support [I-D.ietf-pce-association-group], if a PCEP speaker does not support
this Path Protection Association Type, it would return a PCErr this Path Protection Association Type, it would return a PCErr
message with Error-Type 26 (Early allocation by IANA) "Association message with Error-Type 26 "Association Error" and Error-Value 1
Error" and Error-Value 1 "Association type is not supported". "Association type is not supported".
All LSPs (working or protection) within a PPAG MUST belong to the All LSPs (working or protection) within a PPAG MUST belong to the
same TE Tunnel (as described in [RFC3209]) and have the same source same TE Tunnel (as described in [RFC3209]) and have the same source
and destination. If a PCEP speaker attempts to add an LSP to a PPAG and destination. If a PCEP speaker attempts to add an LSP to a PPAG
and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV [RFC8231], with
description as per [RFC3209]) or source or destination of the LSP is description as per [RFC3209]) or source or destination of the LSP is
different from the LSP(s) in the PPAG, the PCC MUST send PCErr with different from the LSP(s) in the PPAG, the PCC MUST send PCErr with
Error-Type 26 (Early allocation by IANA) (Association Error) Error-Type 26 (Association Error) [I-D.ietf-pce-association-group]
[I-D.ietf-pce-association-group] and Error-Value TBD3 (Tunnel ID or and Error-Value TBD3 (Tunnel ID or End points mismatch for Path
End points mismatch for Path Protection Association). In case of Protection Association). In case of Path Protection, LSP-IDENTIFIERS
Path Protection, LSP-IDENTIFIERS TLV SHOULD be included for all LSPs TLV SHOULD be included for all LSPs (including Segment Routing (SR)
(including Segment Routing (SR) [I-D.ietf-pce-segment-routing]). [I-D.ietf-pce-segment-routing]).
When the PCEP peer does not support the protection type set in PPAG, When the PCEP peer does not support the protection type set in PPAG,
the PCEP peer MUST send PCErr with Error-Type 26 (Early allocation by the PCEP peer MUST send PCErr with Error-Type 26 (Association Error)
IANA) (Association Error) [I-D.ietf-pce-association-group] and Error- [I-D.ietf-pce-association-group] and Error-Value TBD5 (Protection
Value TBD5 (Protection type is not supported). type is not supported).
A given LSP MAY belong to more than one PPAG. If there is a conflict A given LSP MAY belong to more than one PPAG. If there is a conflict
between any of the two PPAGs, the PCEP peer MUST send PCErr with between any of the two PPAGs, the PCEP peer MUST send PCErr with
Error-Type 26 (Early allocation by IANA) (Association Error) Error-Type 26 (Association Error) [I-D.ietf-pce-association-group]
[I-D.ietf-pce-association-group] and Error-Value 6 (Association and Error-Value 6 (Association information mismatch) as per
information mismatch) as per [I-D.ietf-pce-association-group]. [I-D.ietf-pce-association-group].
When the protection type is set to 1+1 or 1:N with N=1, there MUST be When the protection type is set to 1+1 or 1:N with N=1, there MUST be
only one working LSP and one protection LSP within a PPAG. If a PCEP only one working LSP and one protection LSP within a PPAG. If a PCEP
speaker attempts to add another working/protection LSP, the PCEP peer speaker attempts to add another working/protection LSP, the PCEP peer
MUST send PCErr with Error-Type 26 (Early allocation by IANA) MUST send PCErr with Error-Type 26 (Association Error)
(Association Error) [I-D.ietf-pce-association-group] and Error-Value
TBD4 (Attempt to add another working/protection LSP for Path
Protection Association). When the protection type is set to 1:N with
N>1, there MUST be only one working LSP and number of protection LSPs
MUST NOT be more than N within a PPAG. If a PCEP speaker attempts to
add another working/protection LSP, the PCEP peer MUST send PCErr
with Error-Type 26 (Early allocation by IANA) (Association Error)
[I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add [I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add
another working/protection LSP for Path Protection Association). another working/protection LSP for Path Protection Association).
When the protection type is set to 1:N with N>1, there MUST be only
one working LSP and number of protection LSPs MUST NOT be more than N
within a PPAG. If a PCEP speaker attempts to add another working/
protection LSP, the PCEP peer MUST send PCErr with Error-Type 26
(Association Error) [I-D.ietf-pce-association-group] and Error-Value
TBD4 (Attempt to add another working/protection LSP for Path
Protection Association).
All processing as per [I-D.ietf-pce-association-group] continues to All processing as per [I-D.ietf-pce-association-group] continues to
apply. apply.
5. Other Considerations 5. Other Considerations
The working and protection LSPs are typically resource disjoint The working and protection LSPs are typically resource disjoint
(e.g., node, SRLG disjoint). This ensures that a single failure will (e.g., node, SRLG disjoint). This ensures that a single failure will
not affect both the working and protection LSPs. The disjoint not affect both the working and protection LSPs. The disjoint
requirement for a group of LSPs is handled via another Association requirement for a group of LSPs is handled via another Association
type called "Disjointness Association", as described in type called "Disjointness Association", as described in
skipping to change at page 9, line 39 skipping to change at page 9, line 30
[RFC4872] introduces the concept and mechanisms to support the [RFC4872] introduces the concept and mechanisms to support the
association of one LSP to another LSP across different RSVP - Traffic association of one LSP to another LSP across different RSVP - Traffic
Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION
object. The information in the PPAG TLV in PCEP as received from the object. The information in the PPAG TLV in PCEP as received from the
PCE, is used to trigger the signalling of working LSP and protection PCE, is used to trigger the signalling of working LSP and protection
LSP, with the Path Protection Association Flags mapped to the LSP, with the Path Protection Association Flags mapped to the
corresponding fields in the PROTECTION Object in RSVP-TE. corresponding fields in the PROTECTION Object in RSVP-TE.
6. IANA Considerations 6. IANA Considerations
[Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain
"TBD1" through "TBD5" those should be replaced by the values that
IANA assigns.]
6.1. Association Type 6.1. Association Type
This document defines a new Association type, originally defined in This document defines a new Association type, originally defined in
[I-D.ietf-pce-association-group], for path protection. IANA is [I-D.ietf-pce-association-group], for path protection. IANA is
requested to make the assignment of a new value for the sub-registry requested to make the assignment of a new value for the sub-registry
"ASSOCIATION Type Field" (request to be created in "ASSOCIATION Type Field" (request to be created in
[I-D.ietf-pce-association-group]), as follows: [I-D.ietf-pce-association-group]), as follows:
+----------------------+-------------------------+------------------+ +----------------------+-------------------------+------------------+
| Association type | Association Name | Reference | | Association type | Association Name | Reference |
skipping to change at page 12, line 35 skipping to change at page 12, line 29
operations in addition to those already listed in [RFC5440], operations in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
9. Acknowledgments 9. Acknowledgments
We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for
their contributions to this document. their contributions to this document.
Thanks to Ines Robles for the RTGDIR review. Thanks to Ines Robles for the RTGDIR review.
Thanks to Pete Resnick for the GENART review.
10. References 10. References
10.1. Normative References 10.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
skipping to change at page 14, line 48 skipping to change at page 14, line 43
[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-12 (work in progress), July 2019. yang-12 (work in progress), July 2019.
[I-D.ietf-pce-association-diversity] [I-D.ietf-pce-association-diversity]
Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
Extension for LSP Diversity Constraint Signaling", draft- Extension for LSP Diversity Constraint Signaling", draft-
ietf-pce-association-diversity-08 (work in progress), July ietf-pce-association-diversity-09 (work in progress),
2019. August 2019.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-16 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
March 2019. March 2019.
[I-D.litkowski-pce-state-sync] [I-D.litkowski-pce-state-sync]
Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
Stateful Path Computation Element (PCE) Communication Stateful Path Computation Element (PCE) Communication
 End of changes. 21 change blocks. 
38 lines changed or deleted 43 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/