draft-ietf-teas-assoc-corouted-bidir-frr-04.txt   draft-ietf-teas-assoc-corouted-bidir-frr-05.txt 
TEAS Working Group R. Gandhi, Ed. TEAS Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Updates: 4090, 7551 H. Shah Updates: 4090, 7551 H. Shah
Intended Status: Standards Track Ciena Intended Status: Standards Track Ciena
Expires: January 16, 2019 J. Whittaker Expires: February 9, 2019 J. Whittaker
Verizon Verizon
July 15, 2018 August 8, 2018
Updates to the 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-04 draft-ietf-teas-assoc-corouted-bidir-frr-05
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 updates LSP follows the same path as its forward LSP. This document updates
the Fast Reroute (FRR) procedures defined in RFC 4090 to support both the Fast Reroute (FRR) procedures defined in RFC 4090 to support both
single-sided and double-sided provisioned associated bidirectional single-sided and double-sided provisioned associated bidirectional
LSPs. This document also updates the procedure for associating two LSPs. This document also updates the procedure for associating two
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . 4 2.2.2. Reverse Co-routed Unidirectional LSPs . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 10 4.2. Bidirectional LSP Association At Mid-points . . . . . . . 10
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Example of Extended ASSOCIATION ID . . . . . . . . . 11 Appendix A. Extended ASSOCIATION ID . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.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 Multiprotocol Label Switching (MPLS) and Generalized MPLS
(TE) Label Switched Paths (LSPs). [RFC7551] defines mechanisms for (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs).
binding two point-to-point unidirectional LSPs [RFC3209] into an [RFC7551] defines mechanisms for binding two point-to-point
associated bidirectional LSP. There are two models described in unidirectional LSPs [RFC3209] into an associated bidirectional LSP.
[RFC7551] for provisioning an associated bidirectional LSP, single- There are two models described in [RFC7551] for provisioning an
sided and double-sided. In both models, the reverse LSP of the associated bidirectional LSP, single-sided and double-sided. In both
bidirectional LSP may or may not be co-routed and follow the same models, the reverse LSP of the bidirectional LSP may or may not be
path as its forward LSP. co-routed and follow the same path as its forward LSP.
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.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
Two reverse unidirectional point-to-point (P2P) LSPs are setup in the Two reverse unidirectional point-to-point (P2P) LSPs are setup in the
opposite directions between a pair of source and destination nodes to opposite directions between a pair of source and destination nodes to
form an associated bidirectional LSP. A reverse unidirectional LSP form an associated bidirectional LSP. A reverse unidirectional LSP
originates on the same node where the forward unidirectional LSP originates on the same node where the forward unidirectional LSP
terminates, and it terminates on the same node where the forward terminates, and it terminates on the same node where the forward
unidirectional LSP originates. A reverse co-routed unidirectional unidirectional LSP originates. A reverse co-routed unidirectional
LSP traverses along the same path as the forward direction LSP traverses along the same path as the forward direction
unidirectional LSP in the opposite direction. unidirectional LSP in the opposite direction.
3. Overview 3. Problem Statement
As specified in [RFC7551], in the single-sided provisioning case, the As specified in [RFC7551], in the single-sided provisioning case, the
RSVP TE tunnel is configured only on one endpoint node of the RSVP TE tunnel is configured only on one endpoint node of the
bidirectional LSP. An LSP for this tunnel is initiated by the bidirectional LSP. An LSP for this tunnel is initiated by the
originating endpoint with (Extended) ASSOCIATION Object containing originating endpoint with (Extended) ASSOCIATION Object containing
Association Type set to "single-sided associated bidirectional LSP" Association Type set to "single-sided associated bidirectional LSP"
and REVERSE_LSP Object inserted in the RSVP Path message. The remote and REVERSE_LSP Object inserted in the RSVP Path message. The remote
endpoint then creates the corresponding reverse TE tunnel and signals endpoint then creates the corresponding reverse TE tunnel and signals
the reverse LSP in response using the information from the the reverse LSP in response using the information from the
REVERSE_LSP Object and other objects present in the received RSVP REVERSE_LSP Object and other objects present in the received RSVP
skipping to change at page 6, line 23 skipping to change at page 6, line 23
| F +---------+ G | | F +---------+ G |
+-----+ +-----+ +-----+ +-----+
<-- Bypass S --> <-- Bypass S -->
Figure 1: Multiple Bidirectional Bypass Tunnels Figure 1: Multiple Bidirectional Bypass Tunnels
As shown in Figure 1, there are two bypass tunnels available, Bypass As shown in Figure 1, there are two bypass tunnels available, Bypass
tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C). tunnel N (on path B-H-I-C) and Bypass tunnel S (on path B-F-G-C).
The mid-point PLR nodes B and C need to coordinate bypass tunnel The mid-point PLR nodes B and C need to coordinate bypass tunnel
assignment to ensure that traffic in both directions flow through assignment to ensure that traffic in both directions flow through
either on the Bypass tunnel N (on path B-H-I-C) or the Bypass tunnel either on the Bypass tunnel N or the Bypass tunnel S, after the link
S (on path B-F-G-C), after the link B-C failure. B-C failure.
3.2. Node Protection Bypass Tunnels 3.2. Node Protection Bypass Tunnels
When using a node protection bypass tunnel with a protected When using a node protection bypass tunnel with a protected
associated bidirectional LSP, after a link failure, the forward and associated bidirectional LSP, after a link failure, the forward and
reverse LSP traffic can flow on different node protection bypass reverse LSP traffic can flow on different node protection bypass
tunnels in the upstream and downstream directions. tunnels in the upstream and downstream directions.
<-- Bypass N --> <-- Bypass N -->
+-----+ +-----+ +-----+ +-----+
skipping to change at page 8, line 36 skipping to change at page 8, line 36
node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of node in the RECORD_ROUTE Object (RRO) of the RSVP Path message of
the forward LSP to indicate the local bypass tunnel assignment the forward LSP to indicate the local bypass tunnel assignment
using the procedure defined in [RFC8271]. The upstream node uses using the procedure defined in [RFC8271]. The upstream node uses
the bypass assignment information (namely, bypass tunnel source the bypass assignment information (namely, bypass tunnel source
address, destination address and Tunnel ID) in the received RSVP address, destination address and Tunnel ID) in the received RSVP
Path message of the protected forward LSP to find the associated Path message of the protected forward LSP to find the associated
bypass tunnel in the reverse direction. The upstream PLR node bypass tunnel in the reverse direction. The upstream PLR node
MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the MUST NOT add the BYPASS_ASSIGNMENT subobject in the RRO of the
RSVP Path message of the reverse LSP. RSVP Path message of the reverse LSP.
o The downstream PLR node always initiates the bypass tunnel o The downstream PLR node initiates the bypass tunnel assignment for
assignment for the forward LSP. The upstream PLR (forward the forward LSP. The upstream PLR (forward direction LSP MP) node
direction LSP MP) node simply reflects the associated bypass reflects the associated bypass tunnel assignment for the reverse
tunnel assignment for the reverse direction LSP. The upstream PLR direction LSP. The upstream PLR node MUST NOT initiate the bypass
node MUST NOT initiate the bypass tunnel assignment. tunnel assignment.
o If the indicated forward bypass tunnel or the associated reverse o If the indicated forward bypass tunnel or the associated reverse
bypass tunnel is not found, the upstream PLR SHOULD send a Notify bypass tunnel is not found, the upstream PLR SHOULD send a Notify
message [RFC3473] with Error-code "FRR Bypass Assignment Error" message [RFC3473] with Error-code "FRR Bypass Assignment Error"
(value: 44) and Sub-code "Bypass Tunnel Not Found" (value: 1) (value: 44) and Sub-code "Bypass Tunnel Not Found" (value: 1)
[RFC8271] to the downstream PLR. [RFC8271] to the downstream PLR.
o If the bypass tunnel can not be used as described in Section 4.5.3 o If the bypass tunnel can not be used as described in Section 4.5.3
in [RFC8271], the upstream PLR SHOULD send a Notify message in [RFC8271], the upstream PLR SHOULD send a Notify message
[RFC3473] with Error-code "FRR Bypass Assignment Error" (value: [RFC3473] with Error-code "FRR Bypass Assignment Error" (value:
skipping to change at page 9, line 30 skipping to change at page 9, line 30
traffic over the bypass tunnel on which the forward LSP RSVP Path traffic over the bypass tunnel on which the forward LSP RSVP Path
messages and traffic are received. This procedure is defined as messages and traffic are received. This procedure is defined as
restoring co-routing in [RFC8271]. This procedure is used to ensure restoring co-routing in [RFC8271]. This procedure is used to ensure
that both forward and reverse LSP signaling and traffic flow on the that both forward and reverse LSP signaling and traffic flow on the
same bidirectional bypass tunnel after fast reroute. same bidirectional bypass tunnel after fast reroute.
As shown in Figure 2, when using a node protection bypass tunnel with As shown in Figure 2, when using a node protection bypass tunnel with
protected co-routed LSPs, asymmetry of paths can occur in the forward protected co-routed LSPs, asymmetry of paths can occur in the forward
and reverse directions after a link failure [RFC8271]. In order to and reverse directions after a link failure [RFC8271]. In order to
restore co-routing, the downstream MP node D (acting as an upstream restore co-routing, the downstream MP node D (acting as an upstream
PLR) SHOULD trigger procedure to restore co-routing and reroute the PLR) SHOULD trigger the procedure to restore co-routing and reroute
protected reverse LSP2 RSVP Path messages and traffic over the bypass the protected reverse LSP2 RSVP Path messages and traffic over the
tunnel S (on path D-G-F-B) to the upstream MP node B upon receiving bypass tunnel S (on path D-G-F-B) to the upstream MP node B upon
the protected forward LSP modified RSVP Path messages and traffic receiving the protected forward LSP modified RSVP Path messages and
over the bypass tunnel S (on path D-G-F-B) from node B. The upstream traffic over the bypass tunnel S (on path D-G-F-B) from node B. The
PLR node C stops receiving the RSVP Path messages and traffic for the upstream PLR node C stops receiving the RSVP Path messages and
reverse LSP2 from node D (resulting in RSVP soft-state timeout) and traffic for the reverse LSP2 from node D (resulting in RSVP
it stops sending the RSVP Path messages for the reverse LSP2 over the soft-state timeout) and it stops sending the RSVP Path messages for
bypass tunnel N (on path C-I-H-A) to node A. the reverse LSP2 over the bypass tunnel N (on path C-I-H-A) to node
A.
4.1.2. Unidirectional Link Failures 4.1.2. Unidirectional Link Failures
The unidirectional link failures can cause co-routed associated The unidirectional link failures can cause co-routed associated
bidirectional LSPs to become non-corouted after fast reroute with bidirectional LSPs to become non-corouted after fast reroute with
both link protection and node protection bypass tunnels. However, both link protection and node protection bypass tunnels. However,
the unidirectional link failures in the upstream and/or downstream the unidirectional link failures in the upstream and/or downstream
directions do not result in RSVP soft-state timeout with the directions do not result in RSVP soft-state timeout with the
associated bidirectional LSPs as upstream and downstream PLRs trigger associated bidirectional LSPs as upstream and downstream PLRs trigger
fast reroute independently. The asymmetry of forward and reverse LSP fast reroute independently. The asymmetry of forward and reverse LSP
skipping to change at page 11, line 5 skipping to change at page 11, line 5
if the associated bidirectional bypass tunnel is already in-use at if the associated bidirectional bypass tunnel is already in-use at
the upstream PLR, it SHOULD send a Notify message [RFC3473] with the upstream PLR, it SHOULD send a Notify message [RFC3473] with
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. An endpoint node
an endpoint node MAY set the Extended Association ID to the value MAY set the Extended Association ID to the value shown in Appendix A.
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
skipping to change at page 11, line 43 skipping to change at page 11, line 42
This document updates the signaling mechanisms defined in [RFC4090] This document updates the signaling mechanisms defined in [RFC4090]
and [RFC7551]; and does not introduce any additional security and [RFC7551]; and does not introduce any additional security
considerations other than those already covered in [RFC4090], considerations other than those already covered in [RFC4090],
[RFC7551], [RFC8271], and the MPLS/GMPLS security framework [RFC7551], [RFC8271], and the MPLS/GMPLS security framework
[RFC5920]. [RFC5920].
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
Appendix A. Example of Extended ASSOCIATION ID Appendix A. Extended ASSOCIATION ID
Extended Association ID in the Extended ASSOCIATION Object [RFC6780] Extended Association ID in the Extended ASSOCIATION Object [RFC6780]
can be set to the value shown in the following example to uniquely 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.
Example of IPv4 Extended Association ID format is shown below: An 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 :
skipping to change at page 12, line 35 skipping to change at page 12, line 34
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].
Example of IPv6 Extended Association ID format is shown below: An 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) |
+ + + +
skipping to change at page 16, line 8 skipping to change at page 16, line 8
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.
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. The authors would
also like to thank Vishnu Pavan Beeram and Daniele Ceccarelli for
reviewing this document and providing valuable comments.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Himanshu Shah Himanshu Shah
 End of changes. 15 change blocks. 
37 lines changed or deleted 39 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/