draft-ietf-teas-rsvp-ingress-protection-10.txt   draft-ietf-teas-rsvp-ingress-protection-11.txt 
Internet Engineering Task Force H. Chen, Ed. Internet Engineering Task Force H. Chen, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Experimental R. Torvi, Ed. Intended status: Experimental R. Torvi, Ed.
Expires: February 4, 2018 Juniper Networks Expires: April 18, 2018 Juniper Networks
August 3, 2017 October 15, 2017
Extensions to RSVP-TE for LSP Ingress FRR Protection Extensions to RSVP-TE for LSP Ingress FRR Protection
draft-ietf-teas-rsvp-ingress-protection-10.txt draft-ietf-teas-rsvp-ingress-protection-11.txt
Abstract Abstract
This document describes extensions to Resource Reservation Protocol - This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting the ingress node Traffic Engineering (RSVP-TE) for locally protecting the ingress node
of a Traffic Engineered (TE) Label Switched Path (LSP), which is a of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic
Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. Engineered (TE) Label Switched Path (LSP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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/.
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 4, 2018. This Internet-Draft will expire on April 18, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. An Example of Ingress Local Protection . . . . . . . . . . 4 1.1. Ingress Local Protection . . . . . . . . . . . . . . . . . 4
1.2. Ingress Local Protection with FRR . . . . . . . . . . . . 5
2. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 5 2. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 5
2.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 5 2.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 5
2.2. Backup and Source Detect Failure . . . . . . . . . . . . . 6 2.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5
3. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 6 3. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 6
3.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 6 3.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 6
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6
4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 7 4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6
4.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 8 4.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 8
4.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 9 4.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 9
4.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 9 4.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 9
4.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 10 4.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 9
4.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 10 4.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 10
4.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 11 4.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 11
5. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 11 5. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 11
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12 5.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 11
5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12
5.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 13
5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13 5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 14 5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13
5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 15 5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14
5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 16 5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 15
5.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 16 5.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 16
5.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 18 5.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 18
5.3.3. Failure Detection and Refresh PATH Messages . . . . . 19 5.3.3. Failure Detection and Refresh PATH Messages . . . . . 19
5.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 19 5.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 19
5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 20 5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 19
5.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 20 5.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
There is a need for a fast and efficient protection against the
failure of the ingress node of a MPLS TE LSP (either P2MP LSP or P2P
LSP).
For a MPLS TE LSP, protecting the failures of its transit nodes using For a MPLS TE LSP, protecting the failures of its transit nodes using
fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875 fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875
for P2MP LSP. However, protecting the failure of its ingress node for P2MP LSP. However, protecting the failure of its ingress node
using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS
Transport Profile (MPLS-TP) Linear Protection described in RFC 6378 Transport Profile (MPLS-TP) Linear Protection described in RFC 6378
can provide a protection against the failure of any transit node of a can provide a protection against the failure of any transit node of a
LSP between the ingress node and the egress node of the LSP, but LSP between the ingress node and the egress node of the LSP, but
cannot protect against the failure of the ingress node. cannot protect against the failure of the ingress node.
To protect against the failure of the (primary) ingress node of a To protect against the failure of the (primary) ingress node of a
skipping to change at page 4, line 16 skipping to change at page 4, line 11
reliable. Any failure on the path of the BFD from an egress node reliable. Any failure on the path of the BFD from an egress node
to an ingress node may cause the BFD down to indicate the failure to an ingress node may cause the BFD down to indicate the failure
of the ingress node. of the ingress node.
o The speed of protection against the failure of the ingress node o The speed of protection against the failure of the ingress node
may be slow. may be slow.
This specification defines a simple extension to RSVP-TE for local This specification defines a simple extension to RSVP-TE for local
protection (FRR) of the ingress node of a P2MP or P2P LSP to resolve protection (FRR) of the ingress node of a P2MP or P2P LSP to resolve
these issues. Ingress local protection and ingress FRR protection these issues. Ingress local protection and ingress FRR protection
will be used exchangeably. will be used exchangeably. The procedures described in this document
are experimental.
1.1. An Example of Ingress Local Protection 1.1. Ingress Local Protection
Figure 1 shows an example of using a backup P2MP LSP to locally Figure 1 shows an example of using a backup P2MP LSP to locally
protect the ingress of a primary P2MP LSP, which is from ingress R1 protect the ingress of a primary P2MP LSP, which is from ingress Ia
to three egresses: L1, L2 and L3. The backup LSP is from backup to three egresses: L1, L2 and L3. The backup LSP is from backup
ingress Ra to the next hops R2 and R4 of ingress R1. ingress Ib to the next hops R2 and R4 of ingress Ia.
[R2]******[R3]*****[L1] ******* ******* S Source
* | **** Primary LSP [R2]-----[R3]-----[L1] Ix Ingress
* | ---- Backup LSP */ & Rx Transit
* / .... BFD Session */ & Lx Egress
* / $ Link */ & *** Primary LSP
....[R1]*******[R4]****[R5]*****[L2] $ */ & &&& Backup LSP across
: $ $ / / * $ */ & logical hop
: $ $ / / * */ &
[S] $ / / * */ ******** ******** *******
$ $ / / * [S]---[Ia]--------[R4]------[R5]-----[L2]
$ $/ / * \ | & & *\
[Ra]----[Rb] [L3] \ | & & *\
\ | & & *\
\ | & & *\
\ | & & *\
\ |& & *\
[Ib]&&& [L3]
Figure 1: Backup P2MP LSP for Locally Protecting Ingress Figure 1: Ingress Local Protection
In normal operations, source S sends the traffic to primary ingress In normal operations, source S sends the traffic to primary ingress
R1. R1 imports the traffic into the primary LSP. Ia. Ia imports the traffic into the primary LSP.
When source S detects the failure of R1, it switches the traffic to When source S detects the failure of Ia, it switches the traffic to
backup ingress Ra, which imports the traffic from S into the backup backup ingress Ib, which imports the traffic from S into the backup
LSP to R1's next hops R2 and R4, where the traffic is merged into the LSP to Ia's next hops R2 and R4, where the traffic is merged into the
primary LSP, and then sent to egresses L1, L2 and L3. Source S primary LSP, and then sent to egresses L1, L2 and L3. Source S
detects the failure of R1 and switches the traffic within 10s of ms. detects the failure of Ia and switches the traffic within 10s of ms.
Note that the backup ingress is one logical hop away from the Note that the backup ingress is one logical hop away from the
ingress. A logical hop is a direct link or a tunnel such as a GRE ingress. A logical hop is a direct link or a tunnel such as a GRE
tunnel, over which RSVP-TE messages may be exchanged. tunnel, over which RSVP-TE messages may be exchanged.
1.2. Ingress Local Protection with FRR
Through using the ingress local protection and the FRR, we can
locally protect the ingress, all the links and the transit nodes of
an LSP. The traffic switchover time is within 10s of ms whenever the
ingress, any of the links and the transit nodes of the LSP fails.
The ingress node of the LSP can be locally protected through using
the ingress local protection. All the links and all the transit
nodes of the LSP can be locally protected through using the FRR.
2. Ingress Failure Detection 2. Ingress Failure Detection
Exactly how to detect the failure of the ingress is out of scope. Exactly how to detect the failure of the ingress is out of scope.
However, it is necessary to discuss different modes for detecting the However, it is necessary to discuss different modes for detecting the
failure because they determine what is the required behavior for the failure because they determine what is the required behavior for the
source and backup ingress. source and backup ingress.
2.1. Source Detects Failure 2.1. Source Detects Failure
Source Detects Failure or Source-Detect for short means that the Source Detects Failure or Source-Detect for short means that the
skipping to change at page 13, line 20 skipping to change at page 13, line 14
after the ingress for the LSP. In the off-path, the backup ingress after the ingress for the LSP. In the off-path, the backup ingress
is not any next-hop node after the ingress for all associated sub- is not any next-hop node after the ingress for all associated sub-
LSPs. LSPs.
The key advantage of this approach is that it minimizes the special The key advantage of this approach is that it minimizes the special
handling code requires. Because the backup ingress is on the handling code requires. Because the backup ingress is on the
signaling path, it can receive various notifications. It easily has signaling path, it can receive various notifications. It easily has
access to all the PATH messages needed for modification to be sent to access to all the PATH messages needed for modification to be sent to
refresh control-plane state after a failure. refresh control-plane state after a failure.
5.1.3. Comparing Two Methods
+-------+-----------+-------+--------------+---------------+---------+
|\_ Item|Primary LSP|Config |PATH Msg from |RESV Msg from |Reuse |
| \_ |Depends on |Proxy- |Backup Ingress|Primary Ingress|Some |
| \|Backup |Ingress|to Primary |to Backup |Existing |
|Method |Ingress |ID |Ingress |Ingress |Functions|
+-------+-----------+-------+--------------+---------------+---------+
|Relay- | No | No | No | No | Yes- |
|Message| | | | | |
+-------+-----------+-------+--------------+---------------+---------+
|Proxy- | Yes | Yes- | Yes | Yes | Yes |
|Ingress| | | | | |
+-------+-----------+-------+--------------+---------------+---------+
5.2. Ingress Behavior 5.2. Ingress Behavior
The primary ingress MUST be configured with a couple of pieces of The primary ingress MUST be configured with a couple of pieces of
information for ingress protection. information for ingress protection.
o Backup Ingress Address: The primary ingress MUST know an IP o Backup Ingress Address: The primary ingress MUST know an IP
address for it to be included in the INGRESS_PROTECTION object. address for it to be included in the INGRESS_PROTECTION object.
o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The
Proxy-Ingress-Id is only used in the Record Route Object for Proxy-Ingress-Id is only used in the Record Route Object for
skipping to change at page 21, line 15 skipping to change at page 20, line 36
7. IANA Considerations 7. IANA Considerations
IANA maintains a registry called "Class Names, Class Numbers, and IANA maintains a registry called "Class Names, Class Numbers, and
Class Types" under "Resource Reservation Protocol-Traffic Engineering Class Types" under "Resource Reservation Protocol-Traffic Engineering
(RSVP-TE) Parameters". IANA is requested to assign a new Class (RSVP-TE) Parameters". IANA is requested to assign a new Class
Number for new object INGRESS_PROTECTION as follows: Number for new object INGRESS_PROTECTION as follows:
+====================+===============+============================+ +====================+===============+============================+
| Class Names | Class Numbers | Class Types | | Class Names | Class Numbers | Class Types |
+====================+===============+============================+ +====================+===============+============================+
| INGRESS_PROTECTION | 206 | 1: INGRESS_PROTECTION_IPv4 | | INGRESS_PROTECTION | TBD | 1: INGRESS_PROTECTION_IPv4 |
| | is suggested +----------------------------+ | | +----------------------------+
| | | 2: INGRESS_PROTECTION_IPv6 | | | | 2: INGRESS_PROTECTION_IPv6 |
+--------------------+---------------+----------------------------+ +--------------------+---------------+----------------------------+
IANA is to create and maintain a new registry under IANA is to create and maintain a new registry under
INGRESS_PROTECTION: INGRESS_PROTECTION:
o Sub-object type - 206 INGRESS_PROTECTION o Sub-object type - TBD INGRESS_PROTECTION
Initial values for the registry are given below. The future Initial values for the registry are given below. The future
assignments are to be made through IETF Review. assignments are to be made through IETF Review.
Value Name Definition Value Name Definition
1 BACKUP_INGRESS_IPv4_ADDRESS Section 4.1.1 1 BACKUP_INGRESS_IPv4_ADDRESS Section 4.1.1
2 BACKUP_INGRESS_IPv6_ADDRESS Section 4.1.2 2 BACKUP_INGRESS_IPv6_ADDRESS Section 4.1.2
3 INGRESS_IPv4_ADDRESS Section 4.1.3 3 INGRESS_IPv4_ADDRESS Section 4.1.3
4 INGRESS_IPv6_ADDRESS Section 4.1.4 4 INGRESS_IPv6_ADDRESS Section 4.1.4
5 TRAFFIC_DESCRIPTOR_INTERFACE Section 4.1.5 5 TRAFFIC_DESCRIPTOR_INTERFACE Section 4.1.5
6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX Section 4.1.5 6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX Section 4.1.5
7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX Section 4.1.5 7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX Section 4.1.5
8 TRAFFIC_DESCRIPTOR_APPLICATION Section 4.1.5 8 TRAFFIC_DESCRIPTOR_APPLICATION Section 4.1.5
9 LabeL_Routes Section 4.1.6 9 LabeL_Routes Section 4.1.6
8. Co-authors and Contributors 8. Co-authors and Contributors
1. Co-authors 1. Co-authors
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ningso01@gmail.com
Autumn Liu Autumn Liu
Ciena Ciena
USA USA
Email: hliu@ciena.com Email: hliu@ciena.com
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Email: zhenbin.li@huawei.com Email: zhenbin.li@huawei.com
Yimin Shen Yimin Shen
skipping to change at page 22, line 23 skipping to change at page 22, line 4
Yimin Shen Yimin Shen
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: yshen@juniper.net Email: yshen@juniper.net
Tarek Saad Tarek Saad
Cisco Systems Cisco Systems
Email: tsaad@cisco.com Email: tsaad@cisco.com
Fengman Xu Fengman Xu
Verizon Verizon
2400 N. Glenville Dr 2400 N. Glenville Dr
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: fengman.xu@verizon.com Email: fengman.xu@verizon.com
2. Contributors
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ningso01@gmail.com
Mehmet Toy Mehmet Toy
Verizon Verizon
USA USA
Email: mehmet.toy@verizon.com Email: mehmet.toy@verizon.com
Lei Liu Lei Liu
USA USA
Email: liulei.kddi@gmail.com Email: liulei.kddi@gmail.com
2. Contributors
Renwei Li Renwei Li
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: renwei.li@huawei.com Email: renwei.li@huawei.com
Quintin Zhao Quintin Zhao
Huawei Technologies Huawei Technologies
Boston, MA Boston, MA
skipping to change at page 24, line 4 skipping to change at page 23, line 27
9. Acknowledgement 9. Acknowledgement
The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric
Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia
Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath,
Gregory Mirsky, and Ronhazli Adam for their valuable comments and Gregory Mirsky, and Ronhazli Adam for their valuable comments and
suggestions on this draft. suggestions on this draft.
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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/ Label Switching Architecture", RFC 3031, DOI 10.17487/
RFC3031, January 2001, RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[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, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[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,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
10.2. Informative References 10.2. Informative References
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher,
N., and A. Fulignoli, Ed., "MPLS Transport Profile N., and A. Fulignoli, Ed., "MPLS Transport Profile
(MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/ (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/
RFC6378, October 2011, RFC6378, October 2011,
<http://www.rfc-editor.org/info/rfc6378>. <https://www.rfc-editor.org/info/rfc6378>.
Authors' Addresses Authors' Addresses
Huaimo Chen (editor) Huaimo Chen (editor)
Huawei Technologies Huawei Technologies
Boston, MA Boston, MA
USA USA
Email: huaimo.chen@huawei.com Email: huaimo.chen@huawei.com
Raveendra Torvi (editor) Raveendra Torvi (editor)
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: rtorvi@juniper.net Email: rtorvi@juniper.net
 End of changes. 40 change blocks. 
91 lines changed or deleted 67 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/