< draft-ietf-mpls-bfd-directed-02.txt		draft-ietf-mpls-bfd-directed-03.txt >
	MPLS Working Group G. Mirsky		MPLS Working Group G. Mirsky
	Internet-Draft J. Tantsura		Internet-Draft Ericsson
	Intended status: Standards Track Ericsson		Intended status: Standards Track J. Tantsura
	Expires: September 3, 2016 I. Varlashkin		Expires: February 18, 2017
			I. Varlashkin
	Google		Google
	M. Chen		M. Chen
	Huawei		Huawei
	March 2, 2016		August 17, 2016
	Bidirectional Forwarding Detection (BFD) Directed Return Path		Bidirectional Forwarding Detection (BFD) Directed Return Path
	draft-ietf-mpls-bfd-directed-02		draft-ietf-mpls-bfd-directed-03
	Abstract		Abstract
	Bidirectional Forwarding Detection (BFD) is expected to monitor bi-		Bidirectional Forwarding Detection (BFD) is expected to monitor any
	directional paths. When a BFD session monitors an explicit routed		kind of paths between systems. When a BFD session monitors an
	path there is a need to be able to direct egress BFD peer to use		explicitly routed uni-directional path there may be a need to direct
	specific path for the reverse direction of the BFD session.		egress BFD peer to use specific path for the reverse direction of the
			BFD session.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 3, 2016.		This Internet-Draft will expire on February 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 20 ¶		skipping to change at page 2, line 22 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions used in this document . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . 3
	1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3		1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 4		3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 4
	3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 4		3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 4
	3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4		3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4
	3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5		3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5
	3.1.3. Segment Routing: MPLS Data Plane Case . . . . . . . . 5		3.1.3. Segment Routing: MPLS Data Plane Case . . . . . . . . 5
	3.2. Segment Routing: IPv6 Data Plane Case . . . . . . . . . . 6		3.2. Bootstrapping BFD session with BFD Reverse Path over
	3.3. Bootstrapping BFD session with BFD Reverse Path over
	Segment Routed tunnel . . . . . . . . . . . . . . . . . . 6		Segment Routed tunnel . . . . . . . . . . . . . . . . . . 6
	3.4. Return Codes . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 6
	4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 7		4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 9		5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. Normative References . . . . . . . . . . . . . . . . . . . . 9		8. Normative References . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883]		RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883]
	established the BFD protocol for IP networks and RFC 5884 [RFC5884]		established the BFD protocol for IP networks and RFC 5884 [RFC5884]
	set rules of using BFD asynchronous mode over IP/MPLS LSPs. These		set rules of using BFD asynchronous mode over IP/MPLS LSPs. These
	four standards implicitly assume that the egress BFD peer will use		four standards implicitly assume that the egress BFD peer will use
	the shortest path route regardless of route being used to send BFD		the shortest path route regardless of route being used to send BFD
	control packets towards it.		control packets towards it.
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Problem Statement		2. Problem Statement
	BFD is best suited to monitor bi-directional co-routed paths. In		BFD is best suited to monitor bi-directional co-routed paths. In
	most cases, given stable environments, the forward and reverse		most cases, given stable environments, the forward and reverse
	directions between two nodes are likely to be co-routed, thus		directions between two nodes are likely to be co-routed. If BFD is
	fulfilling the implicit BFD requirement. If BFD is used to monitor		used to monitor unidirectional explicitly routed path, e.g. MPLS-TE
	unidirectional explicitly routed path, e.g. MPLS-TE LSP, BFD control		LSP, BFD control packets in forward direction would be in-band using
	packets in forward direction would be in-band using the mechanism		the mechanism defined in [RFC5884] and [RFC5586]. But the reverse
	defined in [RFC5884] and [RFC5586]. But the reverse direction of the		direction of the BFD session would still follow the shortest path
	BFD session would still follow the shortest path route and that might		route and that might lead to the following problem in detecting
	lead to the following problem in detecting failures on a		failures on a unidirectional explicit path:
	unidirectional explicit path:
	o a failure detection by ingress node on the reverse path cannot be		o a failure detection by ingress node on the reverse path cannot be
	interpreted as bi-directional failure with all the certainty and		interpreted as bi-directional failure with all the certainty and
	thus trigger, for example, protection switchover of the forward		thus trigger, for example, protection switchover of the forward
	direction without possibility of being a false positive defect		direction without possibility of being a false positive defect
	notification.		notification.
	To address this scenario the egress BFD peer should be instructed to		To address this scenario the egress BFD peer should be instructed to
	use a specific path for BFD control packets.		use a specific path for BFD control packets.
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	Length field is 2 octets long and defines the length in octets of the		Length field is 2 octets long and defines the length in octets of the
	Reverse Path field.		Reverse Path field.
	Reverse Path field contains a sub-TLV. Any Target FEC sub-TLV		Reverse Path field contains a sub-TLV. Any Target FEC sub-TLV
	(already defined, or to be defined in the future) for TLV Types 1,		(already defined, or to be defined in the future) for TLV Types 1,
	16, and 21 of MPLS LSP Ping Parameters registry MAY be used in this		16, and 21 of MPLS LSP Ping Parameters registry MAY be used in this
	field. Exactly one sub-TLV MUST be included in the Reverse Path TLV.		field. Exactly one sub-TLV MUST be included in the Reverse Path TLV.
	If more than one sub-TLV is present in the Reverse Path TLV, then, in		If more than one sub-TLV is present in the Reverse Path TLV, then, in
	order to avoid ambiguity of which of TLVs to use, the egress BFD peer		order to avoid ambiguity of which of TLVs to use, the egress BFD peer
	MUST send Echo Reply with the received Reverse Path TLVs and set the		MUST send Echo Reply with the received Reverse Path TLVs and set the
	Return Code to "Too Many TLVs Detected" Section 3.4.		Return Code to "Too Many TLVs Detected" Section 3.3.
	If the egress LSR cannot find the path specified in the Reverse Path		If the egress LSR cannot find the path specified in the Reverse Path
	TLV it MUST send Echo Reply with the received Reverse Path TLV and		TLV it MUST send Echo Reply with the received Reverse Path TLV and
	set the Return Code to "Failed to establish the BFD session. The		set the Return Code to "Failed to establish the BFD session. The
	specified reverse path was not found" Section 3.4. The egress BFD		specified reverse path was not found" Section 3.3. The egress BFD
	peer MAY establish the BFD session over IP network as defined in		peer MAY establish the BFD session over IP network as defined in
	[RFC5884].		[RFC5884].
	3.1.2. Static and RSVP-TE sub-TLVs		3.1.2. Static and RSVP-TE sub-TLVs
	When an explicit path on an MPLS data plane is set either as Static		When an explicit path on an MPLS data plane is set either as Static
	or RSVP-TE LSP respective sub-TLVs defined in [RFC7110] MAY be used		or RSVP-TE LSP respective sub-TLVs defined in [RFC7110] MAY be used
	to identify the explicit reverse path for the BFD session.		to identify the explicit reverse path for the BFD session.
	3.1.3. Segment Routing: MPLS Data Plane Case		3.1.3. Segment Routing: MPLS Data Plane Case
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	Section 5).		Section 5).
	The egress LSR MUST use the Value field as label stack for BFD		The egress LSR MUST use the Value field as label stack for BFD
	control packets for the BFD session identified by the source IP		control packets for the BFD session identified by the source IP
	address of the MPLS LSP Ping packet and the value in the BFD		address of the MPLS LSP Ping packet and the value in the BFD
	Discriminator TLV. Label Entries MUST be in network order.		Discriminator TLV. Label Entries MUST be in network order.
	The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV		The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV
	defined in [RFC7110]		defined in [RFC7110]
	3.2. Segment Routing: IPv6 Data Plane Case		3.2. Bootstrapping BFD session with BFD Reverse Path over Segment
	IPv6 can be used as the data plane of choice for Segment Routed
	tunnels [I-D.previdi-6man-segment-routing-header]. In this case the
	BFD Reverse Path TLV described in Section 3.1.1 can be used as well.
	To specify the reverse path of a BFD session for an IPv6 explicitly
	routed path the BFD Discriminator TLV MUST be used along with the BFD
	Reverse Path TLV. The BFD Reverse Path TLV in IPv6 network MUST
	include the Segment Routing IPv6 Tunnel sub-TLV.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SegRouting IPv6 sub-TLV Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| IPv6 Prefix |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| IPv6 Prefix |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Segment Routing IPv6 Tunnel sub-TLV
	The Segment Routing IPv6 Tunnel sub-TLV Type is two octets in length,
	and has a value of TB3 (to be assigned by IANA as requested in
	Section 5).
	3.3. Bootstrapping BFD session with BFD Reverse Path over Segment
	Routed tunnel		Routed tunnel
	As discussed in [I-D.kumarkini-mpls-spring-lsp-ping] introduction of		As discussed in [I-D.ietf-mpls-spring-lsp-ping] introduction of
	Segment Routing network domains with an MPLS data plane adds three		Segment Routing network domains with an MPLS data plane adds three
	new sub-TLVs that MAY be used with Target FEC TLV. Section 6.1		new sub-TLVs that MAY be used with Target FEC TLV. Section 6.1
	addresses use of the new sub-TLVs in Target FEC TLV in LSP ping and		addresses use of the new sub-TLVs in Target FEC TLV in LSP ping and
	LSP traceroute. For the case of LSP ping the		LSP traceroute. For the case of LSP ping the
	[I-D.kumarkini-mpls-spring-lsp-ping] states that:		[I-D.ietf-mpls-spring-lsp-ping] states that:
	"Initiator MUST include FEC(s) corresponding to the destination		"Initiator MUST include FEC(s) corresponding to the destination
	segment. "		segment. "
	"Initiator, i.e. ingress LSR, MAY include FECs corresponding to some		"Initiator, i.e. ingress LSR, MAY include FECs corresponding to some
	or all of segments imposed in the label stack by the ingress LSR to		or all of segments imposed in the label stack by the ingress LSR to
	communicate the segments traversed. "		communicate the segments traversed. "
	When LSP ping is used to bootstrap BFD session this document updates		When LSP ping is used to bootstrap BFD session this document updates
	the statement and defines that LSP Ping MUST include the FEC		the statement and defines that LSP Ping MUST include the FEC
	corresponding to the destination segment and SHOULD NOT include FECs		corresponding to the destination segment and SHOULD NOT include FECs
	corresponding to some or all of other segments imposed by the ingress		corresponding to some or all of other segments imposed by the ingress
	LSR. Operationally such restriction would not cause any problem or		LSR. Operationally such restriction would not cause any problem or
	uncertainty as LSP ping with FECs corresponding to some or all		uncertainty as LSP ping with FECs corresponding to some or all
	segments or traceroute that validate the segment route MAY precede		segments or traceroute that validate the segment route MAY precede
	the LSP ping that bootstraps the BFD session.		the LSP ping that bootstraps the BFD session.
	3.4. Return Codes		3.3. Return Codes
	This document defines the following Return Codes for MPLS LSP Echo		This document defines the following Return Codes for MPLS LSP Echo
	Reply:		Reply:
	o "Too Many TLVs Detected", (TBD4). When more than one Reverse Path		o "Too Many TLVs Detected", (TBD3). When more than one Reverse Path
	TLV found in the recieved Echo Request by the egress BFD peer, an		TLV found in the received Echo Request by the egress BFD peer, an
	Echo Reply with the return code set to "Too Many TLVs Detected"		Echo Reply with the return code set to "Too Many TLVs Detected"
	MUST be sent to the ingress BFD peer Section 3.1.1.		MUST be sent to the ingress BFD peer Section 3.1.1.
	o "Failed to establish the BFD session. The specified reverse path		o "Failed to establish the BFD session. The specified reverse path
	was not found", (TBD5). When a specified reverse path is not		was not found", (TBD4). When a specified reverse path is not
	available at the egress BFD peer, an Echo Reply with the return		available at the egress BFD peer, an Echo Reply with the return
	code set to "Failed to establish the BFD session. The specified		code set to "Failed to establish the BFD session. The specified
	reverse path was not found" MUST be sent back to the ingress BFD		reverse path was not found" MUST be sent back to the ingress BFD
	peer Section 3.1.1.		peer Section 3.1.1.
	4. Use Case Scenario		4. Use Case Scenario
	In the network presented in Figure 4 node A monitors two tunnels to		In the network presented in Figure 3 node A monitors two tunnels to
	node H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap a BFD session to		node H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap a BFD session to
	monitor the first tunnel, node A MUST include a BFD Discriminator TLV		monitor the first tunnel, node A MUST include a BFD Discriminator TLV
	with Discriminator value (e.g. foobar-1) and MAY include a BFD		with Discriminator value (e.g. foobar-1) and MAY include a BFD
	Reverse Path TLV that references H-G-D-C-B-A tunnel. To bootstrap a		Reverse Path TLV that references H-G-D-C-B-A tunnel. To bootstrap a
	BFD session to monitor the second tunnel, node A MUST include a BFD		BFD session to monitor the second tunnel, node A MUST include a BFD
	Discriminator TLV with a different Discriminator value (e.g. foobar-		Discriminator TLV with a different Discriminator value (e.g. foobar-
	2) [RFC7726] and MAY include a BFD Reverse Path TLV that references		2) [RFC7726] and MAY include a BFD Reverse Path TLV that references
	H-G-F-E-B-A tunnel.		H-G-F-E-B-A tunnel.
	C---------D		C---------D
	| |		| |
	A-------B G-----H		A-------B G-----H
	| |		| |
	E---------F		E---------F
	Figure 4: Use Case for BFD Reverse Path TLV		Figure 3: Use Case for BFD Reverse Path TLV
	If an operator needs node H to monitor a path to node A, e.g.		If an operator needs node H to monitor a path to node A, e.g.
	H-G-D-C-B-A tunnel, then by looking up list of known Reverse Paths it		H-G-D-C-B-A tunnel, then by looking up list of known Reverse Paths it
	MAY find and use the existing BFD session.		MAY find and use the existing BFD session.
	5. IANA Considerations		5. IANA Considerations
	5.1. TLV		5.1. TLV
	The IANA is requested to assign a new value for BFD Reverse Path TLV		The IANA is requested to assign a new value for BFD Reverse Path TLV
	skipping to change at page 8, line 36 ¶		skipping to change at page 7, line 48 ¶
	+----------+----------------------+---------------+		+----------+----------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+----------+----------------------+---------------+		+----------+----------------------+---------------+
	| X (TBD1) | BFD Reverse Path TLV | This document |		| X (TBD1) | BFD Reverse Path TLV | This document |
	+----------+----------------------+---------------+		+----------+----------------------+---------------+
	Table 1: New BFD Reverse Type TLV		Table 1: New BFD Reverse Type TLV
	5.2. Sub-TLV		5.2. Sub-TLV
	The IANA is requested to assign two new sub-TLV types from		The IANA is requested to assign new sub-TLV type from "Multiprotocol
	"Multiprotocol Label Switching Architecture (MPLS) Label Switched		Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping
	Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV		Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21"
	Types 1, 16, and 21" sub-registry.		sub-registry.
	+----------+-------------------------------------+---------------+		+----------+-------------------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+----------+-------------------------------------+---------------+		+----------+-------------------------------------+---------------+
	| X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |		| X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |
	| X (TBD3) | Segment Routing IPv6 Tunnel sub-TLV | This document |
	+----------+-------------------------------------+---------------+		+----------+-------------------------------------+---------------+
	Table 2: New Segment Routing Tunnel sub-TLV		Table 2: New Segment Routing Tunnel sub-TLV
	5.3. Return Codes		5.3. Return Codes
	The IANA is requested to assign a new Return Code value from the		The IANA is requested to assign a new Return Code value from the
	"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)		"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
	Ping Parameters" registry, "Return Codes" sub-registry, as follows		Ping Parameters" registry, "Return Codes" sub-registry, as follows
	using a Standards Action value.		using a Standards Action value.
	+----------+----------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+----------+----------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	| X (TBD4) | Too Many TLVs Detected. | This document |		| X (TBD3) | Too Many TLVs Detected. | This document |
	| X (TBD5) | Failed to establish the BFD session. | This document |		| X (TBD4) | Failed to establish the BFD session. | This document |
	| | The specified reverse path was not | |		| | The specified reverse path was not | |
	| | found. | |		| | found. | |
	+----------+----------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	Table 3: New Return Code		Table 3: New Return Code
	6. Security Considerations		6. Security Considerations
	Security considerations discussed in [RFC5880], [RFC5884], and		Security considerations discussed in [RFC5880], [RFC5884], and
	[RFC4379], apply to this document.		[RFC4379], apply to this document.
	7. Acknowledgements		7. Acknowledgements
	Authors greatly appreciate thorough review and the most helpful		Authors greatly appreciate thorough review and the most helpful
	comments from Eric Gray.		comments from Eric Gray.
	8. Normative References		8. Normative References
	[I-D.kumarkini-mpls-spring-lsp-ping]		[I-D.ietf-mpls-spring-lsp-ping]
	Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,		Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
	S., Gredler, H., and M. Chen, "Label Switched Path (LSP)		S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
	Ping/Trace for Segment Routing Networks Using MPLS		Ping/Trace for Segment Routing Networks Using MPLS
	Dataplane", draft-kumarkini-mpls-spring-lsp-ping-05 (work		Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in
	in progress), January 2016.		progress), May 2016.
	[I-D.previdi-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
	J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
	Routing Header (SRH)", draft-previdi-6man-segment-routing-
	header-08 (work in progress), October 2015.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,		Label Switched (MPLS) Data Plane Failures", RFC 4379,
	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>.
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 11 ¶
	Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,		Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
	DOI 10.17487/RFC7726, January 2016,		DOI 10.17487/RFC7726, January 2016,
	<http://www.rfc-editor.org/info/rfc7726>.		<http://www.rfc-editor.org/info/rfc7726>.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	Ericsson		Ericsson
	Email: gregory.mirsky@ericsson.com		Email: gregory.mirsky@ericsson.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson
	Email: jeff.tantsura@ericsson.com		Email: jefftant.ietf@gmail.com
	Ilya Varlashkin		Ilya Varlashkin
	Google		Google
	Email: Ilya@nobulus.com		Email: Ilya@nobulus.com
	Mach(Guoyi) Chen		Mach(Guoyi) Chen
	Huawei		Huawei
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
End of changes. 27 change blocks.
	91 lines changed or deleted		50 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/