draft-ietf-teas-p2mp-loose-path-reopt-08.txt		draft-ietf-teas-p2mp-loose-path-reopt-09.txt
	TEAS Working Group T. Saad, Ed.		TEAS Working Group T. Saad, Ed.
	Internet-Draft R. Gandhi, Ed.		Internet-Draft R. Gandhi, Ed.
	Intended status: Standards Track Z. Ali		Intended status: Standards Track Z. Ali
	Expires: June 11, 2017 Cisco Systems, Inc.		Expires: August 6, 2017 Cisco Systems, Inc.
	R. Venator		R. Venator
	Defense Information Systems Agency		Defense Information Systems Agency
	Y. Kamite		Y. Kamite
	NTT Communications Corporation		NTT Communications Corporation
	December 8, 2016		February 2, 2017
	RSVP Extensions For Re-optimization of Loosely Routed		RSVP Extensions For Re-optimization of Loosely Routed
	Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)		Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
	draft-ietf-teas-p2mp-loose-path-reopt-08		draft-ietf-teas-p2mp-loose-path-reopt-09
	Abstract		Abstract
	Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered		Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered
	(TE) Label Switched Path (LSP) may be triggered based on the need to		(TE) Label Switched Path (LSP) may be triggered based on the need to
	re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of		re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of
	S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or		S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or
	the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method.		the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method.
	This document discusses the application of the existing mechanisms		This document discusses the application of the existing mechanisms
	for path re-optimization of loosely routed Point-to-Point (P2P) TE		for path re-optimization of loosely routed Point-to-Point (P2P) TE
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	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."
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4		2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 6		3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 6
	3.2. Existing Mechanism For Tree-Based P2MP-TE LSP		3.2. Existing Mechanism For Tree-Based P2MP-TE LSP
	Re-optimization . . . . . . . . . . . . . . . . . . . . . 7		Re-optimization . . . . . . . . . . . . . . . . . . . . . 6
	3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP		3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP
	Re-optimization . . . . . . . . . . . . . . . . . . . . . 8		Re-optimization . . . . . . . . . . . . . . . . . . . . . 7
	4. Signaling Extensions For Loosely Routed P2MP-TE LSP		4. Signaling Extensions For Loosely Routed P2MP-TE LSP
	Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 9		Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 9		4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8
	4.2. Sub-Group-Based Re-optimization Using Fragment		4.2. Sub-Group-Based Re-optimization Using Fragment
	Identifier . . . . . . . . . . . . . . . . . . . . . . . . 10		Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Message and Object Definitions . . . . . . . . . . . . . . . . 11		5. Message and Object Definitions . . . . . . . . . . . . . . . . 11
	5.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11		5.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11
	5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 11		5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 11
	5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 12		5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11
	6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 13		7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 13
	7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 14		7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 13
	7.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 14		7.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	2.2. Abbreviations		2.2. Abbreviations
	ABR: Area Border Router.		ABR: Area Border Router.
	AS: Autonomous System.		AS: Autonomous System.
	ERO: Explicit Route Object.		ERO: Explicit Route Object.
	LSR: Label Switching Router.		LSR: Label Switching Router.
			S2L sub-LSP: Source-to-leaf sub Label Switched Path.
	TE LSP: Traffic Engineering Label Switched Path.		TE LSP: Traffic Engineering Label Switched Path.
	TE LSP ingress: Head-end/source node of the TE LSP.		TE LSP ingress: Head-end/source node of the TE LSP.
	TE LSP egress: Tail-end/destination node of the TE LSP.		TE LSP egress: Tail-end/destination node of the TE LSP.
	2.3. Terminology		2.3. Terminology
	Domain: Routing or administrative domain such as an IGP area and an
	autonomous system.
	Interior Gateway Protocol Area (IGP Area): OSPF area or IS-IS level.
	Inter-area TE LSP: A TE LSP whose path transits across at least two
	different IGP areas.
	Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least
	two different Autonomous Systems (ASes) or sub-ASes (BGP
	confederations).
	S2L sub-LSP: Source-to-leaf sub Label Switched Path.
	The reader is assumed to be familiar with the terminology in		The reader is assumed to be familiar with the terminology in
	[RFC4875] and [RFC4736].		[RFC4736] and [RFC4875].
	3. Overview		3. Overview
	[RFC4736] defines RSVP signaling extensions for re-optimizing loosely		[RFC4736] defines RSVP signaling extensions for re-optimizing loosely
	routed P2P TE LSPs as follows:		routed P2P TE LSPs as follows:
	o A mid-point LSR that expands loose next-hop(s) sends a solicited		o A mid-point LSR that expands loose next-hop(s) sends a solicited
	or unsolicited PathErr with the Notify error code 25 (as defined		or unsolicited PathErr with the Notify error code 25 (as defined
	in [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists"		in [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists"
	to the ingress node.		to the ingress node.
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 33 ¶
	path(s) MUST propagate the request downstream by setting the		path(s) MUST propagate the request downstream by setting the
	"P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES		"P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES
	Object of the RSVP Path message.		Object of the RSVP Path message.
	A mid-point LSR MAY send an unsolicited PathErr with the Notify error		A mid-point LSR MAY send an unsolicited PathErr with the Notify error
	code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress		code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress
	node to notify of a preferred P2MP-TE LSP tree when it determines it		node to notify of a preferred P2MP-TE LSP tree when it determines it
	exists. In this case, the mid-point LSR that expands loose next-		exists. In this case, the mid-point LSR that expands loose next-
	hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L		hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L
	sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to		sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to
	the ingress node.		the ingress node. The mid-point LSR SHOULD consider how frequently
			it chooses to send such a PathErr - considering both that a PathErr
			may be lost on its transit to the ingress node and that the ingress
			node may choose not to re-optimize the LSP when such a PathErr is
			received.
	The sending of an RSVP PathErr with the Notify error code and		The sending of an RSVP PathErr with the Notify error code and
	"Preferable P2MP-TE Tree Exists" sub-code to the ingress node		"Preferable P2MP-TE Tree Exists" sub-code to the ingress node
	notifies the ingress node of the existence of a preferable P2MP-TE		notifies the ingress node of the existence of a preferable P2MP-TE
	LSP tree and upon receiving this PathErr, the ingress node MUST		LSP tree and upon receiving this PathErr, the ingress node SHOULD
	trigger re-optimization of the LSP using the MBB method with a		trigger re-optimization of the LSP using the MBB method with a
	different LSP-ID.		different LSP-ID.
	4.2. Sub-Group-Based Re-optimization Using Fragment Identifier		4.2. Sub-Group-Based Re-optimization Using Fragment Identifier
	It might be preferable, as per [RFC4875], to re-optimize the entire		It might be preferable, as per [RFC4875], to re-optimize the entire
	P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1,		P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1,
	"Make-before-Break") or to re-optimize individual or group of S2L		"Make-before-Break") or to re-optimize individual or group of S2L
	sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2		sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2
	"Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same		"Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same
	skipping to change at page 13, line 43 ¶		skipping to change at page 13, line 35 ¶
	http://www.iana.org/assignments/rsvp-te-parameters). From the		http://www.iana.org/assignments/rsvp-te-parameters). From the
	registries in this name space "Attribute Flags", allocation of new		registries in this name space "Attribute Flags", allocation of new
	flag is requested (Section 5.1).		flag is requested (Section 5.1).
	The following new flag is defined for the Attributes Flags TLV in the		The following new flag is defined for the Attributes Flags TLV in the
	LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned		LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned
	by IANA.		by IANA.
	o P2MP-TE Tree Re-evaluation Request Flag:		o P2MP-TE Tree Re-evaluation Request Flag:
	+--------+---------------+---------+---------+---------+------------+		+--------+---------------+---------+---------+---------+-----------+
	| Bit No | Attribute | Carried | Carried | Carried | Reference |		| Bit No | Attribute | Carried | Carried | Carried | Reference |
	| | Flag Name | in Path | in Resv | in RRO | |		| | Flag Name | in Path | in Resv | in RRO | |
	+--------+---------------+---------+---------+---------+------------+		| | | | | or ERO | |
	| TBA1 by| P2MP-TE Tree | Yes | No | No | This |		+--------+---------------+---------+---------+---------+-----------+
	| IANA | Re-evaluation | | | | document |		| TBA1 by| P2MP-TE Tree | Yes | No | No | This |
	+--------+---------------+---------+---------+---------+------------+		| IANA | Re-evaluation | | | | document |
			+--------+---------------+---------+---------+---------+-----------+
	7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code		7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code
	IANA maintains a name space for RSVP protocol parameters "Resource		IANA maintains a name space for RSVP protocol parameters "Resource
	Reservation Protocol (RSVP) Parameters" (see		Reservation Protocol (RSVP) Parameters" (see
	http://www.iana.org/assignments/rsvp-parameters). From the		http://www.iana.org/assignments/rsvp-parameters). From the
	sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes		sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes
	and Globally-Defined Error Value Sub-Codes", allocation of a new		and Globally-Defined Error Value Sub-Codes", allocation of a new
	error code is requested (Section 5.2).		error code is requested (Section 5.2).
End of changes. 16 change blocks.
	36 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/