--- 1/draft-ietf-teas-rsvp-ingress-protection-07.txt 2016-09-01 20:16:10.715597790 -0700 +++ 2/draft-ietf-teas-rsvp-ingress-protection-08.txt 2016-09-01 20:16:10.763599002 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force H. Chen, Ed. Internet-Draft Huawei Technologies Intended status: Experimental R. Torvi, Ed. -Expires: February 9, 2017 Juniper Networks - August 8, 2016 +Expires: March 5, 2017 Juniper Networks + September 1, 2016 - Extensions to RSVP-TE for LSP Ingress Local Protection - draft-ietf-teas-rsvp-ingress-protection-07.txt + Extensions to RSVP-TE for LSP Ingress FRR Protection + draft-ietf-teas-rsvp-ingress-protection-08.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. Status of this Memo @@ -23,21 +23,21 @@ 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 9, 2017. + This Internet-Draft will expire on March 5, 2017. Copyright Notice Copyright (c) 2016 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 @@ -101,21 +101,23 @@ protecting its ingress node and transit nodes. Protecting an ingress is not covered either in the fast-reroute method defined in [RFC4090] or in the P2MP fast-reroute extensions to fast-reroute in [RFC4875]. An alternate approach to local protection (fast-reroute) is to use global protection and set up a secondary backup LSP (whether P2MP or P2P) from a backup ingress to the egresses. The main disadvantage of this is that the backup LSP may reserve additional network bandwidth. This specification defines a simple extension to RSVP-TE for local - protection of the ingress node of a P2MP or P2P LSP. + protection (FRR) of the ingress node of a P2MP or P2P LSP. Ingress + local protection and ingress FRR protection will be used + exchangeably. 2.1. An Example of 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 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. [R2]******[R3]*****[L1] * | **** Primary LSP @@ -1016,20 +1018,33 @@ 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. The ingress local protection proposed in this draft will resolve the above issues. + The Pseudowire (PW) protection in PALS is a different level + protection than the TE LSP tunnel protection in TEAS. The former is + about protecting a PW, which is one level above an LSP tunnel. + + Draft "Dual-Homing Protection for MPLS and MPLS-TP Pseudowires" in + PALS describes a framework and several scenarios for Pseudowire (PW) + dual-homing protection, which protects the failures in the Attachment + Circuit (AC) or PW side. For protecting a working PW (against the + failure of the primary PW ingress such as PE1), an end-to-end + protection PW from a backup PW ingress such as PE2 is created. The + protection PW crosses the network from a PE connecting to a CE to + another PE connecting to another CE. + Appendix B. Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: huaimo.chen@huawei.com Raveendra Torvi Juniper Networks @@ -1063,20 +1078,15 @@ Email: tsaad@cisco.com Fengman Xu Verizon 2400 N. Glenville Dr Richardson, TX 75082 USA Email: fengman.xu@verizon.com Mehmet Toy - Comcast - 1800 Bishops Gate Blvd. - Mount Laurel, NJ 08054 USA - Email: mehmet_toy@cable.comcast.com - + Email: mtoy054@yahoo.com Lei Liu - UC Davis USA Email: liulei.kddi@gmail.com