draft-ietf-mpls-lsp-ping-reply-mode-simple-04.txt		draft-ietf-mpls-lsp-ping-reply-mode-simple-05.txt
	Internet Engineering Task Force N. Akiya		Internet Engineering Task Force N. Akiya
	Internet-Draft Big Switch Networks		Internet-Draft Big Switch Networks
	Updates: 7110 (if approved) G. Swallow		Updates: 7110 (if approved) G. Swallow
	Intended status: Standards Track C. Pignataro		Intended status: Standards Track C. Pignataro
	Expires: March 16, 2016 Cisco Systems		Expires: April 10, 2016 Cisco Systems
	L. Andersson		L. Andersson
	M. Chen		M. Chen
	Huawei		Huawei
	September 13, 2015		October 8, 2015
	Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification		Label Switched Path (LSP) Ping/Traceroute Reply Mode Simplification
	draft-ietf-mpls-lsp-ping-reply-mode-simple-04		draft-ietf-mpls-lsp-ping-reply-mode-simple-05
	Abstract		Abstract
	The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)		The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
	Ping and Traceroute use the Reply Mode field to signal the method to		Ping and Traceroute use the Reply Mode field to signal the method to
	be used in the MPLS echo reply. This document updates the "Reply via		be used in the MPLS echo reply. This document updates the procedures
	Specified Path (5)" Reply Mode value to easily indicate the reverse		for the "Reply via Specified Path" Reply Mode, the value of this
	LSP. This document also adds an optional TLV which can carry ordered		Reply Mode is 5. The update creates a simple way to indicate that
	list of Reply Mode values.		the Reverse LSP should be used as return path. This document also
			adds an optional TLV which can carry ordered list of Reply Mode
			values.
	This document updates RFC7110.		This document updates RFC7110.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 47		skipping to change at page 2, line 4
	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 April 10, 2016.
	This Internet-Draft will expire on March 16, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 28		skipping to change at page 2, line 29
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3
	3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Reply via Specified Path Update . . . . . . . . . . . . . 5		3.1. Reply via Specified Path Update . . . . . . . . . . . . . 5
	3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6		3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6
	4. Relations to Other LSP Ping/Trace Features . . . . . . . . . 8		4. Relations to Other LSP Ping/Trace Features . . . . . . . . . 8
	4.1. Backwards Compatibility with Reply via Specified Path (5)		4.1. Backwards Compatibility with Reply via Specified Path
	Reply Mode . . . . . . . . . . . . . . . . . . . . . . . 8		Reply Mode . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 8		4.2. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 8
	4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path		4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path
	TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9		TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. Example 2: Reply Mode Order TLV Usage with Reply Path		4.2.2. Example 2: Reply Mode Order TLV Usage with Reply Path
	TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9		TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 10		4.3. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 10
	4.3.1. Proxy LSR Sending an MPLS Echo Request . . . . . . . 10		4.3.1. Proxy LSR Sending an MPLS Echo Request . . . . . . . 10
	4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply . . . . . 10		4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Manageability Considerations . . . . . . . . . . . . . . . . 10		6. Manageability Considerations . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 11		7.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 12		9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 12		Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 13
	A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 13		A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 14
	A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 13		A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)		The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
	Ping, described in [RFC4379], allows an initiator LSR to encode		Ping, described in [RFC4379], allows an initiator LSR to encode
	instructions (Reply Mode) on how a responder LSR should send the		instructions (Reply Mode) on how a responder LSR should send the
	response back to the initiator LSR. [RFC7110] also allows the		response back to the initiator LSR. [RFC7110] also allows the
	initiator LSR to encode a TLV (Reply Path TLV) which can instruct the		initiator LSR to encode a TLV (Reply Path TLV) which can instruct the
	responder LSR to use a specific LSP to send the response back to the		responder LSR to use a specific LSP to send the response back to the
	initiator LSR. Both approaches are powerful as they provide the		initiator LSR. Both approaches are powerful as they provide the
	skipping to change at page 3, line 40		skipping to change at page 3, line 40
	o In Section 2, further description of the problems;		o In Section 2, further description of the problems;
	o In Section 3, a solution to minimize false failures while		o In Section 3, a solution to minimize false failures while
	accommodating operator preferences;		accommodating operator preferences;
	o In Section 4, relationships to other LSP Ping/Traceroute features;		o In Section 4, relationships to other LSP Ping/Traceroute features;
	o In Appendix A, examples of scenarios where the mechanism described		o In Appendix A, examples of scenarios where the mechanism described
	in this document provides benefits.		in this document provides benefits.
	This documents updates [RFC7110] by allowing the usage of the Reply		This document updates [RFC7110] by allowing the usage of the "Reply
	Mode value 5 (Reply via Specified Path) without including the Reply		via Specified Path" (value=5) Reply Mode without including the Reply
	Path TLV.		Path TLV. The update creates a simple way to indicate that the
			Reverse LSP should be used as return path.
	2. Problem Statements		2. Problem Statements
	It is becoming increasingly difficult for implementations to		It is becoming increasingly difficult for implementations to
	automatically supply a workable return path encoding for all MPLS LSP		automatically supply a workable return path encoding for all MPLS LSP
	Ping and Traceroute operations across all LSP types. There are		Ping and Traceroute operations across all LSP types. There are
	several factors which are contributing to this complication.		several factors which are contributing to this complication.
	o Some LSPs have a control-channel, and some do not. Some LSPs have		o Some LSPs have a control-channel, and some do not. Some LSPs have
	a reverse LSP, and some do not. Some LSPs have IP reachability in		a reverse LSP, and some do not. Some LSPs have IP reachability in
	skipping to change at page 4, line 28		skipping to change at page 4, line 28
	unintended target, which can have different available return		unintended target, which can have different available return
	path(s) than the intended target.		path(s) than the intended target.
	o The MPLS LSP Ping operation is expected to terminate on an egress		o The MPLS LSP Ping operation is expected to terminate on an egress
	LSR. However, the MPLS LSP Ping operation with specific TTL		LSR. However, the MPLS LSP Ping operation with specific TTL
	values and MPLS LSP Traceroute operation can terminate on both		values and MPLS LSP Traceroute operation can terminate on both
	transit LSR(s) and the egress LSR.		transit LSR(s) and the egress LSR.
	Except for the case where the responder LSR does not have an IP route		Except for the case where the responder LSR does not have an IP route
	back to the initiator LSR, it is possible to use the "Reply via an		back to the initiator LSR, it is possible to use the "Reply via an
	IPv4/IPv6 UDP packet (2)" Reply Mode value in all cases. However,		IPv4/IPv6 UDP packet" (value=2) Reply Mode value in all cases.
	some operators are preferring control-channel and reverse LSP as		However, some operators are preferring control-channel and reverse
	default return path if they are available, which is not always the		LSP as default return path if they are available, which is not always
	case.		the case.
	When specific return path encoding is supplied by users or		When specific return path encoding is supplied by users or
	applications, then there are no issues in choosing the return path		applications, then there are no issues in choosing the return path
	encoding. When specific return path encoding is not supplied by		encoding. When specific return path encoding is not supplied by
	users or applications, then implementations use extra logic to		users or applications, then implementations use extra logic to
	compute, and sometimes guess, the default return path encodings. If		compute, and sometimes guess, the default return path encodings. If
	a responder LSR receives an MPLS echo request containing return path		a responder LSR receives an MPLS echo request containing return path
	instructions which cannot be accommodated due to unavailability, then		instructions which cannot be accommodated due to unavailability, then
	the responder LSR often drops such packets. This failure mode		the responder LSR often drops such packets. This failure mode
	results in the initiator LSR not receiving the intended MPLS LSP echo		results in the initiator LSR not receiving the intended MPLS LSP echo
	skipping to change at page 5, line 14		skipping to change at page 5, line 14
	for particular operations, or allow a default return path to be		for particular operations, or allow a default return path to be
	configured. It would not be considered beneficial to use a preferred		configured. It would not be considered beneficial to use a preferred
	return path for an intended target LSR if there is previous knowledge		return path for an intended target LSR if there is previous knowledge
	at the initiator LSR that the return path is not available. Using a		at the initiator LSR that the return path is not available. Using a
	unavailable preferred return path would undesirably result in the		unavailable preferred return path would undesirably result in the
	initiator LSR not receiving the MPLS echo return packets. It would		initiator LSR not receiving the MPLS echo return packets. It would
	be considered beneficial, for given operations, if the sender of the		be considered beneficial, for given operations, if the sender of the
	MPLS echo request would be able to determined return path		MPLS echo request would be able to determined return path
	availability before the operation is initiated.		availability before the operation is initiated.
	This document updates the "Reply via Specified Path (5)" Reply Mode		This document updates the procedures for "Reply via Specified Path"
	to easily indicate the reverse the reverse LSP, and adds one optional		Reply Mode to easily indicate the reverse LSP, and adds one optional
	TLV to describe an ordered list of reply modes. Based on operational		TLV to describe an ordered list of Reply Modes. Based on operational
	needs, the TLV can describe multiple Reply Mode values in a preferred		needs, the TLV can describe multiple Reply Mode values in a preferred
	order to allow the responder LSR to use the first available Reply		order to allow the responder LSR to use the first available Reply
	Mode from the list. This eliminates the need for the initiator LSR		Mode from the list. This eliminates the need for the initiator LSR
	to compute, or sometimes guess, the default return path encoding.		to compute, or sometimes guess, the default return path encoding.
	This new mode of operation would resulted in a simplification to		This new mode of operation would resulted in a simplification to
	implementations across the various vendors and improve both usability		implementations across the various vendors and improve both usability
	and operational needs.		and operational needs.
	3. Solution		3. Solution
	This document updates the "Reply via Specified Path (5)" Reply Mode		This document updates the procedures for "Reply via Specified Path"
	to easily indicate the reverse LSP. This document also adds an		Reply Mode to easily indicate the reverse LSP. This document also
	optional TLV which can carry an ordered list of reply modes.		adds an optional TLV which can carry an ordered list of Reply Modes.
	3.1. Reply via Specified Path Update		3.1. Reply via Specified Path Update
	Some LSP types are capable of having a related LSP in reverse		Some LSP types are capable of having a related LSP in reverse
	direction, through signaling or other association mechanisms.		direction, through signaling or other association mechanisms.
	Examples of such LSP types are bidirectional Resource ReserVation		Examples of such LSP types are bidirectional Resource ReserVation
	Protocol-Traffic Engineering (RSVP-TE) LSPs [RFC3473] and MPLS		Protocol-Traffic Engineering (RSVP-TE) LSPs [RFC3473] and MPLS
	Transport Profile (MPLS-TP) LSPs ([RFC5960]). This document uses the		Transport Profile (MPLS-TP) LSPs ([RFC5960]). This document uses the
	term "Reverse LSP" to refer to the LSP in the reverse direction of		term "Reverse LSP" to refer to the LSP in the reverse direction of
	such LSP types. Note that this document restricts the scope of		such LSP types. Note that this document restricts the scope of
	"Reverse LSP" applicability to those reverse LSPs which are capable		"Reverse LSP" applicability to those reverse LSPs which are capable
	and allowed to carry the IP encapsulated MPLS echo reply.		and allowed to carry the IP encapsulated MPLS echo reply.
	[RFC7110] has defined the Reply Mode "Reply via Specified Path (5)"		[RFC7110] has defined the Reply Mode "Reply via Specified Path" which
	which allows the initiator LSR to instruct the responder LSR to send		allows the initiator LSR to instruct the responder LSR to send the
	the MPLS echo reply message on the reverse LSP. However, the		MPLS echo reply message on the reverse LSP. However, the instruction
	instruction also requires the initiator LSR to include the "Reply		also requires the initiator LSR to include the "Reply Path TLV" with
	Path TLV" with the B bit (Bidirectional bit) set in the Flags field.		the B bit (Bidirectional bit) set in the Flags field. Additionally,
	Additionally, [RFC7110] defines the usage of the "Reply via Specified		[RFC7110] defines that if the "Reply via Specified Path" Reply Mode
	Path (5)" Reply Mode without inclusion of the "Reply Path TLV" to be		is used the "Reply Path TLV" MUST present.
	invalid.
	This document updates the "Reply via Specified Path (5)" Reply Mode		This document updates the procedures for "Reply via Specified Path"
	as follows:		Reply Mode as follows:
	o The usage of the "Reply via Specified Path (5)" without inclusion		o The "Reply via Specified Path" MAY be used without including a
	of a "Reply Path TLV" is no longer invalid.		"Reply Path TLV".
	o The usage of the "Reply via Specified Path (5)" without inclusion		o The usage of the "Reply via Specified Path" without inclusion of a
	of a "Reply Path TLV" implies the reverse LSP. In other words,		"Reply Path TLV" implies the reverse LSP. In other words, the
	the usage of the "Reply via Specified Path (5)" without inclusion		usage of the "Reply via Specified Path" without inclusion of a
	of a "Reply Path TLV" has the same semantics as the usage of the		"Reply Path TLV" has the same semantics as the usage of the "Reply
	"Reply via Specified Path (5)" with inclusion of a "Reply Path		via Specified Path" with inclusion of a "Reply Path TLV" with the
	TLV" with the B bit set in the Flags field.		B bit set in the Flags field.
			Specific to section 5.1 of [RFC7110], this document updates the first
			sentence as follows:
			o When sending an echo request, in addition to the rules and
			procedures defined in Section 4.3 of [RFC4379], the Reply Mode of
			the echo request MUST be set to "Reply via Specified Path", and a
			Reply Path TLV SHOULD be carried in the echo request message
			correspondingly; if the Reply Path TLV is not carried, then it
			indicates the reverse LSP as the reply path.
	Note that the reverse LSP is in relation to the last FEC specified in		Note that the reverse LSP is in relation to the last FEC specified in
	the Target FEC Stack TLV.		the Target FEC Stack TLV.
	3.2. Reply Mode Order TLV		3.2. Reply Mode Order TLV
	This document also introduces a new optional TLV to describe a list		This document also introduces a new optional TLV to describe a list
	of Reply Mode values. The new TLV will contain one or more Reply		of Reply Mode values. The new TLV will contain one or more Reply
	Mode value(s) in preferred order. The first Reply Mode value is the		Mode value(s) in preferred order. The first Reply Mode value is the
	most preferred and the last Reply Mode value is the least preferred.		most preferred and the last Reply Mode value is the least preferred.
	skipping to change at page 7, line 43		skipping to change at page 8, line 10
	path MUST be set in Reply Mode field of the MPLS echo reply to		path MUST be set in Reply Mode field of the MPLS echo reply to
	communicate back to the initiator LSR which return path was chosen.		communicate back to the initiator LSR which return path was chosen.
	The format of the TLV is as follows:		The format of the TLV is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reply Mode Order TLV Type | Length |		| Reply Mode Order TLV Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Reply mode 1 | Reply mode 2 | Reply mode 3 | Reply mode 4 ~		~ Reply Mode 1 | Reply Mode 2 | Reply Mode 3 | Reply Mode 4 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1 Reply Mode Order TLV		Figure 1 Reply Mode Order TLV
	This is a variable length optional TLV. Each Reply Mode field is 1		This is a variable length optional TLV. The Reply Mode Order TLV
	octet.		Type is TBD1.
			The Length field is 2 octets in length. It defines the length in
			octets of the list of Reply Mode values.
			Each Reply Mode field is 1 octet, and there is no padding.
	4. Relations to Other LSP Ping/Trace Features		4. Relations to Other LSP Ping/Trace Features
	4.1. Backwards Compatibility with Reply via Specified Path (5) Reply		4.1. Backwards Compatibility with Reply via Specified Path Reply Mode
	Mode
	[RFC7110] has introduced the "Reply via Specified path (5)" Reply		[RFC7110] introduces the "Reply via Specified Path" (value=5) Reply
	Mode, and defined that usage of the "Reply via Specified path (5)"		Mode. The RFC also defines that if this Reply Mode is used, the
	Reply Mode without also including the "Reply Path TLV" to be invalid.		"Reply Path TLV" MUST be included. This document relaxes the
	This document relaxes this semantic by defining the use of the "Reply		semantics and defines that this Reply Mode MAY be used without the
	via Specified path (5)" Reply Mode without the "Reply via Specified		"Reply Path TLV". This MAY be done to indicate that the reverse LSP
	path (5)" to indicate the reverse LSP. In other words, what was		SHALL be used as he return path.
	considered invalid is now valid. If the initiator LSR, which sent an
	MPLS echo request message with the "Reply via Specified path (5)"		If the initiator LSR, which sent an MPLS echo request message with
	Reply Mode but without including the "Reply Path TLV", receives back		the "Reply via Specified Path" Reply Mode but without including the
	an MPLS echo reply message with the return code being "Malformed echo		"Reply Path TLV", receives back an MPLS echo reply message with the
	request received", then the initiator LSR SHOULD assume that the		return code being "Malformed echo request received", then the
	responder LSR does not support the mechanism defined in this		initiator LSR SHOULD assume that the responder LSR does not support
	document.		the mechanism defined in this document.
	4.2. Reply Path TLV		4.2. Reply Path TLV
	A "Reply Path TLV" [RFC7110] is defined to identify a single return		A "Reply Path TLV" [RFC7110] is defined to identify a single return
	path. When the initiator LSR wants to use the Reply Mode Order TLV		path. When the initiator LSR wants to use the Reply Mode Order TLV
	to describe multiple return paths, then the initiator SHOULD include		to describe multiple return paths, then the initiator SHOULD include
	multiple "Reply via Specified Path (5)" Reply mode values and		multiple "Reply via Specified Path" (value=5) Reply Mode values and
	multiple corresponding "Reply Path TLV" objects (one "Reply Path TLV"		multiple corresponding "Reply Path TLV" objects (one "Reply Path TLV"
	corresponding to a "Reply via Specified Path (5)" Reply mode, and one		corresponding to a "Reply via Specified Path" Reply Mode, and one
	"Reply Path TLV" identifies a return path).		"Reply Path TLV" identifies a return path).
	As described in Section 3.1, it's valid to use the "Reply via		As described in Section 3.1, it's valid to use the "Reply via
	Specified Path (5)" Reply mode without inclusion a "Reply Path TLV".		Specified Path" Reply Mode without inclusion a "Reply Path TLV". For
	For the Reply Mode Order TLV, it's also valid to include a "Reply via		the Reply Mode Order TLV, it's also valid to include a "Reply via
	Specified Path (5)" Reply mode value without a corresponding "Reply		Specified Path" Reply Mode value without a corresponding "Reply Path
	Path TLV", this implies that the reverse LSP is the preferred return		TLV", this implies that the reverse LSP is the preferred return path.
	path. When multiple consecutive "Reply via Specified Path (5)" Reply		When multiple consecutive "Reply via Specified Path" Reply Mode
	mode values are included but less corresponding "Reply Path TLV"		values are included but less corresponding "Reply Path TLV" objects
	objects exist, the responder LSR SHOULD think that the former "Reply		exist, the responder LSR SHOULD think that the former "Reply via
	via Specified Path (5)" Reply mode values have corresponding "Reply		Specified Path" Reply Mode values have corresponding "Reply Path
	Path TLV", the latter "Reply via Specified Path (5)" Reply mode		TLV", the latter "Reply via Specified Path" Reply Mode values have no
	values have no corresponding "Reply Path TLV". For example, if the		corresponding "Reply Path TLV". For example, if the Reply Mode Order
	Reply Mode Order TLV carrying Reply Modes {5, 5, 5} and only two		TLV carrying Reply Modes {5, 5, 5} and only two Reply Path TLVs
	Reply Path TLVs carrying FEC X and FEC Y respectively. The reply		carrying FEC X and FEC Y respectively. The reply path order is as
	path order is as follows:		follows:
	1. Reply via Specified Path (FEC X)		1. Reply via Specified Path (FEC X)
	2. Reply via Specified Path (FEC Y)		2. Reply via Specified Path (FEC Y)
	3. Reply via Specified Path (Reverse LSP)		3. Reply via Specified Path (Reverse LSP)
	4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path TLV		4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path TLV
	If the initiator LSR was interested in encoding following return		If the initiator LSR was interested in encoding following return
	paths:		paths:
	1. Reply via application level control channel		1. Reply via application level control channel
	2. FEC X		2. FEC X
	skipping to change at page 10, line 41		skipping to change at page 11, line 16
	TLVs, then order of them MUST be preserved when copying.		TLVs, then order of them MUST be preserved when copying.
	4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply		4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply
	If the proxy LSR is sending an MPLS proxy ping reply, then it is		If the proxy LSR is sending an MPLS proxy ping reply, then it is
	RECOMMENDED that the Reply Mode Order TLV is ignored and the Reply		RECOMMENDED that the Reply Mode Order TLV is ignored and the Reply
	Mode field in the MPLS proxy ping request message is used.		Mode field in the MPLS proxy ping request message is used.
	5. Security Considerations		5. Security Considerations
	Beyond those specified in [RFC4379] and [RFC7110], there are no		Those security considerations specified in [RFC4379] and [RFC7110]
	further security measures required.		apply for this document.
			In addition, this document introduces the Reply Mode Order TLV. It
			provides a new way for an unauthorized source to gather more network
			information, especially the potential return path(s) information of
			an LSP. To protect against unauthorized sources using MPLS echo
			request messages with the Reply Mode Order TLV to obtain network
			information, similar to [RFC4379], it is RECOMMENDED that
			implementations provide a means of checking the source addresses of
			MPLS echo request messages against an access list before accepting
			the message.
			Another potential security issue is that the MPLS echo request and
			reply messages are not encrypted, the content of the MPLS echo
			request and reply messages may be potentially exposed. Although the
			exposure is within the MPLS domain, if such exposure is a concern,
			some encryption mechanisms [I-D.ietf-mpls-opportunistic-encrypt] may
			be employed.
	6. Manageability Considerations		6. Manageability Considerations
	Section 2 described the problems which increases the complexity with		Section 2 described the problems which increases the complexity with
	respect to operations and implementations. In order to simplify		respect to operations and implementations. In order to simplify
	operations and to allow for the LSP Ping/Traceroute to function		operations and to allow for the LSP Ping/Traceroute to function
	efficiently whilst preserving the code simplicity, it is RECOMMENDED		efficiently whilst preserving the code simplicity, it is RECOMMENDED
	that implementations allow devices to have configuration options to		that implementations allow devices to have configuration options to
	set operator preferred Reply Modes. For example:		set operator preferred Reply Modes. For example:
	skipping to change at page 12, line 32		skipping to change at page 13, line 23
	DOI 10.17487/RFC4379, February 2006,		DOI 10.17487/RFC4379, February 2006,
	<http://www.rfc-editor.org/info/rfc4379>.		<http://www.rfc-editor.org/info/rfc4379>.
	[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,		[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
	"Return Path Specified Label Switched Path (LSP) Ping",		"Return Path Specified Label Switched Path (LSP) Ping",
	RFC 7110, DOI 10.17487/RFC7110, January 2014,		RFC 7110, DOI 10.17487/RFC7110, January 2014,
	<http://www.rfc-editor.org/info/rfc7110>.		<http://www.rfc-editor.org/info/rfc7110>.
	10.2. Informative References		10.2. Informative References
			[I-D.ietf-mpls-opportunistic-encrypt]
			Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
			Networks", draft-ietf-mpls-opportunistic-encrypt-00 (work
			in progress), July 2015.
	[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label		[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Resource ReserVation Protocol-		Switching (GMPLS) Signaling Resource ReserVation Protocol-
	Traffic Engineering (RSVP-TE) Extensions", RFC 3473,		Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
	DOI 10.17487/RFC3473, January 2003,		DOI 10.17487/RFC3473, January 2003,
	<http://www.rfc-editor.org/info/rfc3473>.		<http://www.rfc-editor.org/info/rfc3473>.
	[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS		[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
	Transport Profile Data Plane Architecture", RFC 5960,		Transport Profile Data Plane Architecture", RFC 5960,
	DOI 10.17487/RFC5960, August 2010,		DOI 10.17487/RFC5960, August 2010,
	<http://www.rfc-editor.org/info/rfc5960>.		<http://www.rfc-editor.org/info/rfc5960>.
End of changes. 27 change blocks.
	89 lines changed or deleted		127 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/