< draft-brissette-pals-pw-fec-label-request-00.txt		draft-brissette-pals-pw-fec-label-request-01.txt >
	PALS Working Group Patrice Brissette		PALS Working Group Patrice Brissette
	Internet Draft Kamran Raza		Internet Draft Kamran Raza
	Intended Status: Proposed Standard Sami Boutros		Intended Status: Proposed Standard Sami Boutros
	Expires: April 26, 2015 Cisco Systems, Inc.		Expires: April 26, 2015 Cisco Systems, Inc.
	Nick Del Regno		Nick Del Regno
	Matthew Turlington		Matthew Turlington
	Verizon		Verizon
	October 23, 2014		June 29, 2015
	Handling Incoming Label Request for PW FEC Types		Handling Incoming Label Request for PW FEC Types
	draft-brissette-pals-pw-fec-label-request-00		draft-brissette-pals-pw-fec-label-request-01
	Abstract		Abstract
	This document clarifies the behavior of an LSR PE upon receiving an		This document clarifies the behavior of an LSR PE upon receiving an
	LDP Label Request message for Pseudowire (PW) FEC types. Furthermore,		LDP Label Request message for Pseudowire (PW) FEC types. Furthermore,
	this document specifies the procedures to be followed by the LSR PE		this document specifies the procedures to be followed by the LSR PE
	in order to answer such requests for a given PW FEC type.		in order to answer such requests for a given PW FEC type.
	Status of this Memo		Status of this Memo
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	Convention		Convention
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1 PWid FEC (FEC128) . . . . . . . . . . . . . . . . . . . . . 4		3.1 PWid FEC (FEC128) . . . . . . . . . . . . . . . . . . . . . 5
	3.2 Generalized PWid FEC (FEC129): . . . . . . . . . . . . . . . 5		3.2 Generalized PWid FEC (FEC129): . . . . . . . . . . . . . . . 5
	3.3 P2MP PW Upstream FEC (FEC130): . . . . . . . . . . . . . . . 5		3.3 Common to PWid and Generalized PWid FEC . . . . . . . . . . 5
	3.4 P2MP PW Downstream FEC (FEC132): . . . . . . . . . . . . . . 5		3.4 P2MP PW Upstream FEC (FEC130): . . . . . . . . . . . . . . . 5
			3.5 P2MP PW Downstream FEC (FEC132): . . . . . . . . . . . . . . 5
	3.5 PW Typed Wildcard FEC . . . . . . . . . . . . . . . . . . . 5		3.5 PW Typed Wildcard FEC . . . . . . . . . . . . . . . . . . . 5
	4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5		4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
	5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5		5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	6.1 Normative References . . . . . . . . . . . . . . . . . . . 6		7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.2 Informative References . . . . . . . . . . . . . . . . . . 6		7.1 Normative References . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		7.2 Informative References . . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	1 Introduction		1 Introduction
	Label Distribution Protocol (LDP) base specification [RFC5036]		Label Distribution Protocol (LDP) base specification [RFC5036]
	defines different LDP message types and their procedures for		defines different LDP message types and their procedures for
	advertising label bindings. These procedures are generic and		advertising label bindings. These procedures are generic and
	inherited by any FEC type that is advertised using these message		inherited by any FEC type that is advertised using these message
	types. For a given FEC type, any difference in behavior, compared to		types. For a given FEC type, any difference in behavior, compared to
	what is already specified in RFC 5036, needs to be spelled out		what is already specified in RFC 5036, needs to be spelled out
	clearly in the corresponding specification in which the FEC type is		clearly in the corresponding specification in which the FEC type is
	being introduced or extended.		being introduced or extended.
	[RFC4447] specifies mechanisms to setup pseudowires (PWs) using LDP.		[RFC4447] specifies mechanisms to setup pseudowires (PWs) using LDP.
	RFC 4447 does not specify any behavior change with regards to label		[RFC4447] does not specify any behavior change with regards to label
	binding distribution for PW FEC types in response to a corresponding		binding distribution for PW FEC types in response to a corresponding
	Label Request message from a peer LSR PE. This implies that RFC 4447		Label Request message from a peer LSR PE. This implies that [RFC4447]
	inherits the base procedures defined in RFC 5036 for Label Request		inherits the base procedures defined in [RFC5036] for Label Request
	and associated response for a PW FEC type. The lack of specification		and associated response for a PW FEC type. The lack of specification
	in the area of Label Request in RFC 4447 has led to some		in the area of Label Request in [RFC4447] has led to some
	interoperability issues between vendors due to different		interoperability issues between vendors due to different
	interpretation. For example, there are some implementations which do		interpretation. For example, there are some implementations which do
	not honor and do not respond to an incoming Label Request for a PW		not honor and do not respond to an incoming Label Request for a PW
	FEC type, resulting in functionality impact. Some of these problems		FEC type, resulting in functionality impact. Some of these problems
	are very critical for the deployment of PW technologies. The		are very critical for the deployment of PW technologies. The
	following is a non-exhaustive list of some of the problems and		following is a non-exhaustive list of some of the problems and
	potential breakages that may result due to the lack of support of		potential breakages that may result due to the lack of support of
	incoming Label Request for a PW FEC:		incoming Label Request for a PW FEC:
	- An LSR PE can not restart forwarding of packet with sequence		- An LSR PE can not restart forwarding of packet with sequence
	number 1 as specified in section 6.4.2 of RFC 4447 with regards		number 1 as specified in section 4.1 of [RFC4385] with regards
	to Control Word Sequencing.		to Control Word Sequencing.
	- An LSR PE may not be able to perform a PW consistency check as		- An LSR PE may not be able to perform a PW consistency check as
	defined in section 4.1 of [RFC6667], resulting in LSR PEs		defined in section 4.1 of [RFC6667], resulting in LSR PEs
	becoming out-of-sync.		becoming out-of-sync.
	- Some implementations of LSR PE do not checkpoint PW label		- Some implementations of LSR PE do not checkpoint PW label
	bindings learnt from peer(s) in their persistent memory and		bindings learnt from peer(s) in their persistent memory and
	hence are not able to recover any peer state after their own		hence are not able to recover any peer state after their own
	restarts or switchovers. Such implementations typically require		restarts or switchovers. Such implementations typically require
	skipping to change at page 4, line 6 ¶		skipping to change at page 4, line 6 ¶
	and rely on Label Request mechanisms.		and rely on Label Request mechanisms.
	- The combination of Downstream Unsolicited mode and Conservative		- The combination of Downstream Unsolicited mode and Conservative
	Label retention (used due to memory limitations) can lead		Label retention (used due to memory limitations) can lead
	to a situation where an LSR PE releases the label learnt from a		to a situation where an LSR PE releases the label learnt from a
	peer for a PW that it may need later. Label Request is used to		peer for a PW that it may need later. Label Request is used to
	solve this issue. For example, consider an LSR PE operating in		solve this issue. For example, consider an LSR PE operating in
	Label Conservative mode receiving a label binding for a		Label Conservative mode receiving a label binding for a
	non-locally configured/known PW. This LSR PE ignores such a		non-locally configured/known PW. This LSR PE ignores such a
	label binding and later tries to re-learn it via Label Request		label binding and later tries to re-learn it via Label Request
	procedure once PW is locally configured.		procedure once PW is locally configured. The authors will like
			to remind the readers about the following fact: [RFC4447] does
			not mandate to use Label Liberal mode. Therefore it is possible
			that some implementation used Label Conservative mode.
	This document clarifies the use of Label Request message and its		This document clarifies the use of Label Request message and its
	procedures for PW FEC types and re-enforces the acceptable behavior		procedures for PW FEC types and re-enforces the acceptable behavior
	to be implemented by an LSR PE.		to be implemented by an LSR PE.
	3. Recommendation		2. Requirements
	This document recommends the following action to be implemented by an		This document recommends the following action to be implemented by an
	LSR PE that supports a PW FEC Type (P2P or P2MP type):		LSR PE that supports a PW FEC Type (P2P or P2MP type):
	- An LSR PE SHOULD respond to an incoming Label Request message		- An LSR PE MUST respond to an incoming Label Request message
	for a PW FEC by sending its local binding for the PW via a		for a PW FEC by sending its local binding for the PW via a
	Label Mapping message. If no such binding is available, the		Label Mapping message. If no such binding is available, the
	LSR PE SHOULD respond by sending a new status code "No PW"		LSR PE SHOULD respond by sending a new status code "No PW"
	in a Notification message.		in a Notification message.
	- An LSR PE SHOULD respond to an incoming Label Request message		- An LSR PE MUST respond to an incoming Label Request message
	for a Wildcard FEC [RFC5036] by sending its local bindings for		for a Wildcard FEC [RFC5036] by sending its local bindings for
	all its PWs via Label Mapping messages. This is in addition to		all its PWs via Label Mapping messages. This is in addition to
	label bindings corresponding to any other LDP FEC types		label bindings corresponding to any other LDP FEC types
	configured and available at the LSR.		configured and available at the LSR.
	- An LSR PE SHOULD respond to an incoming Label Request message		- An LSR PE MUST respond to an incoming Label Request message
	for a Typed Wildcard PW FEC [RFC6667] by sending its local		for a Typed Wildcard PW FEC [RFC6667] by sending its local
	bindings for all its PWs for the given FEC type via Label		bindings for all its PWs for the given FEC type via Label
	Mapping messages. For a given PW FEC type, this advertisement		Mapping messages. For a given PW FEC type, this advertisement
	is to be scoped either for a specific PW type or for all		is to be scoped either for a specific PW type or for all
	PW types according to the received PW Typed Wildcard FEC.		PW types according to the received PW Typed Wildcard FEC.
	3. Procedures		3. Procedures
	This document re-enforces the Label Request generic procedures, as		This document re-enforces the Label Request generic procedures, as
	defined by RFC 5036, for PW FEC types, and hence strongly recommends		defined by RFC 5036, for PW FEC types, and hence strongly recommends
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 6 ¶
	that an LSR PE receiving the PW Label Request message should respond		that an LSR PE receiving the PW Label Request message should respond
	either by sending its label binding in Label Mapping message(s) or		either by sending its label binding in Label Mapping message(s) or
	with a Notification message indicating why it cannot satisfy the		with a Notification message indicating why it cannot satisfy the
	request.		request.
	An LSR PE should respond to a Label Request when corresponding PW FEC		An LSR PE should respond to a Label Request when corresponding PW FEC
	is resolved locally. The following sub sections define the meaning of		is resolved locally. The following sub sections define the meaning of
	a "resolution" for a given PW FEC type.		a "resolution" for a given PW FEC type.
	3.1 PWid FEC (FEC128)		3.1 PWid FEC (FEC128)
	A PWid FEC is resolved when a local label binding has been allocated		A PWid FEC is resolved when a local label binding has been allocated
	after local configuration application.		after local configuration application.
			[RFC6073] does not preclude setting up MS-PWs using FEC-128,
			therefore this procedure is also applicable to PEs acting as S-PEs.
	3.2 Generalized PWid FEC (FEC129):		3.2 Generalized PWid FEC (FEC129):
	A Generalized PWid FEC is resolved at an ST-PE when SAII is locally		A Generalized PWid FEC is resolved at an ST-PE when SAII is locally
	configured, TAII is learnt statically or dynamically via discovery		configured, TAII is learnt statically or dynamically via discovery
	mechanisms, and a local label binding has been allocated.		mechanisms, and a local label binding has been allocated.
	This FEC is resolved at an TT-PE when SAII is locally configured,		This FEC is resolved at an TT-PE when SAII is locally configured,
	TAII is learnt statically or dynamically via discovery mechanisms,		TAII is learnt statically or dynamically via discovery mechanisms,
	remote label binding is received, and a local label binding has been		remote label binding is received, and a local label binding has been
	allocated.		allocated.
	Whereas, this FEC is resolved at an S-PE when remote label binding is		Whereas, this FEC is resolved at an S-PE when remote label binding is
	received for PW segment, TAII is learnt statically or dynamically via		received for PW segment, TAII is learnt statically or dynamically via
	discovery mechanisms, and a local label binding has been allocated.		discovery mechanisms, and a local label binding has been allocated.
	3.3 P2MP PW Upstream FEC (FEC130):		3.3 Common to PWid and Generalized PWid FEC
			A FEC is resolved at an S-PE when remote label binding is received
			for PW segment.
			In the case of Generalized PWid FEC, TAII is learnt statically or
			dynamically via discovery mechanisms, and a local label binding has
			been allocated. Whereas PWid FEC is resolved when a local binding has
			been allocated.
			3.4 P2MP PW Upstream FEC (FEC130):
	Editor Note: Deferred for further study.		Editor Note: Deferred for further study.
	3.4 P2MP PW Downstream FEC (FEC132):		3.5 P2MP PW Downstream FEC (FEC132):
	Editor Note: Deferred for further study.		Editor Note: Deferred for further study.
	3.5 PW Typed Wildcard FEC		3.5 PW Typed Wildcard FEC
	The rules defined for individual PW FEC types apply equally when they		The rules defined for individual PW FEC types apply equally when they
	are used under a PW Typed Wildcard FEC [RFC6667].		are used under a PW Typed Wildcard FEC [RFC6667].
	4 Security Considerations		4 Acknowledgements
			The authors would like to thank for Alexander Vainshtein its
			reviews and comments of this document.
			5 Security Considerations
	This document does not introduce any additional security constraints.		This document does not introduce any additional security constraints.
	5 IANA Considerations		6 IANA Considerations
	This document requires the assignment of a new LDP Status Code to be		This document requires the assignment of a new LDP Status Code to be
	used in a Notification message to notify a peer LSR if lookup fails		used in a Notification message to notify a peer LSR if lookup fails
	at receiving LSR for a PW FEC received in a Label Request message.		at receiving LSR for a PW FEC received in a Label Request message.
	The value requested from the IANA managed LDP registry "LDP Status		The value requested from the IANA managed LDP registry "LDP Status
	Code Name Space" is:		Code Name Space" is:
	Range/Value E Description		Range/Value E Description
	----------- --- -----------		----------- --- -----------
	0x00000032 0 No PW		0x00000032 0 No PW
	6 References		7 References
	6.1 Normative References		7.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.
	[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	"LDP Specification", RFC 5036, October 2007.		"LDP Specification", RFC 5036, October 2007.
	[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and		[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
	G. Heron, "Pseudowire Setup and Maintenance Using the		G. Heron, "Pseudowire Setup and Maintenance Using the
	Label Distribution Protocol (LDP)", RFC 4447, April 2006.		Label Distribution Protocol (LDP)", RFC 4447, April 2006.
	[RFC6667] Raza, K., Boutros, S., and Pignataro, C., "LDP Typed		[RFC6667] Raza, K., Boutros, S., and Pignataro, C., "LDP Typed
	Wildcard FEC for PWid and Generalized PWid FEC", RFC 6667,		Wildcard FEC for PWid and Generalized PWid FEC", RFC 6667,
	July 2012.		July 2012.
	6.2 Informative References		7.2 Informative References
	Authors' Addresses		Authors' Addresses
	Patrice Brissette		Patrice Brissette
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Drive		2000 Innovation Drive
	Kanata, ON K2K-3E8, Canada.		Kanata, ON K2K-3E8, Canada.
	EMail: pbrisset@cisco.com		EMail: pbrisset@cisco.com
	Kamran Raza		Kamran Raza
End of changes. 24 change blocks.
	29 lines changed or deleted		52 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/