< draft-ietf-pwe3-mspw-er-05.txt		draft-ietf-pwe3-mspw-er-06.txt >
	Network Working Group P. Dutta		Network Working Group P. Dutta
	Internet-Draft M. Bocci		Internet-Draft M. Bocci
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: February 8, 2015 L. Martini		Expires: March 14, 2015 L. Martini
	Cisco Systems		Cisco Systems
	August 7, 2014		September 10, 2014
	Explicit Path Routing for Dynamic Multi-Segment Pseudowires		Explicit Path Routing for Dynamic Multi-Segment Pseudowires
	draft-ietf-pwe3-mspw-er-05		draft-ietf-pwe3-mspw-er-06
	Abstract		Abstract
	Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit		Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit
	path may be required to provide a simple solution for 1:1 protection		path may be required to provide a simple solution for 1:1 protection
	with diverse primary and backup MS-PWs for a service, or to enable		with diverse primary and backup MS-PWs for a service, or to enable
	controlled signaling (strict or loose) for special MS-PWs. This		controlled signaling (strict or loose) for special MS-PWs. This
	document specifies the extensions and procedures required to enable		document specifies the extensions and procedures required to enable
	dynamic MS-PWs to be established along explicit paths.		dynamic MS-PWs to be established along explicit paths.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 February 8, 2015.		This Internet-Draft will expire on March 14, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	3.3. Explicit Route Hop TLV (ER-Hop TLV) . . . . . . . . . . . 4		3.3. Explicit Route Hop TLV (ER-Hop TLV) . . . . . . . . . . . 4
	3.4. ER-Hop Semantics . . . . . . . . . . . . . . . . . . . . 4		3.4. ER-Hop Semantics . . . . . . . . . . . . . . . . . . . . 4
	3.4.1. ER-Hop Type: IPv4 Prefix . . . . . . . . . . . . . . 4		3.4.1. ER-Hop Type: IPv4 Prefix . . . . . . . . . . . . . . 4
	3.4.2. ER-Hop Type: IPv6 Prefix . . . . . . . . . . . . . . 4		3.4.2. ER-Hop Type: IPv6 Prefix . . . . . . . . . . . . . . 4
	3.4.3. ER-Hop Type: L2 PW Address . . . . . . . . . . . . . 4		3.4.3. ER-Hop Type: L2 PW Address . . . . . . . . . . . . . 4
	4. Explicit Route TLV Processing . . . . . . . . . . . . . . . . 6		4. Explicit Route TLV Processing . . . . . . . . . . . . . . . . 6
	4.1. Next-Hop Selection . . . . . . . . . . . . . . . . . . . 6		4.1. Next-Hop Selection . . . . . . . . . . . . . . . . . . . 6
	4.2. Adding ER Hops to the Explicit Route TLV . . . . . . . . 7		4.2. Adding ER Hops to the Explicit Route TLV . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. Normative References . . . . . . . . . . . . . . . . . . . . 8		8. Normative References . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Procedures for dynamically establishing multi-segment pseudowires		Procedures for dynamically establishing multi-segment pseudowires
	(MS-PWs), where their paths are automatically determined using a		(MS-PWs), where their paths are automatically determined using a
	dynamic routing protocol, are defined in [RFC7267]. For 1:1		dynamic routing protocol, are defined in [RFC7267]. For 1:1
	protection of MS-PWs with primary and backup paths, MS-PWs need to be		protection of MS-PWs with primary and backup paths, MS-PWs need to be
	established through a diverse set of S-PEs (Switching Provider-Edges)		established through a diverse set of S-PEs (Switching Provider-Edges)
	to avoid any single points of failure at the PW level. [RFC7267]		to avoid any single points of failure at the PW level. [RFC7267]
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	An S-PE that is capable of dynamic MS-PW signaling, but has not been		An S-PE that is capable of dynamic MS-PW signaling, but has not been
	assigned an S-PE address, and that receives a Label Mapping message		assigned an S-PE address, and that receives a Label Mapping message
	for a dynamic MS-PW MUST follow the procedures of [RFC7267]		for a dynamic MS-PW MUST follow the procedures of [RFC7267]
	Section 3.2.		Section 3.2.
	3.2. Explicit Route TLV (ER-TLV)		3.2. Explicit Route TLV (ER-TLV)
	The ER-TLV specifies the path to be taken by the MS-PW being		The ER-TLV specifies the path to be taken by the MS-PW being
	established. Each hop along the path is represented by an abstract		established. Each hop along the path is represented by an abstract
	node, which is a group of one or more S-PEs, identified by an IPv4,		node, which is a group of one or more S-PEs, identified by an IPv4,
	and IPv6 or an S-PE address. The ER-TLV format is as per Section 4.1		an IPv6 or an S-PE address. The ER-TLV format is as per Section 4.1
	of [RFC3212].		of [RFC3212].
	The ER-TLV contains one or more Explicit Route Hop TLVs (ER-Hop TLVs)		The ER-TLV contains one or more Explicit Route Hop TLVs (ER-Hop TLVs)
	defined in Section 3.3.		defined in Section 3.3.
	3.3. Explicit Route Hop TLV (ER-Hop TLV)		3.3. Explicit Route Hop TLV (ER-Hop TLV)
	The contents of an ER-TLV are a series of variable length ER-Hop		The contents of an ER-TLV are a series of variable length ER-Hop
	TLVs. Each hop contains the identification of an "Abstract Node"		TLVs. Each hop contains the identification of an "Abstract Node"
	that represents the hop to be traversed. The ER-Hop TLV format is as		that represents the hop to be traversed. The ER-Hop TLV format is as
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	All other fields (AII Type, Length, Global ID, Prefix, and AC ID)		All other fields (AII Type, Length, Global ID, Prefix, and AC ID)
	define the L2 PW Address and are to be set and interpreted as		define the L2 PW Address and are to be set and interpreted as
	defined in Section 3.2 of [RFC5003].		defined in Section 3.2 of [RFC5003].
	4. Explicit Route TLV Processing		4. Explicit Route TLV Processing
	4.1. Next-Hop Selection		4.1. Next-Hop Selection
	A PW Label Mapping Message containing an explicit route TLV specifies		A PW Label Mapping Message containing an explicit route TLV specifies
	the next hop for a given MS-PW path. Selection of this next hop may		the next hop for a given MS-PW path. Selection of this next hop by
	involve a selection from a set of possible alternatives. The		the ST-PE or S-PE inserting the ER Hop TLV may involve a selection
	mechanism for making a selection from this set is implementation		from a set of possible alternatives. The mechanism for making a
	specific and is outside of the scope of this document. The mechanism		selection from this set is implementation specific and is outside of
	used to select a particular path is also outside of the scope of this		the scope of this document. The mechanism used to select a
	document, but each node MUST attempt to determine a loop-free path.		particular path is also outside of the scope of this document, but
	A noted in Section 1, in many deployments the ST-PE will not have a		each node MUST determine a loop-free path if it is to signal the MS-
			PW. [RFC6073] Section 7.6 provides a mechanism by which a node can
			check that the path taken by an MS-PW does not include loops.
			As noted in Section 1, in many deployments the ST-PE will not have a
	view of the topology of S-PEs and so the path will need to be		view of the topology of S-PEs and so the path will need to be
	supplied from a management application.		supplied from a management application.
	If a loop free path cannot be found, then a node MUST NOT attempt to		If a loop free path cannot be found by an ST-PE or S-PE, then a node
	signal the MS-PW. For an S-PE, if it cannot determine a loop free		MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot
	path, then the received Label Mapping MUST be released with a status		determine a loop free path, then the received Label Mapping MUST be
	code of "PW Loop Detected" as per Section 4.2.3 of [RFC7267].		released with a status code of "PW Loop Detected" as per
			Section 4.2.3 of [RFC7267].
	To determine the next hop for the MS-PW path, a node performs the		To determine the next hop for the MS-PW path, a node performs the
	following steps. Note that these procedures assume that a valid S-PE		following steps. Note that these procedures assume that a valid S-PE
	address has been assigned to the node, as per Section 3.1, above.		address has been assigned to the node, as per Section 3.1, above.
	1. The node receiving the Label Mapping Message that contains an ER-		1. The node receiving the Label Mapping Message that contains an ER-
	TLV MUST evaluate the first ER Hop. If the L bit is not set in		TLV MUST evaluate the first ER Hop. If the L bit is not set in
	the first ER Hop and if the node is not part of the abstract node		the first ER Hop and if the node is not part of the abstract node
	described by the first ER Hop (i.e it does not lie within the		described by the first ER Hop (i.e it does not lie within the
	prefix as determined by the prefix length specified in the ER-Hop		prefix as determined by the prefix length specified in the ER-Hop
	TLV), it has received the message in error, and MUST reply with a		TLV), it has received the message in error. Therefore, the node
	Label Release Message with a "Bad Initial ER Hop Error"		MUST reply with a Label Release Message with a "Bad Initial ER
	(0x04000004) status code. If the L bit is set and the local node		Hop Error" (0x04000004) status code. If the L bit is set and the
	is not part of the abstract node described by the first ER Hop,		local node is not part of the abstract node described by the
	the node selects a next hop that is along the path to the		first ER Hop, the node selects a next hop that is along the path
	abstract node described by the first ER Hop. If there is no ER-		to the abstract node described by the first ER Hop. If there is
	Hop TLV contained in the ER-TLV, the message is also in error and		no ER-Hop TLV contained in the ER-TLV, the message is also in
	the node should return a "Bad Explicit Routing TLV Error"		error and the node SHOULD return a "Bad Explicit Routing TLV
	(0x04000001) status code in a Label Release Message sent to		Error" (0x04000001) status code in a Label Release Message sent
	upstream node. Note that this statement does not preclude a		to upstream node. Note that this statement does not preclude a
	Label mapping message with no ER-TLV. If a Label Mapping message		Label mapping message with no ER-TLV. If a Label Mapping message
	with no ER-TLV is received, then it MUST be processed as per		with no ER-TLV is received, then it MUST be processed as per
	[RFC7267].		[RFC7267].
	2. If there are no further ER-Hop TLVs following the first ER-Hop		2. If there are no further ER-Hop TLVs following the first ER-Hop
	TLV, this indicates the end of the explicit route. The Explicit		TLV, this indicates the end of the explicit route. The Explicit
	Route TLV MUST be removed from the Label Mapping message. This		Route TLV MUST be removed from the Label Mapping message. This
	node may or may not be the end of the PW. Processing continues		node may or may not be the end of the PW. Processing continues
	as per Section 4.2, where a new explicit route TLV MAY be added		as per Section 4.2, where a new explicit route TLV MAY be added
	to the Label Mapping Message.		to the Label Mapping Message.
	3. If a second ER Hop TV does exist, and the node is also a part of		3. If a second ER Hop TLV does exist, and the node is also a part of
	the abstract node described by the second ER-Hop, then the node		the abstract node described by the second ER-Hop, then the node
	deletes the first ER-Hop and continues processing with step 2,		deletes the first ER-Hop and continues processing with step 2,
	above. Note that this makes the second ER Hop into the first ER		above. Note that this makes the second ER Hop into the first ER
	Hop for the iteration for the next PW segment.		Hop for the iteration for the next PW segment.
	4. The node determines if it is topologically adjacent to the		4. The node determines if it is topologically adjacent to the
	abstract node described by the second ER Hop. That is, it is		abstract node described by the second ER Hop. That is, it is
	directly connected to the next node by a PW control plane		directly connected to the next node by a PW control plane
	adjacency. If so, the node selects a particular next hop which		adjacency. If so, the node selects a particular next hop which
	is a member of the abstract node. The node then deletes the		is a member of the abstract node. The node then deletes the
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 50 ¶
	6. Finally, the node replaces the first ER Hop with any ER Hop that		6. Finally, the node replaces the first ER Hop with any ER Hop that
	denotes an abstract node containing the next hop. This is		denotes an abstract node containing the next hop. This is
	necessary so that when the explicit route is received by the next		necessary so that when the explicit route is received by the next
	hop, it will be accepted.		hop, it will be accepted.
	7. Progress the Label Mapping Message to the next hop.		7. Progress the Label Mapping Message to the next hop.
	4.2. Adding ER Hops to the Explicit Route TLV		4.2. Adding ER Hops to the Explicit Route TLV
	After selecting a next hop, the node may alter the explicit route in		After selecting a next hop, the node MAY alter the explicit route in
	the following ways.		the following ways.
	If, as part of executing the algorithm in Section 4.1, the explicit		If, as part of executing the algorithm in Section 4.1, the explicit
	route TLV is removed, the node may add a new explicit route TLV.		route TLV is removed, the node MAY add a new explicit route TLV.
	Otherwise, if the node is a member of the abstract node for the first		Otherwise, if the node is a member of the abstract node for the first
	ER-Hop, then a series of ER Hops may be inserted before the First ER		ER-Hop, then a series of ER Hops MAY be inserted before the First ER
	Hop or may replace the first ER Hop. Each ER Hop in this series must		Hop or the first ER Hop MAY be replaced. Each ER Hop in this series
	denote an abstract node that is a subset of the current abstract		MUST denote an abstract node that is a subset of the current abstract
	node.		node.
	Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary		Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary
	series of ER Hops may be inserted prior to the first ER-Hop.		series of ER Hops MAY be inserted prior to the first ER-Hop.
	5. IANA Considerations		5. IANA Considerations
	RFC5036 [RFC5036] defines the LDP TLV name space which is maintained		RFC5036 [RFC5036] defines the LDP TLV name space which is maintained
	by IANA as "LDP TLV Registry". TLV types for the Explicit Route TLV,		by IANA as "LDP TLV Registry". TLV types for the Explicit Route TLV,
	IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already		IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already
	defined in the LDP TLV Registry.		defined in the LDP TLV Registry.
	IANA is requested to assign a further code point from the IETF		IANA is requested to assign a further code point from the IETF
	consesus portion of this registry as follows:		consensus portion of this registry as follows:
	TLV Type Value Reference		TLV Type Value Reference
	------------------------------------ -------- ---------		------------------------------------ -------- ---------
	L2 PW Address of Switching Point TBD This Document		L2 PW Address of Switching Point TBD This Document
	A value of 0x0805 is requested.		A value of 0x0805 is requested.
	6. Security Considerations		6. Security Considerations
	This document introduces no new security considerations over		This document introduces no new security considerations over
	[RFC5036], [RFC4447] and [RFC7267]. The security considerations		[RFC5036], [RFC4447] and [RFC7267]. The security considerations
	detailed in those documents apply to the protocol extensions		detailed in those documents apply to the protocol extensions
	described in this RFC.		described in this RFC.
			As with [RFC7267], it should be noted that the path selection
			mechanisms specified in this document enable the network to
			automatically select the S-PEs that are used to forward packets on
			the MS-PW. Appropriate tools, such as the Virtual Circuit
			Connectivity Verification (VCCV) trace mechanisms specified in
			[RFC6073], can be used by an operator of the network to verify the
			path taken by the MS-PW and therefore be satisfied that the path does
			not represent an additional security risk.
	7. Acknowledgements		7. Acknowledgements
	The authors gratefully acknowledge the contribution of the [RFC3212]		The authors gratefully acknowledge the contribution of the
	RFC3212 authors through the specification of TLVs, which are reused		RFC3212[RFC3212] authors through the specification of TLVs, which are
	by this document. The authors also gratefully acknowledge the input		reused by this document. The authors also gratefully acknowledge the
	of Lizhong Jin.		input of Lizhong Jin.
	8. Normative References		8. 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.
	[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,		[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
	L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,		L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
	Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.		Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
	Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,		Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 34 ¶
	Heron, "Pseudowire Setup and Maintenance Using the Label		Heron, "Pseudowire Setup and Maintenance Using the Label
	Distribution Protocol (LDP)", RFC 4447, April 2006.		Distribution Protocol (LDP)", RFC 4447, April 2006.
	[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,		[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
	"Attachment Individual Identifier (AII) Types for		"Attachment Individual Identifier (AII) Types for
	Aggregation", RFC 5003, September 2007.		Aggregation", RFC 5003, September 2007.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
			[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
			Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
	[RFC7267] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement		[RFC7267] Martini, L., Bocci, M., and F. Balus, "Dynamic Placement
	of Multi-Segment Pseudowires", RFC 7267, June 2014.		of Multi-Segment Pseudowires", RFC 7267, June 2014.
	Authors' Addresses		Authors' Addresses
	Pranjal Kumar Dutta		Pranjal Kumar Dutta
	Alcatel-Lucent		Alcatel-Lucent
	701 E Middlefield Road		701 E Middlefield Road
	Mountain View, California 94043		Mountain View, California 94043
	USA		USA
End of changes. 18 change blocks.
	40 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/