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/