draft-ietf-mpls-flow-ident-01.txt		draft-ietf-mpls-flow-ident-02.txt
	MPLS S. Bryant		MPLS Working Group S. Bryant
	Internet-Draft Independent		Internet-Draft M. Chen
	Intended status: Informational C. Pignataro		Intended status: Informational Z. Li
	Expires: December 12, 2016 Cisco Systems		Expires: February 26, 2017 Huawei
	M. Chen		C. Pignataro
	Z. Li		Cisco Systems
	Huawei
	G. Mirsky		G. Mirsky
	Ericsson		Ericsson
	June 10, 2016		August 25, 2016
	MPLS Flow Identification Considerations		MPLS Flow Identification Considerations
	draft-ietf-mpls-flow-ident-01		draft-ietf-mpls-flow-ident-02
	Abstract		Abstract
	This memo discusses the desired capabilities for MPLS flow		This memo discusses the desired capabilities for MPLS flow
	identification. The key application that needs this is in-band		identification. The key application that needs this is in-band
	performance monitoring of user data packets.		performance monitoring of user data packets.
	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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 37 ¶
	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 December 12, 2016.		This Internet-Draft will expire on February 26, 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 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	multi-point to point and multi-point to multi-point network		multi-point to point and multi-point to multi-point network
	environments there needs to be a method whereby the sink can		environments there needs to be a method whereby the sink can
	distinguish between packets from the various sources, that is to say,		distinguish between packets from the various sources, that is to say,
	that a multi-point to multi-point measurement model needs to be		that a multi-point to multi-point measurement model needs to be
	developed.		developed.
	2. Requirements Language		2. 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 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	3. Loss Measurement Considerations		3. Loss Measurement Considerations
	Modern networks, if not oversubscribed, normally drop very few		Modern networks, if not oversubscribed, normally drop very few
	packets, thus packet loss measurement is highly sensitive to counter		packets, thus packet loss measurement is highly sensitive to counter
	errors. Without some form of coloring or batch marking such as that		errors. Without some form of coloring or batch marking such as that
	proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve		proposed in [I-D.tempia-ippm-p3m] it may not be possible to achieve
	the required accuracy in the loss measurement of customer data		the required accuracy in the loss measurement of customer data
	traffic. Thus where accuracy better than the data link loss		traffic. Thus where accuracy better than the data link loss
	performance of a modern optical network is required, it may be		performance of a modern optical network is required, it may be
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	Where this level of accuracy is required and the traffic between a		Where this level of accuracy is required and the traffic between a
	source-destination pair is subject to Equal-Cost Multipath (ECMP) a		source-destination pair is subject to Equal-Cost Multipath (ECMP) a
	demarcation mechanism is needed to group the packets into batches.		demarcation mechanism is needed to group the packets into batches.
	Once a batch is correlated at both ingress and egress, the packet		Once a batch is correlated at both ingress and egress, the packet
	accounting mechanism is then able to operate on the batch of packets		accounting mechanism is then able to operate on the batch of packets
	which can be accounted for at both the packet ingress and the packet		which can be accounted for at both the packet ingress and the packet
	egress. Errors in the accounting are particularly acute in Label		egress. Errors in the accounting are particularly acute in Label
	Switched Paths (LSPs) subjected to ECMP because the network transit		Switched Paths (LSPs) subjected to ECMP because the network transit
	time will be different for the various ECMP paths since:		time will be different for the various ECMP paths since:
	a. The packets may traverse different sets of LSRs.		1. The packets may traverse different sets of LSRs.
	b. The packets may depart from different interfaces on different		2. The packets may depart from different interfaces on different
	line cards on LSRs		line cards on LSRs
	c. The packets may arrive at different interfaces on different line		3. The packets may arrive at different interfaces on different line
	cards on LSRs.		cards on LSRs.
	A consideration in modifying the identity label (the MPLS label		A consideration in modifying the identity label (the MPLS label
	ordinarily used to identify the LSP, Virtual Private Network,		ordinarily used to identify the LSP, Virtual Private Network,
	Pseudowire etc) to indicate the batch is the impact that this has on		Pseudowire etc) to indicate the batch is the impact that this has on
	the path chosen by the ECMP mechanism. When the member of the ECMP		the path chosen by the ECMP mechanism. When the member of the ECMP
	path set is chosen by deep packet inspection a change of batch		path set is chosen by deep packet inspection a change of batch
	represented by a change of identity label will have no impact on the		represented by a change of identity label will have no impact on the
	ECMP path. Where the path member is chosen by reference to an		ECMP path. Where the path member is chosen by reference to an
	entropy label [RFC6790] then changing the batch identifier will not		entropy label [RFC6790] then changing the batch identifier will not
	skipping to change at page 10, line 38 ¶		skipping to change at page 10, line 38 ¶
	2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <http://www.rfc-editor.org/info/rfc7258>.
	[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating		[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating
	and Retiring Special-Purpose MPLS Labels", RFC 7274,		and Retiring Special-Purpose MPLS Labels", RFC 7274,
	DOI 10.17487/RFC7274, June 2014,		DOI 10.17487/RFC7274, June 2014,
	<http://www.rfc-editor.org/info/rfc7274>.		<http://www.rfc-editor.org/info/rfc7274>.
	Authors' Addresses		Authors' Addresses
	Stewart Bryant		Stewart Bryant
	Independent		Huawei
	Email: stewart.bryant@gmail.com		Email: stewart.bryant@gmail.com
	Carlos Pignataro
	Cisco Systems
	Email: cpignata@cisco.com
	Mach Chen		Mach Chen
	Huawei		Huawei
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Zhenbin Li		Zhenbin Li
	Huawei		Huawei
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
			Carlos Pignataro
			Cisco Systems
			Email: cpignata@cisco.com
	Gregory Mirsky		Gregory Mirsky
	Ericsson		Ericsson
	Email: gregory.mirsky@ericsson.com		Email: gregory.mirsky@eicsson.com
End of changes. 13 change blocks.
	20 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/