draft-ietf-mpls-rsvp-egress-protection-01.txt		draft-ietf-mpls-rsvp-egress-protection-02.txt
	Internet Engineering Task Force H. Chen		Internet Engineering Task Force H. Chen
	Internet-Draft Z. Li		Internet-Draft Z. Li
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: January 4, 2015 N. So		Expires: April 29, 2015 N. So
	Tata Communications		Tata Communications
	A. Liu		A. Liu
	Ericsson		Ericsson
			T. Saad
			Cisco Systems
	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
	July 3, 2014		October 26, 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-01.txt		draft-ietf-mpls-rsvp-egress-protection-02.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 45		skipping to change at page 1, line 47
	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 January 4, 2015.		This Internet-Draft will expire on April 29, 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
	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
	skipping to change at page 2, line 28		skipping to change at page 2, line 29
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. An Example of Egress Local Protection . . . . . . . . . . 3		1.1. An Example of Egress Local Protection . . . . . . . . . . 3
	1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4		1.2. Egress Local Protection with FRR . . . . . . . . . . . . . 4
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
	4.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 4		4.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 4
	4.2. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 6		4.2. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 6
	4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6		4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6		5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6
	5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 6		5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 7		5.2. Transit Node and PLR Behavior . . . . . . . . . . . . . . 7
	5.2.1. Signaling for One-to-One Protection . . . . . . . . . 8		5.2.1. Signaling for One-to-One Protection . . . . . . . . . 8
	5.2.2. Signaling for Facility Protection . . . . . . . . . . 8		5.2.2. Signaling for Facility Protection . . . . . . . . . . 8
	5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9		5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9
	5.2.4. PLR Procedures during Local Repair . . . . . . . . . . 10		5.2.4. PLR Procedures during Local Repair . . . . . . . . . . 10
	6. Considering Application Traffic . . . . . . . . . . . . . . . 10		6. Considering Application Traffic . . . . . . . . . . . . . . . 10
	6.1. A Typical Application . . . . . . . . . . . . . . . . . . 10		6.1. A Typical Application . . . . . . . . . . . . . . . . . . 10
	6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11		6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11
	6.3. Egress Procedures for Applications . . . . . . . . . . . . 11		6.3. Egress Procedures for Applications . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.1. New RSVP C-Num and C-Types . . . . . . . . . . . . . . . . 12
			8.2. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12
			8.3. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 13
			9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . . 14		11.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	RFC 4090 describes two methods for protecting the transit nodes of a		RFC 4090 describes two methods for protecting the transit nodes of a
	P2P LSP: one-to-one and facility protection. RFC 4875 specifies how		P2P LSP: one-to-one and facility protection. RFC 4875 specifies how
	to use them to protect the transit nodes of a P2MP LSP. However,		to use them to protect the transit nodes of a P2MP LSP. However,
	they do not mention any local protection for an egress of an LSP.		they do not mention any local protection for an egress of an LSP.
	To protect the egresses of an LSP (P2P or P2MP), an existing approach		To protect the egresses of an LSP (P2P or P2MP), an existing approach
	sets up a backup LSP from a backup ingress (or the ingress of the		sets up a backup LSP from a backup ingress (or the ingress of the
	skipping to change at page 4, line 19		skipping to change at page 4, line 19
	The time for switching the traffic is within tens of milliseconds.		The time for switching the traffic is within tens of milliseconds.
	The failure of a primary egress (e.g., L1 in the figure) MAY be		The failure of a primary egress (e.g., L1 in the figure) MAY be
	detected by its upstream node (e.g., R3 in the figure) through a BFD		detected by its upstream node (e.g., R3 in the figure) through a BFD
	between the upstream node and the egress in MPLS networks. Exactly		between the upstream node and the egress in MPLS networks. Exactly
	how the failure is detected is out of scope for this document.		how the failure is detected is out of scope for this document.
	1.2. Egress Local Protection with FRR		1.2. Egress Local Protection with FRR
	Using the egress local protection and the FRR, we can locally protect		Using the egress local protection and the FRR, we can locally protect
	the egresses, the links and the intermediate nodes of an LSP. The		the egresses, the links and the transit nodes of an LSP. The traffic
	traffic switchover time is within tens of milliseconds whenever an		switchover time is within tens of milliseconds whenever an egress,
	egress, any of the links and the intermediate nodes of the LSP fails.		any of the links and the transit nodes of the LSP fails.
	The egress nodes of the LSP can be locally protected via the egress		The egress nodes of the LSP can be locally protected via the egress
	local protection. All the links and the intermediate nodes of the		local protection. All the links and the transit nodes of the LSP can
	LSP can be locally protected through using the FRR.		be locally protected through using the FRR.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	3. Terminology		3. Terminology
	This document uses terminologies defined in RFC 2205, RFC 3031, RFC		This document uses terminologies defined in RFC 2205, RFC 3031, RFC
	skipping to change at page 5, line 22		skipping to change at page 5, line 22
	~ Primary Egress IPv4/IPv6 address ~		~ Primary Egress IPv4/IPv6 address ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ (Subobjects) ~		~ (Subobjects) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o Backup Egress 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 Primary Egress 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 TLVs and optional. One of them is P2P LSP ID
	subobject, whose body has the following format and Type is TBD-4/		IPv4/IPv6 subobject, whose body has the following format and Type is
	TBD-5. It may be used to identify a backup LSP.		TBD-4/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) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Tunnel ID |		| Reserved | Tunnel ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Extended Tunnel ID (4/16 bytes) ~		~ Extended Tunnel ID (4/16 bytes) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	o P2P LSP Tunnel Egress IPv4/IPv6 Address:		o P2P LSP Tunnel Egress IPv4/IPv6 Address:
	IPv4/IPv6 address of the egress of the tunnel		IPv4/IPv6 address of the egress of the tunnel
	o Tunnel ID:		o Tunnel ID:
	A 16-bit identifier that is constant over the life of the tunnel		A 16-bit identifier that is constant over the life of the tunnel
	o Extended Tunnel ID:		o Extended Tunnel ID:
	A 4/16-byte identifier being constant over the life of the tunnel		A 4/16-byte identifier being constant over the life of the tunnel
	Another one is Label subobject, whose body has the format below and		Another one is Label subobject, whose body has the format below and
	Type is TBD-6 to be assigned by IANA.		Type is TBD-6 to be assigned by IANA.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label |		| Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ (sub-TLVs ) ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The sub-TLVs are optional.
	4.2. Flags in FAST_REROUTE		4.2. Flags in FAST_REROUTE
	A bit of the flags in the FAST_REROUTE object may be used to indicate		Two new bits of the flags in the FAST_REROUTE object may be defined.
	whether S2L Sub LSP is desired for protecting an egress of a P2MP LSP		One bit (called "S2L Sub LSP Backup Desired" flag) indicates whether
	or One-to-One Backup is preferred for protecting an egress of a P2P		S2L Sub LSP is desired for protecting an egress of a P2MP LSP. When
	LSP when the "Facility Backup Desired" flag is set. This bit is		a S2L Sub LSP is desired for protecting an egress of a P2MP LSP, we
	called "S2L Sub LSP Backup Desired" or "One-to-One Backup Preferred".		should set this flag to one.
			The other bit (called "Other Sending UA Label" flag) indicates if
			another protocol is desired for sending a label as a UA label from a
			primary egress to a backup egress. When we want other protocol such
			as BGP to send a label as UA label, this flag should be set to one.
	4.3. Path Message		4.3. Path Message
	A Path message is enhanced to carry the information about a backup		A Path message is enhanced to carry the information about a backup
	egress for a primary egress of an LSP through including an egress		egress for a primary egress of an LSP by including an egress backup
	backup descriptor list. The format of the enhanced Path message is		descriptor list. The format of the message is illustrated below.
	illustrated below.
	<Path Message> ::= <Common Header> [ <INTEGRITY> ]		<Path Message> ::= <Common Header> [ <INTEGRITY> ]
	[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]		[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
	[ <MESSAGE_ID> ]<SESSION> <RSVP_HOP> <TIME_VALUES>		[ <MESSAGE_ID> ]<SESSION> <RSVP_HOP> <TIME_VALUES>
	[ <EXPLICIT_ROUTE> ]		[ <EXPLICIT_ROUTE> ]
	<LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ...]		<LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ...]
	[ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ]		[ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ]
	[ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ]		[ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ]
	<sender descriptor> [<S2L sub-LSP descriptor list>]		<sender descriptor> [<S2L sub-LSP descriptor list>]
	[<egress backup descriptor list>]		[<egress backup descriptor list>]
	skipping to change at page 7, line 11		skipping to change at page 7, line 19
	If one-to-one backup or facility backup method is desired to protect		If one-to-one backup or facility backup method is desired to protect
	a primary egress of an LSP, the ingress SHOULD include a FAST_REROUTE		a primary egress of an LSP, the ingress SHOULD include a FAST_REROUTE
	object and set the "One-to-One Backup Desired" or "Facility Backup		object and set the "One-to-One Backup Desired" or "Facility Backup
	Desired" flag.		Desired" flag.
	If S2L Sub LSP backup method is desired to protect a primary egress		If S2L Sub LSP backup method is desired to protect a primary egress
	of a P2MP LSP, the ingress SHOULD include a FAST_REROUTE object and		of a P2MP LSP, the ingress SHOULD include a FAST_REROUTE object and
	set the "S2L Sub LSP Backup Desired" flag.		set the "S2L Sub LSP Backup Desired" flag.
	Note that if "Facility Backup Desired" flag is set for protecting the		If another protocol is desired for sending a label as a upstream
	intermediate nodes of a primary P2P LSP, but we want to use "One-to-		assigned label to a backup egress, the ingress SHOULD set the "Other
	One Backup" for protecting the egress of the LSP, then the ingress		Sending UA Label" flag.
	SHOULD set "One-to-One Backup Preferred" flag.
	Optionally, a backup egress may be configured on the ingress of an		Optionally, a backup egress may be configured on the ingress of an
	LSP to protect a primary egress of the LSP.		LSP to protect a primary egress of the LSP.
	The ingress sends a Path message for the LSP with the objects above		The ingress sends a Path message for the LSP with the objects above
	and an optional egress backup descriptor list. For each primary		and an optional egress backup descriptor list. For each primary
	egress of the LSP to be protected, the ingress adds an EGRESS_BACKUP		egress of the LSP to be protected, the ingress adds an EGRESS_BACKUP
	object into the list if the backup egress is given. The object		object into the list if the backup egress is given. The object
	contains the primary egress and the backup egress for protecting the		contains the primary egress and the backup egress for protecting the
	primary egress.		primary egress.
	5.2. Intermediate Node and PLR Behavior		5.2. Transit Node and PLR Behavior
	If an intermediate node of an LSP receives the Path message with an		If a transit node of an LSP receives the Path message with an egress
	egress backup descriptor list and it is not an upstream node of any		backup descriptor list and it is not an upstream node of any primary
	primary egress of the LSP, it forwards the list unchanged.		egress of the LSP, it forwards the list unchanged.
	If the intermediate node is the upstream node of a primary egress to		If the transit node is the upstream node of a primary egress to be
	be protected, it determines the backup egress, obtains a path for the		protected, it determines the backup egress, obtains a path for the
	backup LSP and sets up the backup LSP along the path.		backup LSP and sets up the backup LSP along the path.
	The PLR (upstream node of the primary egress) tries to get the backup		The PLR (upstream node of the primary egress) extracts the backup
	egress from EGRESS_BACKUP in the egress backup descriptor list if the		egress from the respective EGRESS_BACKUP object in the egress backup
	Path message contains the list. If the PLR can not get it, the PLR		descriptor list. If no matching EGRESS_BACKUP object is found or the
	tries to find the backup egress, which is not the primary egress but		list is empty, the PLR may apply a local policy to determine the
	has the same IP address as the destination IP address of the LSP.		backup egress and add an EGRESS_BACKUP object with the backup egress
			and primary egress into a Path message to the primary egress.
	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 backup		After obtaining the backup egress, the PLR tries to compute a backup
	path from itself to the backup egress. It excludes the primary		path from itself to the backup egress. It excludes the primary
	egress to be protected when computing the path. Thus the PLR will		egress to be protected when computing the path. Thus the PLR will
	not select any path via the primary egress.		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" flag is set in the message; otherwise, it
	set in the message; otherwise, it provides facility backup protection		provides facility backup protection if the "Facility Backup Desired
	if the "Facility Backup Desired flag" is set.		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
	example, it will set the "local protection available" and the "node		example, it will set the "local protection available" and the "node
	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
	skipping to change at page 9, line 9		skipping to change at page 9, line 12
	egress. If there is a backup LSP that satisfies the constraints		egress. If there is a backup LSP that satisfies the constraints
	given in the Path message, then this one is selected; otherwise, a		given in the Path message, then this one is selected; otherwise, a
	new backup LSP to the backup egress will be created.		new backup LSP to the backup egress will be created.
	After getting the backup LSP, the PLR associates the backup LSP with		After getting the backup LSP, the PLR associates the backup LSP with
	a primary LSP for protecting its primary egress. The PLR records		a primary LSP for protecting its primary egress. The PLR records
	that the backup LSP is used to protect the primary LSP against its		that the backup LSP is used to protect the primary LSP against its
	primary egress failure and includes an EGRESS_BACKUP object in the		primary egress failure and includes an EGRESS_BACKUP object in the
	Path message to the primary egress. The object contains the backup		Path message to the primary egress. The object contains the backup
	egress and the backup LSP ID. It indicates that the primary egress		egress and the backup LSP ID. It indicates that the primary egress
	SHOULD send the backup egress the primary LSP label as UA label.		SHOULD send the backup egress the service label as UA label if there
			is a service carried by the LSP and the primary LSP label as UA label
			if the label is not implicit null.
			A UA label can be sent via RSVP or another protocol (e.g., BGP). If
			"Other Sending UA Label" flag is one, the primary egress SHOULD send
			the UA labels to the backup egress through another protocol;
			otherwise, UA labels are sent via RSVP.
	After receiving the Path message with the EGRESS_BACKUP, the primary		After receiving the Path message with the EGRESS_BACKUP, the primary
	egress includes the information about the primary LSP label in the		egress includes the information about the UA labels in the Resv
	Resv message with an EGRESS_BACKUP object as UA label. When the PLR		message with an EGRESS_BACKUP object. When the PLR receives the Resv
	receives the Resv message with the information about the UA label, it		message with the information about the UA labels, it includes the
	includes the information in the Path message for the backup LSP to		information in the Path message for the backup LSP to the backup
	the backup egress. Thus the primary LSP label as UA label is sent to		egress. Thus the UA labels are sent to the backup egress from the
	the backup egress from the primary egress.		primary egress via RSVP.
	When the PLR detects the failure of the primary egress, it redirects		When the PLR detects the failure of the primary egress, it redirects
	the packets from the primary LSP into the backup LSP to backup egress		the packets from the primary LSP into the backup LSP to backup egress
	using the primary LSP label from the primary egress as an inner		and keeps the primary LSP label from the primary egress in the label
	label. The backup egress delivers the packets to the same		stack if the label is not implicit null. The backup egress delivers
	destinations as the primary egress using the backup LSP label as		the packets to the same destinations as the primary egress using the
	context label and the inner label as UA label.		backup LSP label as context label and the labels under as UA labels.
	5.2.3. Signaling for S2L Sub LSP Protection		5.2.3. Signaling for S2L Sub LSP Protection
	The S2L Sub LSP Protection is used to protect a primary egress of a		The S2L Sub LSP Protection is used to protect a primary egress of a
	P2MP LSP. Its major advantage is that the application traffic		P2MP LSP. Its major advantage is that the application traffic
	carried by the LSP is easily protected against the egress failure.		carried by the LSP is easily protected against the egress failure.
	The PLR determines to protect a primary egress of a P2MP LSP via S2L		The PLR determines to protect a primary egress of a P2MP LSP via S2L
	sub LSP protection when it receives a Path message with flag "S2L Sub		sub LSP protection when it receives a Path message with flag "S2L Sub
	LSP Backup Desired" set.		LSP Backup Desired" set.
	skipping to change at page 10, line 11		skipping to change at page 10, line 21
	the forwarding entry for the backup LSP to active. Thus, the PLR		the forwarding entry for the backup LSP to active. Thus, the PLR
	forwards the traffic to the backup egress through the backup LSP,		forwards the traffic to the backup egress through the backup LSP,
	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 a transit node.
	Moreover, the PLR lets the upstream part of the primary LSP stay		Moreover, the PLR lets the upstream part of the primary LSP stay
	after the primary egress fails. It continues to send resv message to		after the primary egress fails. It continues to send Resv message to
	its upstream node along the primary LSP. The downstream part of the		its upstream node along the primary LSP. The downstream part of the
	primary LSP from the PLR to the primary egress SHOULD be removed.		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.
	6. Considering Application Traffic		6. Considering Application Traffic
	skipping to change at page 11, line 48		skipping to change at page 12, line 11
	protecting a primary egress of a primary LSP, it includes an		protecting a primary egress of a primary LSP, it includes an
	EGRESS_BACKUP object in the Path message for the primary LSP. The		EGRESS_BACKUP object in the Path message for the primary LSP. The
	object contains the ID information of the backup LSP and indicates		object contains the ID information of the backup LSP and indicates
	that the primary egress SHOULD send the backup egress the application		that the primary egress SHOULD send the backup egress the application
	traffic label (e.g., VPN label) as UA label when needed.		traffic label (e.g., VPN label) as UA label when needed.
	6.3. Egress Procedures for Applications		6.3. Egress Procedures for Applications
	When a primary egress of an LSP sends the ingress of the LSP a label		When a primary egress of an LSP sends the ingress of the LSP a label
	for an application such as a VPN, it SHOULD send the backup egress		for an application such as a VPN, it SHOULD send the backup egress
	for protecting the primary egress the label as a UA label via BGP or		for protecting the primary egress the label as a UA label. Exactly
	another protocol. Exactly how the label is sent is out of scope for		how the label is sent is out of scope for this document.
	this document.
	When the backup egress receives a UA label from the primary egress,		When the backup egress receives a UA label from the primary egress,
	it adds a forwarding entry with the label into the LFIB for the		it adds a forwarding entry with the label into the LFIB for the
	primary egress. When the backup egress receives a packet from the		primary egress. When the backup egress receives a packet from the
	backup LSP, it uses the top label as a context label to find the LFIB		backup LSP, it uses the top label as a context label to find the LFIB
	for the primary egress and the inner label to deliver the packet to		for the primary egress and the inner label to deliver the packet to
	the same destination as the primary egress according to the LFIB.		the same destination as the primary egress according to the LFIB.
	7. Security Considerations		7. 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.
	8. IANA Considerations		8. IANA Considerations
	IANA considerations for new objects will be specified after the		8.1. New RSVP C-Num and C-Types
	objects used are decided upon.
			This document defines a new C-Num, which should be assigned by IANA.
			o EGRESS_BACKUP object. The C-Num should be of the form 11bbbbbb so
			that LSRs that do not recognize it will ignore it but forward it.
			Two C-Types defined for this object should be assigned by IANA.
			- EGRESS_BACKUP_IPv4. Recommended C-Type value 1.
			- EGRESS_BACKUP_IPv6. Recommended C-Type value 2.
			8.2. New TLVs
			The new object referenced above contains TLVs. This document defines
			three TLV types as follows:
			Type Name Allowed on
			1 P2P_LSP_ID_IPv4 TLV EGRESS_BACKUP_IPv4
			2 P2P_LSP_ID_IPv6 TLV EGRESS_BACKUP_IPv6
			3 Label TLV EGRESS_BACKUP_IPv4/IPv6
			8.3. Flags in FAST_REROUTE
			Two flags defined in FAST_REROUTE object should be assigned by IANA.
			0x04 S2L Sub LSP Backup Desired
			0x08 Other Sending UA Label
	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
	skipping to change at page 13, line 7		skipping to change at page 13, line 37
	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, Nobo Akiya, Tarek Saad,		The authors would like to thank Richard Li, Nobo Akiya, Jeffrey
	Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue,		Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael
	Rob Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli		Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan Sampath, Yimin
	Adam and Quintin Zhao for their valuable comments and suggestions on		Shen, Ronhazli Adam and Quintin Zhao for their valuable comments and
	this draft.		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 15, line 4		skipping to change at page 15, line 29
	Email: lizhenbin@huawei.com		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: ningso01@gmail.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
			Tarek Saad
			Cisco Systems
			Email: tsaad@cisco.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. 33 change blocks.
	82 lines changed or deleted		125 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/