draft-ietf-teas-rsvp-ingress-protection-12.txt | draft-ietf-teas-rsvp-ingress-protection-13.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: June 19, 2018 Juniper Networks | Expires: August 17, 2018 Juniper Networks | |||
December 16, 2017 | February 13, 2018 | |||
Extensions to RSVP-TE for LSP Ingress FRR Protection | Extensions to RSVP-TE for LSP Ingress FRR Protection | |||
draft-ietf-teas-rsvp-ingress-protection-12.txt | draft-ietf-teas-rsvp-ingress-protection-13.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 Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic | of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic | |||
Engineered (TE) Label Switched Path (LSP). | Engineered (TE) Label Switched Path (LSP). The procedures described | |||
in this document are experimental. | ||||
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 June 19, 2018. | This Internet-Draft will expire on August 17, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
skipping to change at page 2, line 14 ¶ | skipping to change at page 2, line 15 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Ingress Local Protection . . . . . . . . . . . . . . . . . 4 | 1.1. Ingress Local Protection . . . . . . . . . . . . . . . . . 4 | |||
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 . . . . . . . . . . . . . 5 | 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 . . . . . . . . . . . . . . . . . . . . . 6 | 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6 | 4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 7 | |||
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 . . . . . . . . . . . 9 | 4.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 10 | |||
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 . . . . . . . . . . . . . . . . . 11 | 5.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 12 | |||
5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 | 5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 | |||
5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13 | 5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 14 | 5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 14 | |||
5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14 | 5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 15 | |||
5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 16 | 5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 16 | |||
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 . . . . . . . . . . . . . . . . . . . . 20 | |||
5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 20 | 5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 20 | |||
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 . . . . . . . . . . . . . . . . . . . 21 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | |||
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 | 9. Co-authors and Contributors . . . . . . . . . . . . . . . . . 22 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
1. Introduction | 1. Introduction | |||
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 | |||
skipping to change at page 4, line 11 ¶ | 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. The procedures described in this document | will be used exchangeably. | |||
are experimental. | ||||
Note that this document is experimental. Two different approaches | ||||
are proposed to transfer the information for ingress protection. | ||||
They both use the same new INGRESS_PROTECTION object, which is sent | ||||
in both PATH and RESV messages between a primary ingress and a backup | ||||
ingress. One approach is Relay-Message Method (refer to section | ||||
5.1.1 and 5.2.1), the other is Proxy-Ingress Method (refer to section | ||||
5.1.2 and 5.2.2). Each of them has its advantages and disadvantages. | ||||
It is hard to decide which one is used as a standard approach now. | ||||
After one approach is selected, the document SHOULD become proposed | ||||
standard. | ||||
1.1. 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 Ia | 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 Ib to the next hops R2 and R4 of ingress Ia. | ingress Ib to the next hops R2 and R4 of ingress Ia. | |||
******* ******* S Source | ******* ******* S Source | |||
[R2]-----[R3]-----[L1] Ix Ingress | [R2]-----[R3]-----[L1] Ix Ingress | |||
skipping to change at page 21, line 5 ¶ | skipping to change at page 21, line 11 ¶ | |||
no bandwidth reservation that duplicates the path(s) of the protected | no bandwidth reservation that duplicates the path(s) of the protected | |||
LSP, move traffic to the new LSP, delete the protected LSP, and then | LSP, move traffic to the new LSP, delete the protected LSP, and then | |||
resignal the new LSP with bandwidth. | resignal the new LSP with bandwidth. | |||
6. Security Considerations | 6. Security Considerations | |||
In principle this document does not introduce new security issues. | In principle this document does not introduce new security issues. | |||
The security considerations pertaining to RFC 4090, RFC 4875 and | The security considerations pertaining to RFC 4090, RFC 4875 and | |||
other RSVP protocols remain relevant. | other RSVP protocols remain relevant. | |||
7. IANA Considerations | 7. Compatibility | |||
This extension reuses and extends semantics and procedures defined in | ||||
RFC 2205, RFC 3209, RFC 4090 and RFC 4875 to support ingress | ||||
protection. One new object is defined to indicate ingress protection | ||||
with class numbers in the form 0bbbbbbb. Per RFC 2205, a node not | ||||
supporting this extension will not recognize the new class number and | ||||
should respond with an "Unknown Object Class" error. The error | ||||
message will propagate to the ingress, which can then take action to | ||||
avoid the incompatible node as a backup ingress or may simply | ||||
terminate the session. | ||||
8. 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". Upon approval of this document, IANA is | |||
Number for new object INGRESS_PROTECTION as follows: | requested to assign a new Class Number of form 0bbbbbbb for new | |||
object INGRESS_PROTECTION located at <http://www.iana.org/ | ||||
assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml>, as follows: | ||||
+====================+===============+============================+ | +====================+===============+============================+ | |||
| Class Names | Class Numbers | Class Types | | | Class Names | Class Numbers | Class Types | | |||
+====================+===============+============================+ | +====================+===============+============================+ | |||
| INGRESS_PROTECTION | TBD | 1: INGRESS_PROTECTION_IPv4 | | | INGRESS_PROTECTION | TBD | 1: INGRESS_PROTECTION_IPv4 | | |||
| | +----------------------------+ | | |(124 suggested)+----------------------------+ | |||
| | | 2: INGRESS_PROTECTION_IPv6 | | | | | 2: INGRESS_PROTECTION_IPv6 | | |||
+--------------------+---------------+----------------------------+ | +--------------------+---------------+----------------------------+ | |||
IANA is to create and maintain a new registry under | When this document moves to standards track, IANA is requested to | |||
INGRESS_PROTECTION: | create and maintain a new registry under INGRESS_PROTECTION located | |||
at <http://www.iana.org/assignments/rsvp-te-parameters/ | ||||
rsvp-te-parameters.xhtml>. | ||||
o Sub-object type - TBD 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 | 9. Co-authors and Contributors | |||
1. Co-authors | 1. Co-authors | |||
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 | |||
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 | |||
skipping to change at page 23, line 35 ¶ | skipping to change at page 24, line 18 ¶ | |||
Canada | Canada | |||
Email: Boris.Zhang@telus.com | Email: Boris.Zhang@telus.com | |||
Markus Jork | Markus Jork | |||
Juniper Networks | Juniper Networks | |||
10 Technology Park Drive | 10 Technology Park Drive | |||
Westford, MA 01886 | Westford, MA 01886 | |||
USA | USA | |||
Email: mjork@juniper.net | Email: mjork@juniper.net | |||
9. Acknowledgement | 10. 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 | 11. References | |||
10.1. Normative References | 11.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, | |||
<https://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, | |||
<https://www.rfc-editor.org/info/rfc3031>. | <https://www.rfc-editor.org/info/rfc3031>. | |||
skipping to change at page 24, line 36 ¶ | skipping to change at page 25, line 14 ¶ | |||
DOI 10.17487/RFC4090, May 2005, | DOI 10.17487/RFC4090, May 2005, | |||
<https://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, | |||
<https://www.rfc-editor.org/info/rfc4875>. | <https://www.rfc-editor.org/info/rfc4875>. | |||
10.2. Informative References | 11.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, | |||
<https://www.rfc-editor.org/info/rfc6378>. | <https://www.rfc-editor.org/info/rfc6378>. | |||
Authors' Addresses | Authors' Addresses | |||
Huaimo Chen (editor) | Huaimo Chen (editor) | |||
End of changes. 23 change blocks. | ||||
40 lines changed or deleted | 69 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |