< draft-ietf-teas-assoc-corouted-bidir-frr-03.txt   draft-ietf-teas-assoc-corouted-bidir-frr-04.txt >
TEAS Working Group R. Gandhi, Ed. TEAS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track H. Shah Updates: 4090, 7551 H. Shah
Expires: November 15, 2018 Ciena Intended Status: Standards Track Ciena
J. Whittaker Expires: January 12, 2019 J. Whittaker
Verizon Verizon
May 14, 2018 July 11, 2018
Fast Reroute Procedures for Updates to the Fast Reroute Procedures for
Co-routed Associated Bidirectional Label Switched Paths (LSPs) Co-routed Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-teas-assoc-corouted-bidir-frr-03 draft-ietf-teas-assoc-corouted-bidir-frr-04
Abstract Abstract
Resource Reservation Protocol (RSVP) association signaling can be Resource Reservation Protocol (RSVP) association signaling can be
used to bind two unidirectional LSPs into an associated bidirectional used to bind two unidirectional LSPs into an associated bidirectional
LSP. When an associated bidirectional LSP is co-routed, the reverse LSP. When an associated bidirectional LSP is co-routed, the reverse
LSP follows the same path as its forward LSP. This document LSP follows the same path as its forward LSP. This document updates
describes Fast Reroute (FRR) procedures for both single-sided and the Fast Reroute (FRR) procedures defined in RFC 4090 to support both
double-sided provisioned associated bidirectional LSPs. The FRR single-sided and double-sided provisioned associated bidirectional
procedures can ensure that for the co-routed LSPs, traffic flows on LSPs. This document also updates the procedure for associating two
co-routed paths in the forward and reverse directions after a failure reverse LSPs defined in RFC 7551 to support co-routed bidirectional
event. LSPs. The FRR procedures can ensure that for the co-routed LSPs,
traffic flows on co-routed paths in the forward and reverse
directions after a failure event.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 2, line 23 skipping to change at page 2, line 25
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. Assumptions and Considerations . . . . . . . . . . . . . . 3 1.1. Assumptions and Considerations . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4 2.2.1. Forward Unidirectional LSPs . . . . . . . . . . . . . 4
2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 5 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5 3.1. Fast Reroute Bypass Tunnel Assignment . . . . . . . . . . 5
3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6 3.2. Node Protection Bypass Tunnels . . . . . . . . . . . . . . 6
3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7 3.3. Bidirectional LSP Association At Mid-Points . . . . . . . 7
4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8 4. Signaling Procedure . . . . . . . . . . . . . . . . . . . . . 8
4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8 4.1. Associated Bidirectional LSP Fast Reroute . . . . . . . . 8
4.1.1. Restoring Co-routing with Node Protection Bypass 4.1.1. Restoring Co-routing with Node Protection Bypass
Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9 Tunnels . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9 4.1.2. Unidirectional Link Failures . . . . . . . . . . . . . 9
4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10 4.1.3. Revertive Behavior after Fast Reroute . . . . . . . . 10
4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10 4.1.4. Bypass Tunnel Provisioning . . . . . . . . . . . . . . 10
4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10 4.1.5. One-to-One Bypass Tunnel . . . . . . . . . . . . . . . 10
4.2. Bidirectional LSP Association At Mid-points . . . . . . . 11 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 10
5. Message and Object Definitions . . . . . . . . . . . . . . . . 11 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Extended ASSOCIATION ID . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Appendix A. Example of Extended ASSOCIATION ID . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION The Resource Reservation Protocol (RSVP) (Extended) ASSOCIATION
Object is specified in [RFC6780] which can be used generically to Object is specified in [RFC6780] which can be used generically to
associate (G)Multiprotocol Label Switching (MPLS) Traffic Engineering associate (G)Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for (TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for
binding two point-to-point unidirectional LSPs [RFC3209] into an binding two point-to-point unidirectional LSPs [RFC3209] into an
associated bidirectional LSP. There are two models described in associated bidirectional LSP. There are two models described in
[RFC7551] for provisioning an associated bidirectional LSP, single- [RFC7551] for provisioning an associated bidirectional LSP, single-
sided and double-sided. In both models, the reverse LSP of the sided and double-sided. In both models, the reverse LSP of the
bidirectional LSP may or may not be co-routed and follow the same bidirectional LSP may or may not be co-routed and follow the same
path as its forward LSP. path as its forward LSP.
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE allows stateful control of the MPLS TE LSPs which
may be initiated by the PCE or a PCC. As defined in [PCE-ASSOC-
BIDIR], a Stateful PCE can be employed to initiate single-sided and
double-sided associated bidirectional LSPs on PCC(s).
In packet transport networks, there are requirements where the In packet transport networks, there are requirements where the
reverse LSP of a bidirectional LSP needs to follow the same path as reverse LSP of a bidirectional LSP needs to follow the same path as
its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370] its forward LSP [RFC6373]. The MPLS Transport Profile (TP) [RFC6370]
architecture facilitates the co-routed bidirectional LSP by using the architecture facilitates the co-routed bidirectional LSP by using the
GMPLS extensions [RFC3473] to achieve congruent paths. However, the GMPLS extensions [RFC3473] to achieve congruent paths. However, the
RSVP association signaling allows to enable co-routed bidirectional RSVP association signaling allows to enable co-routed bidirectional
LSPs without having to deploy GMPLS extensions in the existing LSPs without having to deploy GMPLS extensions in the existing
networks. The association signaling also allows to take advantage of networks. The association signaling also allows to take advantage of
the existing TE and Fast Reroute (FRR) mechanisms in the network. the existing TE and Fast Reroute (FRR) mechanisms in the network.
[RFC4090] defines FRR extensions for MPLS TE LSPs and those are also [RFC4090] defines FRR extensions for MPLS TE LSPs and those are also
applicable to the associated bidirectional LSPs. [RFC8271] defines applicable to the associated bidirectional LSPs. [RFC8271] defines
FRR procedure for GMPLS signaled bidirectional LSPs, such as, FRR procedure for GMPLS signaled bidirectional LSPs, such as,
coordinate bypass tunnel assignments in the forward and reverse coordinate bypass tunnel assignments in the forward and reverse
directions of the LSP. The mechanisms defined in [RFC8271] are also directions of the LSP. The mechanisms defined in [RFC8271] are also
useful for the FRR of associated bidirectional LSPs. useful for the FRR of associated bidirectional LSPs.
This document describes FRR procedures for both single-sided and This document updates the FRR procedures defined in [RFC4090] to
double-sided provisioned associated bidirectional LSPs. The FRR support both single-sided and double-sided provisioned associated
procedures can ensure that for the co-routed LSPs, traffic flows on bidirectional LSPs. This document also updates the procedure for
co-routed paths in the forward and reverse directions after a failure associating two reverse LSPs defined in [RFC7551] to support
event. co-routed bidirectional LSPs. The FRR procedures can ensure that for
the co-routed LSPs, traffic flows on co-routed paths in the forward
and reverse directions after a failure event.
1.1. Assumptions and Considerations 1.1. Assumptions and Considerations
The following assumptions and considerations apply to this document: The following assumptions and considerations apply to this document:
o The FRR procedure for the unidirectional LSPs is defined in o The FRR procedure for the unidirectional LSPs is defined in
[RFC4090] and is not modified by this document. [RFC4090] and is not modified by this document.
o The FRR procedure when using the unidirectional bypass tunnels is o The FRR procedure when using the unidirectional bypass tunnels is
defined in [RFC4090] and is not modified by this document. defined in [RFC4090] and is not modified by this document.
skipping to change at page 11, line 12 skipping to change at page 11, line 7
Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code Error-code "FRR Bypass Assignment Error" (value: 44) and Sub-code
"One-to-One Bypass Already in Use" (value: 2) to the downstream PLR. "One-to-One Bypass Already in Use" (value: 2) to the downstream PLR.
4.2. Bidirectional LSP Association At Mid-points 4.2. Bidirectional LSP Association At Mid-points
In order to associate the LSPs unambiguously at a mid-point node (see In order to associate the LSPs unambiguously at a mid-point node (see
Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object Figure 3), the endpoint node MUST signal Extended ASSOCIATION Object
and add unique Extended Association ID for each associated forward and add unique Extended Association ID for each associated forward
and reverse LSP pair forming the bidirectional LSP. As an example, and reverse LSP pair forming the bidirectional LSP. As an example,
an endpoint node MAY set the Extended Association ID to the value an endpoint node MAY set the Extended Association ID to the value
specified in Section 5.1. shown in Appendix A.
o For single-sided provisioned bidirectional LSPs [RFC7551], the o For single-sided provisioned bidirectional LSPs [RFC7551], the
originating endpoint signals the Extended ASSOCIATION Object with originating endpoint signals the Extended ASSOCIATION Object with
a unique Extended Association ID. The remote endpoint copies the a unique Extended Association ID. The remote endpoint copies the
contents of the received Extended ASSOCIATION Object including the contents of the received Extended ASSOCIATION Object including the
Extended Association ID in the RSVP Path message of the reverse Extended Association ID in the RSVP Path message of the reverse
LSP's Extended ASSOCIATION Object. LSP's Extended ASSOCIATION Object.
o For double-sided provisioned bidirectional LSPs [RFC7551], both o For double-sided provisioned bidirectional LSPs [RFC7551], both
endpoints need to ensure that the bidirectional LSP has a unique endpoints need to ensure that the bidirectional LSP has a unique
Extended ASSOCIATION Object for each forward and reverse LSP pair Extended ASSOCIATION Object for each forward and reverse LSP pair
by selecting appropriate unique Extended Association IDs signaled by selecting appropriate unique Extended Association IDs signaled
by them. by them.
5. Message and Object Definitions 5. Compatibility
5.1. Extended ASSOCIATION ID This document updates the procedures for fast reroute for associated
bidirectional LSPs defined in [RFC4090] and for associating
bidirectional LSPs defined in [RFC7551]. Operators wishing to use
this function SHOULD ensure that it is supported on all the nodes on
the LSP path. No new signaling messages are defined in this
document.
The Extended Association ID in the Extended ASSOCIATION Object 6. Security Considerations
[RFC6780] can be set to the value specified as following to uniquely
This document updates the signaling mechanisms defined in [RFC4090]
and [RFC7551]; and does not introduce any additional security
considerations other than those already covered in [RFC4090],
[RFC7551], [RFC8271], and the MPLS/GMPLS security framework
[RFC5920].
7. IANA Considerations
This document does not require any IANA actions.
Appendix A. Example of Extended ASSOCIATION ID
Extended Association ID in the Extended ASSOCIATION Object [RFC6780]
can be set to the value shown in the following example to uniquely
identify associated forward and reverse LSP pair of an associated identify associated forward and reverse LSP pair of an associated
bidirectional LSP. bidirectional LSP.
IPv4 Extended Association ID format is shown below: Example of IPv4 Extended Association ID format is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 LSP Source Address | | IPv4 LSP Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID | | Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Variable Length ID : : Variable Length ID :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Extended Association ID Format Figure 4: IPv4 Extended Association ID Format Example
LSP Source Address LSP Source Address
IPv4 source address of the forward LSP [RFC3209]. IPv4 source address of the forward LSP [RFC3209].
LSP-ID LSP-ID
16-bits LSP-ID of the forward LSP [RFC3209]. 16-bits LSP-ID of the forward LSP [RFC3209].
Variable Length ID Variable Length ID
Variable length ID inserted by the endpoint node of the associated Variable length ID inserted by the endpoint node of the associated
bidirectional LSP [RFC6780]. bidirectional LSP [RFC6780].
IPv6 Extended Association ID format is shown below: Example of IPv6 Extended Association ID format is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| IPv6 LSP Source Address | | IPv6 LSP Source Address |
+ + + +
| (16 bytes) | | (16 bytes) |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP-ID | | Reserved | LSP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Variable Length ID : : Variable Length ID :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 Extended Association ID Format Figure 5: IPv6 Extended Association ID Format Example
LSP Source Address LSP Source Address
IPv6 source address of the forward LSP [RFC3209]. IPv6 source address of the forward LSP [RFC3209].
LSP-ID LSP-ID
16-bits LSP-ID of the forward LSP [RFC3209]. 16-bits LSP-ID of the forward LSP [RFC3209].
Variable Length ID Variable Length ID
Variable length ID inserted by the endpoint node of the associated Variable length ID inserted by the endpoint node of the associated
bidirectional LSP [RFC6780]. bidirectional LSP [RFC6780].
6. Compatibility 8. References
This document describes the procedures for fast reroute for
associated bidirectional LSPs. Operators wishing to use this
function SHOULD ensure that it is supported on the nodes on the LSP
path. No new signaling messages are defines in this document.
7. Security Considerations
This document uses the signaling mechanisms defined in [RFC7551] and
[RFC8271] and does not introduce any additional security
considerations other than those already covered in [RFC7551],
[RFC8271], and the MPLS/GMPLS security framework [RFC5920].
8. IANA Considerations
This document does not require any IANA actions.
9. References
9.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.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
skipping to change at page 14, line 37 skipping to change at page 14, line 37
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional Label Switched Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
<https://www.rfc-editor.org/info/rfc7551>. <https://www.rfc-editor.org/info/rfc7551>.
[RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and [RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
M. Bhatia, "Updates to Resource Reservation Protocol for M. Bhatia, "Updates to Resource Reservation Protocol for
Fast Reroute of Traffic Engineering GMPLS Label Switched Fast Reroute of Traffic Engineering GMPLS Label Switched
Paths (LSPs)", RFC 8271, October 2017. Paths (LSPs)", RFC 8271, October 2017.
9.2. Informative References 8.2. Informative References
[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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
skipping to change at page 15, line 14 skipping to change at page 16, line 5
[RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E. [RFC6373] Andersson, L., Berger, L., Fang, L., Bitar, N., and E.
Gray, "MPLS Transport Profile (MPLS-TP) Control Plane Gray, "MPLS Transport Profile (MPLS-TP) Control Plane
Framework", RFC 6373, September 2011. Framework", RFC 6373, September 2011.
[RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and [RFC8131] Zhang, X., Zheng, H., Ed., Gandhi, R., Ed., Ali, Z., and
P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End P. Brzozowski, "RSVP-TE Signaling Procedure for End-to-End
GMPLS Restoration and Resource Sharing", RFC 8131, March GMPLS Restoration and Resource Sharing", RFC 8131, March
2017. 2017.
[PCE-ASSOC-BIDIR] Barth, C., Gandhi, R., Ed., and B. Wen, "PCEP
Extensions for Associated Bidirectional Label Switched
Paths (LSPs)", draft-ietf-pce-association-bidir (work in
progress).
Acknowledgments Acknowledgments
A special thanks to the authors of [RFC8271], this document uses the A special thanks to the authors of [RFC8271], this document uses the
signaling mechanisms defined in that document. signaling mechanisms defined in that document.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
 End of changes. 21 change blocks. 
70 lines changed or deleted 61 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/