draft-chen-mpls-p2mp-egress-protection-10.txt		draft-chen-mpls-p2mp-egress-protection-11.txt
	Internet Engineering Task Force H. Chen		Internet Engineering Task Force H. Chen
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Standards Track N. So		Intended status: Standards Track N. So
	Expires: June 1, 2014 Tata Communications		Expires: August 14, 2014 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
	November 28, 2013		February 10, 2014
	Extensions to RSVP-TE for LSP Egress Local Protection		Extensions to RSVP-TE for LSP Egress Local Protection
	draft-chen-mpls-p2mp-egress-protection-10.txt		draft-chen-mpls-p2mp-egress-protection-11.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 44
	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 June 1, 2014.		This Internet-Draft will expire on August 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv6 Object . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object . . . . . . 5		4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. EGRESS_BACKUP Object . . . . . . . . . . . . . . . . . . . 4
	3. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6		4.2. Flags in FAST_REROUTE . . . . . . . . . . . . . . . . . . 6
	3.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 7		4.3. Path Message . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 7		5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 6
	3.2.1. Signaling for One-to-One Protection . . . . . . . . . 8		5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 6
	3.2.2. Signaling for Facility Protection . . . . . . . . . . 8		5.2. Intermediate Node and PLR Behavior . . . . . . . . . . . . 7
	3.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9		5.2.1. Signaling for One-to-One Protection . . . . . . . . . 8
	3.2.4. PLR Procedures during Local Repair . . . . . . . . . . 9		5.2.2. Signaling for Facility Protection . . . . . . . . . . 8
	4. Considering Application Traffic . . . . . . . . . . . . . . . 10		5.2.3. Signaling for S2L Sub LSP Protection . . . . . . . . . 9
	4.1. A Typical Application . . . . . . . . . . . . . . . . . . 10		5.2.4. PLR Procedures during Local Repair . . . . . . . . . . 10
	4.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11		6. Considering Application Traffic . . . . . . . . . . . . . . . 10
	4.3. Egress Procedures for Applications . . . . . . . . . . . . 11		6.1. A Typical Application . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6.2. PLR Procedure for Applications . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6.3. Egress Procedures for Applications . . . . . . . . . . . . 11
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
			11.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	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 protection and facility bypass protection. RFC		P2P LSP: one-to-one and facility protection. RFC 4875 specifies how
	4875 specifies how to use them to protect the transit nodes of a P2MP		to use them to protect the transit nodes of a P2MP LSP. However,
	LSP. However, there is no mention of locally protecting any egress		they do not mention any local protection for an egress of an LSP.
	of a protected P2P or P2MP LSP in these RFCs.
	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
	LSP) to the backup egresses, where each egress is paired with a		LSP) to the backup egresses, where each egress is paired with a
	backup egress and protected by the backup egress.		backup egress and protected by the backup egress.
	The main disadvantage of this approach is that more network resources		This approach may use more resources and provide slow fault recovery.
	such as double bandwidths may be used.		This document specifies extensions to RSVP-TE for local protection of
			an egress of an LSP, which overcomes these disadvantages.
	This document specifies extensions to RSVP-TE for locally protecting
	an egress of a P2MP or P2P LSP, which overcome this disadvantage.
	1.1. An Example of Egress Local Protection		1.1. An Example of Egress Local Protection
	Figure 1 illustrates an example of using backup LSPs to locally		Figure 1 shows an example of using backup LSPs to locally protect
	protect egress nodes of a primary P2MP LSP, which is from ingress		egresses of a primary P2MP LSP from ingress R1 to two egresses: L1
	node R1 to two egress nodes: L1 and L2. The primary LSP is		and L2. The primary LSP is represented by star(*) lines and backup
	represented by star(*) lines and backup LSPs by hyphen(-) lines.		LSPs by hyphen(-) lines.
	La and Lb are the designated backup egress nodes for egress nodes L1
	and L2 of the P2MP LSP respectively. To distinguish between an
	egress (e.g., L1 in the figure) and a backup egress (e.g., La in the
	figure), an egress is called a primary egress if necessary.
	The backup LSP for protecting primary egress L1 is from its upstream
	node R3 to backup egress La. The backup LSP for protecting primary
	egress L2 is from its upstream node R5 to backup egress Lb.
	During normal operations, the traffic carried by the P2MP LSP is sent		La and Lb are the designated backup egresses for egresses L1 and L2
	through R3 to L1, which delivers the traffic to its destination CE1.		respectively. To distinguish an egress (e.g., L1) from a backup
	When R3 detects the failure of L1, R3 switches the traffic to the		egress (e.g., La), an egress is called a primary egress if needed.
	backup LSP to backup egress La, which delivers the traffic to CE1.
	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 backup LSP for protecting L1 is from its upstream node R3 to
	detected by its upstream node (e.g., R3 in the figure) through a BFD		backup egress La. The one for protecting L2 is from R5 to Lb.
	session between the upstream node and the egress in MPLS networks.
	Exactly how the failure is detected is out of scope for this
	document.
	[R2]*****[R3]*****[L1]		[R2]*****[R3]*****[L1]
	* \ :.....: $ **** Primary LSP		* \ :.....: $ **** Primary LSP
	* \ $ ---- Backup LSP		* \ $ ---- Backup LSP
	* \ [CE1] .... BFD Session		* \ [CE1] .... BFD Session
	* \ $ $ Link		* \ $ $ Link
	* \ $ $		* \ $ $
	* [La] $		* [La] $
	*		*
	[R1]******[R4]*******[R5]*****[L2]		[R1]******[R4]*******[R5]*****[L2]
	$ \ :.....: $		$ \ :.....: $
	$ \ $		$ \ $
	[S] \ [CE2]		[S] \ [CE2]
	\ $		\ $
	\ $		\ $
	[Lb]		[Lb]
	Figure 1: Backup LSP for Locally Protecting Egress		Figure 1: Backup LSP for Locally Protecting Egress
			During normal operations, the traffic carried by the P2MP LSP is sent
			through R3 to L1, which delivers the traffic to its destination CE1.
			When R3 detects the failure of L1, R3 switches the traffic to the
			backup LSP to backup egress La, which delivers the traffic to CE1.
			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
			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
			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 intermediate nodes of an LSP. The
	traffic switchover time is within tens of milliseconds whenever an		traffic switchover time is within tens of milliseconds whenever an
	egress, any of the links and the intermediate nodes of the LSP fails.		egress, any of the links and the intermediate 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 intermediate nodes of the
	LSP can be locally protected through using the FRR.		LSP can be locally protected through using the FRR.
	2. Protocol Extensions		2. Conventions Used in This Document
	A new object EGRESS_BACKUP_SUB_LSP is defined for signaling egress		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	local protection. It contains a backup egress for a primary egress.		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119.
	2.1. EGRESS_BACKUP_SUB_LSP IPv4/IPv6 Object		3. Terminology
	The class of the EGRESS_BACKUP_SUB_LSP IPv4/IPv6 object is 50, which		This document uses terminologies defined in RFC 2205, RFC 3031, RFC
	is the same as that of the S2L_SUB_LSP IPv4/IPv6 object defined in		3209, RFC 3473, RFC 4090, RFC 4461, and RFC 4875.
	RFC 4875. The C-Type of the EGRESS_BACKUP_SUB_LSP IPv4 object is a
	new number 3 or another number assigned by IANA.
	EGRESS_BACKUP_SUB_LSP_IPv4 C-Type = 3		4. Protocol Extensions
	0 1 2 3		A new object EGRESS_BACKUP is defined for egress local protection.
	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		It contains a backup egress for a primary egress.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Egress Backup Sub LSP destination IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Egress Primary Sub LSP destination IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| (Subobjects) |
	~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Egress Backup Sub LSP destination IPv4 address		4.1. EGRESS_BACKUP Object
	IPv4 address of the backup egress node
	Egress Primary Sub LSP destination IPv4 address
	IPv4 address of the primary egress node
	Subobjects are optional
	The C-Type of the EGRESS_BACKUP_SUB_LSP IPv6 object is a new number 4		The class of the EGRESS_BACKUP object is TBD-1 to be assigned by
	or another number assigned by IANA.		IANA. The C-Type of the EGRESS_BACKUP IPv4/IPv6 object is TBD-2/
			TBD-3 to be assigned by IANA.
	EGRESS_BACKUP_SUB_LSP_IPv6 C-Type = 4		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 Sub LSP destination IPv6 address |		~ Egress Backup destination IPv4/IPv6 address ~
	~ (16 bytes) ~		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		~ Egress Primary destination IPv4/IPv6 address ~
	| Egress Primary Sub LSP destination IPv6 address |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ (16 bytes) ~		~ (Subobjects) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| (Subobjects) |
	~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Egress Backup Sub LSP destination IPv6 address		o Egress Backup destination IPv4/IPv6 address:
	IPv6 address of the backup egress node		IPv4/IPv6 address of the backup egress node
	Egress Primary Sub LSP destination IPv6 address		o Egress Primary destination IPv4/IPv6 address:
	IPv6 address of the primary egress node		IPv4/IPv6 address of the primary egress node
	Subobjects are optional
	2.2. EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE Object		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.
	An EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE (EB-SERO) object is defined		0 1 2 3
	for signaling protection for a primary egress of a P2MP LSP in a new		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
	S2L Sub LSP backup protection method. It contains a path from the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	upstream node of the primary egress to a backup egress. Its format		~ P2P LSP Tunnel Egress IPv4/IPv6 Address (4/16 bytes) ~
	is identical to an ERO's.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved | Tunnel ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Extended Tunnel ID (4/16 bytes) ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The class of an EB-SERO is the same as that of a SERO defined in RFC		o P2P LSP Tunnel Egress IPv4/IPv6 Address:
	4873. The EB-SERO uses a new C-Type 3, or another number assigned by		IPv4/IPv6 address of the egress of the tunnel
	IANA. The formats of sub-objects in an EB-SERO are identical to		o Tunnel ID:
	those of sub-objects in an ERO defined in RFC 3209.		A 16-bit identifier that is constant over the life of the tunnel
			o Extended Tunnel ID:
			A 4/16-byte identifier being constant over the life of the tunnel
	2.3. Path Message		Another one is Label subobject, whose body has the format below and
			Type is TBD-6 to be assigned by IANA.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Label |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			4.2. Flags in FAST_REROUTE
			A bit of the flags in the FAST_REROUTE object may be used to indicate
			whether S2L Sub LSP is desired for protecting an egress of a P2MP LSP
			or One-to-One Backup is preferred for protecting an egress of a P2P
			LSP when the "Facility Backup Desired" flag is set. This bit is
			called "S2L Sub LSP Backup Desired" or "One-to-One Backup Preferred".
			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 through including an egress
	backup sub LSP descriptor list. The format of the enhanced Path		backup descriptor list. The format of the enhanced Path message is
	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> ]		[ <MESSAGE_ID> ]<SESSION> <RSVP_HOP> <TIME_VALUES>
	<SESSION> <RSVP_HOP> <TIME_VALUES>		[ <EXPLICIT_ROUTE> ]
	[ <EXPLICIT_ROUTE> ]		<LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ...]
	<LABEL_REQUEST> [ <PROTECTION> ]		[ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ]
	[ <LABEL_SET> ... ]		[ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ]
	[ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ]		<sender descriptor> [<S2L sub-LSP descriptor list>]
	[ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ]		[<egress backup descriptor list>]
	<sender descriptor>
	[<S2L sub-LSP descriptor list>]
	[<egress backup sub LSP descriptor list>]
	The egress backup sub LSP descriptor list in the message is defined		The egress backup descriptor list in the message is defined below.
	below. It is a sequence of EGRESS_BACKUP_SUB_LSP objects, each of		It is a sequence of EGRESS_BACKUP objects, each of which describes a
	which describes a pair of a primary egress and a backup egress.		pair of a primary egress and a backup egress.
	<egress backup sub LSP descriptor list> ::=		<egress backup descriptor list> ::=
	<egress backup sub LSP descriptor>		<egress backup descriptor>
	[ <egress backup sub LSP descriptor list> ]		[ <egress backup descriptor list> ]
	<egress backup sub LSP descriptor> ::=		<egress backup descriptor> ::= <EGRESS_BACKUP>
	<EGRESS_BACKUP_SUB_LSP>
	[ <EGRESS_BACKUP_SECONDARY_EXPLICIT_ROUTE> ]
	3. Egress Protection Behaviors		5. Egress Protection Behaviors
	3.1. Ingress Behavior
	To protect a primary egress of an LSP, a backup egress must be		5.1. Ingress Behavior
	configured on the ingress of the LSP.
	The ingress initiates a Path message for the LSP with an egress		To protect a primary egress of an LSP, the ingress MUST set the
	backup sub LSP descriptor list. For each primary egress of the LSP		"label recording desired" flag and the "node protection desired" flag
	to be protected, the ingress MUST add an EGRESS_BACKUP_SUB_LSP object		in the SESSION_ATTRIBUTE object.
	into the list. The object contains the primary egress and the backup
	egress for protecting the primary egress.
	To protect a primary egress of an LSP via one-to-one backup or		If one-to-one backup or facility backup method is desired to protect
	facility backup method, 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.
	To protect a primary egress of a P2MP LSP via S2L Sub LSP backup		If S2L Sub LSP backup method is desired to protect a primary egress
	method, the ingress SHOULD add an EB-SERO object following the		of a P2MP LSP, the ingress SHOULD include a FAST_REROUTE object and
	EGRESS_BACKUP_SUB_LSP object into the list. The EB-SERO object		set the "S2L Sub LSP Backup Desired" flag.
	contains a path from the upstream node of the primary egress to the
	backup egress. The ingress computes the path if the P2MP LSP is in
	one area; otherwise, the path may be computed by the Path Computation
	Element (PCE).
	3.2. Intermediate Node and PLR Behavior		Note that if "Facility Backup Desired" flag is set for protecting the
			intermediate nodes of a primary P2P LSP, but we want to use "One-to-
			One Backup" for protecting the egress of the LSP, then the ingress
			SHOULD set "One-to-One Backup Preferred" flag.
			Optionally, a backup egress may be configured on the ingress of an
			LSP to protect a primary egress of the LSP.
			The ingress sends a Path message for the LSP with the objects above
			and an optional egress backup descriptor list. For each primary
			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
			contains the primary egress and the backup egress for protecting the
			primary egress.
			5.2. Intermediate Node and PLR Behavior
	If an intermediate node of an LSP receives the Path message with an		If an intermediate node of an LSP receives the Path message with an
	egress backup sub LSP descriptor list and it is not an upstream node		egress backup descriptor list and it is not an upstream node of any
	of any primary egress of the LSP, it forwards the list in the message		primary egress of the LSP, it forwards the list unchanged.
	unchanged.
	If the intermediate node is the upstream node of a primary egress to		If the intermediate node is the upstream node of a primary egress to
	be protected, it gets the backup egress for the primary egress from		be protected, it determines the backup egress, obtains a path for the
	the EGRESS_BACKUP_SUB_LSP object in the list. It acts as a PLR to		backup LSP and sets up the backup LSP along the path.
	provide one-to-one or facility backup protection for the primary
	egress. It provides one-to-one backup protection if the One-to-One
	Backup Desired flag is set in the message; it provides facility
	backup protection if the Facility Backup Desired flag is set.
	The PLR (upstream node of the primary egress) sets the protection		The PLR (upstream node of the primary egress) tries to get the backup
	flags in the RRO Sub-object for the primary egress in the Resv		egress from EGRESS_BACKUP in the egress backup descriptor list if the
	message according to the status of the primary egress and the backup		Path message contains the list. If the PLR can not get it, the PLR
	LSP protecting the primary egress. For example, it will set the		tries to find the backup egress, which is not the primary egress but
	"local protection available" and the "node protection" flag to one		has the same IP address as the destination IP address of the LSP.
	indicating that the primary egress is protected when the backup LSP
	to the backup egress is set up for protecting the primary egress.
	3.2.1. Signaling for One-to-One Protection		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.
			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
			example, it will set the "local protection available" and the "node
			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		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.
	In the case that the LSP is a P2MP LSP and a primary egress of the		If the LSP is a P2MP LSP and a primary egress of the LSP is a transit
	LSP is a transit node (i.e., bud node), the upstream node of the		node (i.e., bud node), the upstream node of the primary egress as a
	primary egress as a PLR also creates a backup LSP from itself to each		PLR also creates a backup LSP from itself to each of the next hops of
	of the next hops of the primary egress.		the primary egress.
	When the PLR detects a failure in the primary egress, it MUST rapidly		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 a failure in the bud node of an P2MP LSP, the PLR		backup egress. For the failure of the bud node of a P2MP LSP, the
	MUST also rapidly switch the packets to the backup LSPs to the bud		PLR MUST also switch the packets to the backup LSPs to the bud node's
	node's next hops, where the packets are merged into the primary LSP.		next hops, where the packets are merged into the primary LSP.
	3.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
	upstream node of the primary egress as a PLR follows the PLR behavior		upstream node of the primary egress of a primary LSP as a PLR follows
	for facility backup method described in RFC 4090.		the PLR behavior for facility backup method described in RFC 4090.
	For a number of primary P2P LSPs going through the same PLR to the		For a number of primary P2P LSPs going through the same PLR to the
	same primary egress, the primary egress of these LSPs may be		same primary egress, the primary egress of these LSPs may be
	protected by one backup LSP from the PLR to the backup egress		protected by one backup LSP from the PLR to the backup egress
	designated for protecting the primary egress.		designated for protecting the primary egress.
	The PLR selects or creates a backup LSP from itself to the backup		The PLR selects or creates a backup LSP from itself to the backup
	egress. If there exists 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.
	For a primary LSP carrying IP packets, the PLR does not need any		After getting the backup LSP, the PLR associates the backup LSP with
	downstream label as an inner label for the LSP when binding the		a primary LSP for protecting its primary egress. The PLR records
	primary LSP with the backup LSP. When the PLR detects a failure in		that the backup LSP is used to protect the primary LSP against its
	the primary egress, it redirects the IP packets from the primary LSP		primary egress failure and includes an EGRESS_BACKUP object in the
	into the backup LSP to the backup egress, where the IP packets are		Path message to the primary egress. The object contains the backup
	forwarded according to IP destinations in the packets.		egress and the backup LSP ID. It indicates that the primary egress
			SHOULD send the backup egress the primary LSP label as UA label.
	For a primary LSP carrying packets with application or service		After receiving the Path message with the EGRESS_BACKUP, the primary
	labels, the PLR may not need any downstream label as an inner label		egress includes the information about the primary LSP label in the
	for the LSP either when binding the primary LSP with the backup LSP.		Resv message with an EGRESS_BACKUP object as UA label. When the PLR
	When the PLR detects a failure in the primary egress, it redirects		receives the Resv message with the information about the UA label, it
			includes the information in the Path message for the backup LSP to
			the backup egress. Thus the primary LSP label as UA label is sent to
			the backup egress from the primary egress.
			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
	through switching the top label with the backup LSP label. The		using the primary LSP label from the primary egress as an inner
	backup egress delivers the packets to the same destinations as the		label. The backup egress delivers the packets to the same
	primary egress (see details in section "Considering Application		destinations as the primary egress using the backup LSP label as
	Traffic" below).		context label and the inner label as UA label.
	3.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 P2MP LSP may be easily protected against the egress		carried by the LSP is easily protected against the egress failure.
	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 an EB-SERO		sub LSP protection when it receives a Path message with flag "S2L Sub
	object following the EGRESS_BACKUP_SUB_LSP containing the primary		LSP Backup Desired" set.
	egress and a backup egress.
	The PLR sets up the backup S2L sub LSP to the backup egress, creates		The PLR sets up the backup S2L sub LSP to the backup egress, creates
	and maintains its state in the same way as of setting up a source to		and maintains its state in the same way as of setting up a source to
	leaf (S2L) sub LSP defined in RFC 4875 from the signaling's point of		leaf (S2L) sub LSP defined in RFC 4875 from the signaling's point of
	view. It constructs and sends a PATH message along the path given in		view. It computes a path for the backup LSP from itself to the
	the EB-SERO for the backup LSP, receives and processes a RESV message		backup egress, constructs and sends a Path message along the path,
	that responses to the PATH message.		receives and processes a Resv message responding to the Path message.
	After receiving the RESV message for the backup LSP, the PLR creates		After receiving the Resv message for the backup LSP, the PLR creates
	a forwarding entry with an inactive state or flag called inactive		a forwarding entry with an inactive state or flag called inactive
	forwarding entry. This inactive forwarding entry is not used to		forwarding entry. This inactive forwarding entry is not used to
	forward any data traffic during normal operations.		forward any data traffic during normal operations.
	When the PLR detects a failure in the primary egress failure, it		When the PLR detects the failure of the primary egress, it changes
	changes the forwarding entry for the backup LSP to active. Thus, the		the forwarding entry for the backup LSP to active. Thus, the PLR
	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.
	3.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
	a failure in the primary egress, it follows the procedures defined in		the failure of the primary egress, it follows the procedures defined
	section 6.5 of RFC 4090.		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
	The PLR (i.e., the upstream node of the primary egress) SHOULD notify		ingress about the failure of an intermediate node.
	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.
	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 used to be routed over the restored resource once it		LSPs that were routed over the restored resource once it detects that
	detects that the resource is restored. Every primary LSP		the resource is restored. Every primary LSP successfully re-signaled
	successfully re-signaled along the restored resource is switched		along the restored resource is switched back.
	back.
	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. The downstream part of the primary		after the primary egress fails. The downstream part of the primary
	LSP from the PLR to the primary egress SHOULD be removed.		LSP from the PLR to the primary egress SHOULD be removed.
	4. 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 may be delivered to the same destination by
	the backup egress since the inner label if any for the traffic is a		the 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.
	4.1. A Typical Application		6.1. A Typical Application
	L3VPN is a typical application that an LSP carries. An existing		L3VPN is a typical application. An existing solution (refer to
	solution (refer to Figure 2) for protecting L3VPN traffic against		Figure 2) for protecting L3VPN traffic against egress failure
	egress failure includes: 1) A multi-hop BFD session between ingress		includes: 1) A multi-hop BFD session between ingress R1 and egress L1
	R1 and egress L1 of primary LSP; 2) A backup LSP from ingress R1 to		of primary LSP; 2) A backup LSP from ingress R1 to backup egress La;
	backup egress La; 3) La sends R1 VPN backup label and related		3) La sends R1 VPN backup label and related information via BGP; 4)
	information via BGP; 4) R1 has a VRF with two sets of routes: one		R1 has a VRF with two sets of routes: one uses primary LSP and L1 as
	uses primary LSP and L1 as next hop; the other uses backup LSP and La		next hop; the other uses backup LSP and La as next hop.
	as next hop.
	CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP		CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP
	one VPN * : $ ---- Backup LSP		one VPN * : $ ---- Backup LSP
	* .................: $ .... BFD Session		* .................: $ .... BFD Session
	[R1] ..: [CE2] $ Link		[R1] ..: [CE2] $ Link
	$ \ $ $		$ \ $ $
	$ \ $		$ \ $
	[CE1] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label)		[CE1] [R4]-----[R5]-----[La](BGP sends R1 VPN backup label)
	Figure 2: Protect Egress for L3VPN Traffic		Figure 2: Protect Egress for L3VPN Traffic
	In normal operations, R1 sends the traffic from CE1 through primary		In normal operations, R1 sends the traffic from CE1 through primary
	LSP with VPN label received from L1 as inner label to L1, which		LSP with VPN label received from L1 as inner label to L1, which
	delivers the traffic to CE2 using VPN label.		delivers the traffic to CE2 using VPN label.
	When R1 detects a failure in L1, R1 sends the traffic from CE1 via		When R1 detects the failure of L1, R1 sends the traffic from CE1 via
	backup LSP with VPN bakup label received from La as inner label to		backup LSP with VPN backup label received from La as inner label to
	La, which delivers the traffic to CE2 using VPN backup label.		La, which delivers the traffic to CE2 using VPN backup label.
	A new solution (refer to Figure 3) with egress local protection for		A new solution (refer to Figure 3) with egress local protection for
	protecting L3VPN traffic includes: 1) A BFD session between R3 and		protecting L3VPN traffic includes: 1) A BFD session between R3 and
	egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress		egress L1 of primary LSP; 2) A backup LSP from R3 to backup egress
	La; 3) L1 sends La VPN label as UA label and related information via		La; 3) L1 sends La VPN label as UA label and related information; 4)
	BGP or another protocol; 4) L1 and La is virtualized as one from R1's		L1 and La is virtualized as one. This can be achieved by configuring
	point of view.		a same local address on L1 and La, using the address as a destination
			of the LSP and BGP next hop for VPN traffic.
	CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP		CE1,CE2 in [R2]*****[R3]*****[L1] **** Primary LSP
	one VPN * \ :.....: $ ---- Backup LSP		one VPN * \ :.....: $ ---- Backup LSP
	* \ $ .... BFD Session		* \ $ .... BFD Session
	[R1] \ [CE2] $ Link		[R1] \ [CE2] $ Link
	$ \ $ $		$ \ $ $
	$ \ $		$ \ $
	[CE1] [La](VPN label from L1 as UA label)		[CE1] [La](VPN label from L1 as UA label)
	Figure 3: Locally Protect Egress for L3VPN Traffic		Figure 3: Locally Protect Egress for L3VPN Traffic
	When R3 detects a failure in L1, R3 sends the traffic from primary		When R3 detects L1's failure, R3 sends the traffic from primary LSP
	LSP via backup LSP to La, which delivers the traffic to CE2 using VPN		via backup LSP to La, which delivers the traffic to CE2 using VPN
	label under the backup LSP label as a context label.		label as UA label under the backup LSP label as a context label.
	4.2. PLR Procedure for Applications		6.2. PLR Procedure for Applications
	When the PLR creates a backup LSP from itself to a backup egress for		When the PLR gets a backup LSP from itself to a backup egress for
	protecting a primary egress, it includes an EGRESS_BACKUP_SUB_LSP		protecting a primary egress of a primary LSP, it includes an
	object in the Path message for the LSP. The object contains the		EGRESS_BACKUP object in the Path message for the primary LSP. The
	primary egress and the backup egress and indicates that the backup		object contains the ID information of the backup LSP and indicates
	egress SHOULD consider the backup LSP label as a context label and		that the primary egress SHOULD send the backup egress the application
	the inner label as application traffic label when needed.		traffic label (e.g., VPN label) as UA label when needed.
	4.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 sends 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 upstream assigned		for protecting the primary egress the label as a UA label via BGP or
	label via BGP or another protocol. Exactly how the label is sent is		another protocol. Exactly how the label is sent is out of scope for
	out of scope for this document.		this document.
	When the backup egress receives a upstream assigned label from the
	primary egress, it adds a forwarding entry with the label into the
	LFIB for the primary egress. Using this entry, the backup egress
	delivers the traffic with this label as inner label from the backup
	LSP to the same destination as the primary egress.
	When the backup egress receives a packet from the backup LSP, it uses		When the backup egress receives a UA label from the primary egress,
	the top label as a context label to find the LFIB for the primary		it adds a forwarding entry with the label into the LFIB for the
	egress and the inner label to deliver the packet to the same		primary egress. When the backup egress receives a packet from the
	destination as the primary egress according to 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
			the same destination as the primary egress according to the LFIB.
	5. 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.
	6. IANA Considerations		8. IANA Considerations
	TBD		IANA considerations for new objects will be specified after the
			objects used are decided upon.
	7. 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		Zhenbin Li
	Huawei Technologies		Huawei Technologies
	Huawei Bld., No.156 Beiqing Rd.		Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
			Nan Meng
			Huawei Technologies
			Huawei Bld., No.156 Beiqing Rd.
			Beijing 100095
			China
			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
	8. Acknowledgement		10. Acknowledgement
	The authors would like to thank Richard Li, Tarek Saad, Lizhong Jin,		The authors would like to thank Richard Li, Tarek Saad, Lizhong Jin,
	Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Rob Rennison,		Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Rob Rennison,
	Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam and Quintin		Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam and Quintin
	Zhao for their valuable comments and suggestions on this draft.		Zhao for their valuable comments and suggestions on this draft.
	9. References		11. References
	9.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.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	skipping to change at page 13, line 43		skipping to change at page 14, line 5
	[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,		[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
	"Extensions to Resource Reservation Protocol - Traffic		"Extensions to Resource Reservation Protocol - Traffic
	Engineering (RSVP-TE) for Point-to-Multipoint TE Label		Engineering (RSVP-TE) for Point-to-Multipoint TE Label
	Switched Paths (LSPs)", RFC 4875, May 2007.		Switched Paths (LSPs)", RFC 4875, May 2007.
	[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream		[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
	Label Assignment and Context-Specific Label Space",		Label Assignment and Context-Specific Label Space",
	RFC 5331, August 2008.		RFC 5331, August 2008.
			[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
			Local Addresses in OSPF Traffic Engineering (TE)
			Extensions", RFC 5786, March 2010.
	[P2MP FRR]		[P2MP FRR]
	Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux,		Le Roux, J., Aggarwal, R., Vasseur, J., and M. Vigoureux,
	"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",		"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels",
	draft-leroux-mpls-p2mp-te-bypass , March 1997.		draft-leroux-mpls-p2mp-te-bypass , March 1997.
	9.2. Informative References		11.2. Informative References
	[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-		[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
	Multipoint Traffic-Engineered MPLS Label Switched Paths		Multipoint Traffic-Engineered MPLS Label Switched Paths
	(LSPs)", RFC 4461, April 2006.		(LSPs)", RFC 4461, April 2006.
	Authors' Addresses		Authors' Addresses
	Huaimo Chen		Huaimo Chen
	Huawei Technologies		Huawei Technologies
	Boston, MA		Boston, MA
End of changes. 84 change blocks.
	276 lines changed or deleted		305 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/