--- 1/draft-ietf-teas-rsvp-ingress-protection-10.txt 2017-10-15 22:13:09.796290504 -0700 +++ 2/draft-ietf-teas-rsvp-ingress-protection-11.txt 2017-10-15 22:13:09.848291979 -0700 @@ -1,107 +1,101 @@ Internet Engineering Task Force H. Chen, Ed. Internet-Draft Huawei Technologies Intended status: Experimental R. Torvi, Ed. -Expires: February 4, 2018 Juniper Networks - August 3, 2017 +Expires: April 18, 2018 Juniper Networks + October 15, 2017 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 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node - of a Traffic Engineered (TE) Label Switched Path (LSP), which is a - Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. + of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic + Engineered (TE) Label Switched Path (LSP). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. An Example of Ingress Local Protection . . . . . . . . . . 4 - 1.2. Ingress Local Protection with FRR . . . . . . . . . . . . 5 + 1.1. Ingress Local Protection . . . . . . . . . . . . . . . . . 4 2. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 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.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 6 - 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 7 + 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6 4.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 8 4.1.2. Subobject: Backup Ingress IPv6 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.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 11 5. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 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.3. Comparing Two Methods . . . . . . . . . . . . . . . . 13 5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13 - 5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 14 - 5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 15 - 5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 16 + 5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13 + 5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14 + 5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 15 5.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 16 5.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 18 5.3.3. Failure Detection and Refresh PATH Messages . . . . . 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 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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 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 using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS Transport Profile (MPLS-TP) Linear Protection described in RFC 6378 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 cannot protect against the failure of the ingress node. To protect against the failure of the (primary) ingress node of a @@ -138,68 +132,63 @@ 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 of the ingress node. o The speed of protection against the failure of the ingress node may be slow. 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 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 - 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 - 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] - * | **** Primary LSP - * | ---- Backup LSP - * / .... BFD Session - * / $ Link - ....[R1]*******[R4]****[R5]*****[L2] $ - : $ $ / / * $ - : $ $ / / * - [S] $ / / * - $ $ / / * - $ $/ / * - [Ra]----[Rb] [L3] + ******* ******* S Source + [R2]-----[R3]-----[L1] Ix Ingress + */ & Rx Transit + */ & Lx Egress + */ & *** Primary LSP + */ & &&& Backup LSP across + */ & logical hop + */ & + */ ******** ******** ******* + [S]---[Ia]--------[R4]------[R5]-----[L2] + \ | & & *\ + \ | & & *\ + \ | & & *\ + \ | & & *\ + \ | & & *\ + \ |& & *\ + [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 - 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 - backup ingress Ra, 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 + When source S detects the failure of Ia, it switches the traffic to + backup ingress Ib, which imports the traffic from S into the backup + 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 - 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 ingress. A logical hop is a direct link or a tunnel such as a GRE 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 Exactly how to detect the failure of the ingress is out of scope. However, it is necessary to discuss different modes for detecting the failure because they determine what is the required behavior for the source and backup ingress. 2.1. Source Detects Failure Source Detects Failure or Source-Detect for short means that the @@ -551,35 +540,20 @@ 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- LSPs. The key advantage of this approach is that it minimizes the special handling code requires. Because the backup ingress is on the signaling path, it can receive various notifications. It easily has access to all the PATH messages needed for modification to be sent to 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 The primary ingress MUST be configured with a couple of pieces of information for ingress protection. o Backup Ingress Address: The primary ingress MUST know an IP address for it to be included in the INGRESS_PROTECTION object. o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The Proxy-Ingress-Id is only used in the Record Route Object for @@ -926,54 +900,48 @@ 7. IANA Considerations IANA maintains a registry called "Class Names, Class Numbers, and Class Types" under "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters". IANA is requested to assign a new Class Number for new object INGRESS_PROTECTION as follows: +====================+===============+============================+ | Class Names | Class Numbers | Class Types | +====================+===============+============================+ - | INGRESS_PROTECTION | 206 | 1: INGRESS_PROTECTION_IPv4 | - | | is suggested +----------------------------+ + | INGRESS_PROTECTION | TBD | 1: INGRESS_PROTECTION_IPv4 | + | | +----------------------------+ | | | 2: INGRESS_PROTECTION_IPv6 | +--------------------+---------------+----------------------------+ IANA is to create and maintain a new registry under 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 assignments are to be made through IETF Review. Value Name Definition 1 BACKUP_INGRESS_IPv4_ADDRESS Section 4.1.1 2 BACKUP_INGRESS_IPv6_ADDRESS Section 4.1.2 3 INGRESS_IPv4_ADDRESS Section 4.1.3 4 INGRESS_IPv6_ADDRESS Section 4.1.4 5 TRAFFIC_DESCRIPTOR_INTERFACE Section 4.1.5 6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX Section 4.1.5 7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX Section 4.1.5 8 TRAFFIC_DESCRIPTOR_APPLICATION Section 4.1.5 9 LabeL_Routes Section 4.1.6 8. Co-authors and Contributors 1. Co-authors - Ning So - Tata Communications - 2613 Fairbourne Cir. - Plano, TX 75082 - USA - Email: ningso01@gmail.com Autumn Liu Ciena USA Email: hliu@ciena.com Zhenbin Li Huawei Technologies Email: zhenbin.li@huawei.com Yimin Shen @@ -979,39 +947,45 @@ Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: yshen@juniper.net Tarek Saad Cisco Systems Email: tsaad@cisco.com - Fengman Xu Verizon 2400 N. Glenville Dr Richardson, TX 75082 USA Email: fengman.xu@verizon.com + 2. Contributors + + Ning So + Tata Communications + 2613 Fairbourne Cir. + Plano, TX 75082 + USA + Email: ningso01@gmail.com + Mehmet Toy Verizon USA Email: mehmet.toy@verizon.com Lei Liu USA Email: liulei.kddi@gmail.com - 2. Contributors - Renwei Li Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: renwei.li@huawei.com Quintin Zhao Huawei Technologies Boston, MA @@ -1034,62 +1007,64 @@ 9. Acknowledgement The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue, Alia Atlas, Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath, Gregory Mirsky, and Ronhazli Adam for their valuable comments and suggestions on this draft. 10. References + 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, - . + . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/ RFC3031, January 2001, - . + . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, - . + . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, - . + . [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, - . + . 10.2. Informative References [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/ RFC6378, October 2011, - . + . Authors' Addresses Huaimo Chen (editor) Huawei Technologies Boston, MA USA Email: huaimo.chen@huawei.com + Raveendra Torvi (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: rtorvi@juniper.net