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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/