--- 1/draft-ietf-mpls-rsvp-egress-protection-00.txt 2014-07-03 21:14:27.579728331 -0700 +++ 2/draft-ietf-mpls-rsvp-egress-protection-01.txt 2014-07-03 21:14:27.615729206 -0700 @@ -1,29 +1,30 @@ Internet Engineering Task Force H. Chen -Internet-Draft Huawei Technologies -Intended status: Standards Track N. So -Expires: September 18, 2014 Tata Communications +Internet-Draft Z. Li +Intended status: Standards Track Huawei Technologies +Expires: January 4, 2015 N. So + Tata Communications A. Liu Ericsson F. Xu Verizon M. Toy Comcast L. Huang China Mobile L. Liu UC Davis - March 17, 2014 + July 3, 2014 Extensions to RSVP-TE for LSP Egress Local Protection - draft-ietf-mpls-rsvp-egress-protection-00.txt + draft-ietf-mpls-rsvp-egress-protection-01.txt Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP) in a Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. Status of this Memo @@ -33,21 +34,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 September 18, 2014. + This Internet-Draft will expire on January 4, 2015. Copyright Notice Copyright (c) 2014 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 @@ -178,30 +179,30 @@ The class of the EGRESS_BACKUP object is TBD-1 to be assigned by IANA. The C-Type of the EGRESS_BACKUP IPv4/IPv6 object is TBD-2/ TBD-3 to be assigned by IANA. EGRESS_BACKUP Class Num = TBD-1, IPv4/IPv6 C-Type = TBD-2/TBD-3 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Egress Backup destination IPv4/IPv6 address ~ + ~ Backup Egress IPv4/IPv6 address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Egress Primary destination IPv4/IPv6 address ~ + ~ Primary Egress IPv4/IPv6 address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ (Subobjects) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - o Egress Backup destination IPv4/IPv6 address: + o Backup Egress IPv4/IPv6 address: IPv4/IPv6 address of the backup egress node - o Egress Primary destination IPv4/IPv6 address: + o Primary Egress IPv4/IPv6 address: IPv4/IPv6 address of the primary egress node The Subobjects are optional. One of them is P2P LSP ID IPv4/IPv6 subobject, whose body has the following format and Type is TBD-4/ TBD-5. It may be used to identify a backup LSP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ P2P LSP Tunnel Egress IPv4/IPv6 Address (4/16 bytes) ~ @@ -309,22 +310,24 @@ Path message contains the list. If the PLR can not get it, the PLR tries to find the backup egress, which is not the primary egress but has the same IP address as the destination IP address of the LSP. Note that the primary egress and the backup egress SHOULD have a same local address configured, and the cost to the local address on the backup egress SHOULD be much bigger than the cost to the local address on the primary egress. Thus another name such as virtual node based egress protection may be used for egress local protection. - After obtaining the backup egress, the PLR tries to compute a path - from itself to the backup egress. + After obtaining the backup egress, the PLR tries to compute a backup + path from itself to the backup egress. It excludes the primary + egress to be protected when computing the path. Thus the PLR will + not select any path via the primary egress. The PLR then sets up the backup LSP along the path obtained. It provides one-to-one backup protection for the primary egress if the "One-to-One Backup Desired" or "One-to-One Backup Preferred" flag is set in the message; otherwise, it provides facility backup protection if the "Facility Backup Desired flag" is set. The PLR sets the protection flags in the RRO Sub-object for the primary egress in the Resv message according to the status of the primary egress and the backup LSP protecting the primary egress. For @@ -332,24 +335,24 @@ protection" flag indicating that the primary egress is protected when the backup LSP is up and ready for protecting the primary egress. 5.2.1. Signaling for One-to-One Protection The behavior of the upstream node of a primary egress of an LSP as a PLR is the same as that of a PLR for one-to-one backup method described in RFC 4090 except for that the upstream node creates a backup LSP from itself to a backup egress. - If the LSP is a P2MP LSP and a primary egress of the LSP is a transit - node (i.e., bud node), the upstream node of the primary egress as a - PLR also creates a backup LSP from itself to each of the next hops of - the primary egress. + If the LSP is a P2MP LSP and a primary egress of the LSP is also a + transit node (i.e., bud node), the upstream node of the primary + egress as a PLR also creates a backup LSP from itself to each of the + next hops of the primary egress. When the PLR detects the failure of the primary egress, it MUST switch the packets from the primary LSP to the backup LSP to the backup egress. For the failure of the bud node of a P2MP LSP, the PLR MUST also switch the packets to the backup LSPs to the bud node's next hops, where the packets are merged into the primary LSP. 5.2.2. Signaling for Facility Protection Except for backup LSP and downstream label, the behavior of the @@ -417,35 +420,36 @@ which sends the traffic to its destination. 5.2.4. PLR Procedures during Local Repair When the upstream node of a primary egress of an LSP as a PLR detects the failure of the primary egress, it follows the procedures defined in section 6.5 of RFC 4090. It SHOULD notify the ingress about the failure of the primary egress in the same way as a PLR notifies the ingress about the failure of an intermediate node. + Moreover, the PLR lets the upstream part of the primary LSP stay + after the primary egress fails. It continues to send resv message to + its upstream node along the primary LSP. The downstream part of the + primary LSP from the PLR to the primary egress SHOULD be removed. + In the local revertive mode, the PLR re-signals each of the primary LSPs that were routed over the restored resource once it detects that the resource is restored. Every primary LSP successfully re-signaled along the restored resource is switched back. - Moreover, the PLR lets the upstream part of the primary LSP stay - after the primary egress fails. The downstream part of the primary - LSP from the PLR to the primary egress SHOULD be removed. - 6. Considering Application Traffic This section focuses on the application traffic carried by P2P LSPs. When a primary egress of a P2MP LSP fails, the application traffic - carried by the P2MP LSP may be delivered to the same destination by - the backup egress since the inner label if any for the traffic is a + carried by the P2MP LSP is delivered to the same destination by the + backup egress since the inner label if any for the traffic is a upstream assigned label for every egress of the P2MP LSP. 6.1. A Typical Application L3VPN is a typical application. An existing solution (refer to Figure 2) for protecting L3VPN traffic against egress failure includes: 1) A multi-hop BFD session between ingress R1 and egress L1 of primary LSP; 2) A backup LSP from ingress R1 to backup egress La; 3) La sends R1 VPN backup label and related information via BGP; 4) R1 has a VRF with two sets of routes: one uses primary LSP and L1 as @@ -528,47 +532,41 @@ 9. Contributors Boris Zhang Telus Communications 200 Consilium Pl Floor 15 Toronto, ON M1H 3J3 Canada Email: Boris.Zhang@telus.com - Zhenbin Li - Huawei Technologies - Huawei Bld., No.156 Beiqing Rd. - Beijing 100095 - China - Email: lizhenbin@huawei.com - Nan Meng Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: mengnan@huawei.com Vic Liu China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing, 100053 China Email: liuzhiheng@chinamobile.com 10. Acknowledgement - The authors would like to thank Richard Li, Tarek Saad, Lizhong Jin, - Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Rob Rennison, - Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam and Quintin - Zhao for their valuable comments and suggestions on this draft. + The authors would like to thank Richard Li, Nobo Akiya, Tarek Saad, + Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, + Rob Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli + Adam and Quintin Zhao for their valuable comments and suggestions on + this draft. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. @@ -618,34 +616,42 @@ Authors' Addresses Huaimo Chen Huawei Technologies Boston, MA USA Email: huaimo.chen@huawei.com + Zhenbin Li + Huawei Technologies + Huawei Bld., No.156 Beiqing Rd. + Beijing 100095, + China + + Email: lizhenbin@huawei.com + Ning So Tata Communications 2613 Fairbourne Cir. Plano, TX 75082 USA - Email: ning.so@tatacommunications.com - + Email: ningso01@gmail.com Autumn Liu Ericsson CA USA Email: autumn.liu@ericsson.com + Fengman Xu Verizon 2400 N. Glenville Dr Richardson, TX 75082 USA Email: fengman.xu@verizon.com Mehmet Toy Comcast