< draft-ietf-mpls-forwarding-06.txt		draft-ietf-mpls-forwarding-07.txt >
	MPLS C. Villamizar, Ed.		MPLS C. Villamizar, Ed.
	Internet-Draft OCCNC		Internet-Draft OCCNC
	Intended status: Informational K. Kompella		Intended status: Informational K. Kompella
	Expires: August 01, 2014 Juniper Networks		Expires: August 16, 2014 Juniper Networks
	S. Amante		S. Amante
	Apple Inc.		Apple Inc.
	A. Malis		A. Malis
	Huawei		Huawei
	C. Pignataro		C. Pignataro
	Cisco		Cisco
	January 28, 2014		February 12, 2014
	MPLS Forwarding Compliance and Performance Requirements		MPLS Forwarding Compliance and Performance Requirements
	draft-ietf-mpls-forwarding-06		draft-ietf-mpls-forwarding-07
	Abstract		Abstract
	This document provides guidelines for implementers regarding MPLS		This document provides guidelines for implementers regarding MPLS
	forwarding and a basis for evaluations of forwarding implementations.		forwarding and a basis for evaluations of forwarding implementations.
	Guidelines cover many aspects of MPLS forwarding. Topics are		Guidelines cover many aspects of MPLS forwarding. Topics are
	highlighted where implementers might otherwise overlook practical		highlighted where implementers might otherwise overlook practical
	requirements which are unstated or under emphasized or are optional		requirements which are unstated or under emphasized or are optional
	for conformance to RFCs but are often considered mandatory by		for conformance to RFCs but are often considered mandatory by
	providers.		providers.
	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 August 01, 2014.		This Internet-Draft will expire on August 16, 2014.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Document Scope . . . . . . . . . . . . . . . 3		1. Introduction and Document Scope . . . . . . . . . . . . . . . 3
	1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Use of Requirements Language . . . . . . . . . . . . . . 8		1.2. Use of Requirements Language . . . . . . . . . . . . . . 8
	1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 8		1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 8
	1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10		1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
	2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10		2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10
	2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10		2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 10
	2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11		2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 11
	2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 12		2.1.2. MPLS Differentiated Services . . . . . . . . . . . . 13
	2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13		2.1.3. Time Synchronization . . . . . . . . . . . . . . . . 13
	2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14		2.1.4. Uses of Multiple Label Stack Entries . . . . . . . . 14
	2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15		2.1.5. MPLS Link Bundling . . . . . . . . . . . . . . . . . 15
	2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15		2.1.6. MPLS Hierarchy . . . . . . . . . . . . . . . . . . . 15
	2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 15		2.1.7. MPLS Fast Reroute (FRR) . . . . . . . . . . . . . . . 16
	2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16		2.1.8. Pseudowire Encapsulation . . . . . . . . . . . . . . 16
	2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 16		2.1.8.1. Pseudowire Sequence Number . . . . . . . . . . . 17
	2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18		2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
	2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 18		2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . 19
	2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 19		2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . 20
	2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21		2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21
	2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22		2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 22
	2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23		2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . 23
	2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23		2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 23
	2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 23		2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . 24
	2.4.5. Fields Used for Multipath Load Balance . . . . . . . 24		2.4.5. Fields Used for Multipath Load Balance . . . . . . . 24
	2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24		2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . 24
	2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 26		2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . 26
	2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 28		2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 28
	2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 28		2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . 28
	2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 28		2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 29
	2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 29		2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 29
	2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 29		2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . 29
	2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 31		2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . 31
	2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 32		2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . 32
	2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 32		2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 33
	2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 34		2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 34
	2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 34		2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 35
	2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 35		2.7. Number and Size of Flows . . . . . . . . . . . . . . . . 36
	3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 36		3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 36
	3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 36		3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 36
	3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38		3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 38
	3.3. Multipath Capabilities and Performance . . . . . . . . . 38		3.3. Multipath Capabilities and Performance . . . . . . . . . 39
	3.4. Pseudowire Capabilities and Performance . . . . . . . . . 39		3.4. Pseudowire Capabilities and Performance . . . . . . . . . 39
	3.5. Entropy Label Support and Performance . . . . . . . . . . 39		3.5. Entropy Label Support and Performance . . . . . . . . . . 40
	3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 40		3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 40
	3.7. OAM Capabilities and Performance . . . . . . . . . . . . 40		3.7. OAM Capabilities and Performance . . . . . . . . . . . . 40
	4. Forwarding Compliance and Performance Testing . . . . . . . . 40		4. Forwarding Compliance and Performance Testing . . . . . . . . 41
	4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 41		4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . 41
	4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 41		4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 42
	4.3. Multipath Capabilities and Performance . . . . . . . . . 42		4.3. Multipath Capabilities and Performance . . . . . . . . . 42
	4.4. Pseudowire Capabilities and Performance . . . . . . . . . 43		4.4. Pseudowire Capabilities and Performance . . . . . . . . . 43
	4.5. Entropy Label Support and Performance . . . . . . . . . . 43		4.5. Entropy Label Support and Performance . . . . . . . . . . 44
	4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 44		4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . 44
	4.7. OAM Capabilities and Performance . . . . . . . . . . . . 45		4.7. OAM Capabilities and Performance . . . . . . . . . . . . 45
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 46		7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 46		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
	8.1. Normative References . . . . . . . . . . . . . . . . . . 46		8.1. Normative References . . . . . . . . . . . . . . . . . . 49
	8.2. Informative References . . . . . . . . . . . . . . . . . 49		8.2. Informative References . . . . . . . . . . . . . . . . . 51
	Appendix A. Organization of References Section . . . . . . . . . 54		Appendix A. Organization of References Section . . . . . . . . . 56
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction and Document Scope		1. Introduction and Document Scope
	The initial purpose of this document was to address concerns raised		The initial purpose of this document was to address concerns raised
	on the MPLS WG mailing list about shortcomings in implementations of		on the MPLS WG mailing list about shortcomings in implementations of
	MPLS forwarding. Documenting existing misconceptions and potential		MPLS forwarding. Documenting existing misconceptions and potential
	pitfalls might potentially avoid repeating past mistakes. The		pitfalls might potentially avoid repeating past mistakes. The
	document has grown to address a broad set of forwarding requirements.		document has grown to address a broad set of forwarding requirements.
	The focus of this document is MPLS forwarding, base pseudowire		The focus of this document is MPLS forwarding, base pseudowire
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	interfaces today operate at 1 Gb/s or greater. It is assumed that		interfaces today operate at 1 Gb/s or greater. It is assumed that
	all forwarding operations are implemented in specialized forwarding		all forwarding operations are implemented in specialized forwarding
	hardware rather than on a general purpose processor. This is often		hardware rather than on a general purpose processor. This is often
	referred to as "fast path" and "slow path" processing. Some		referred to as "fast path" and "slow path" processing. Some
	recommendations are made regarding implementing control or management		recommendations are made regarding implementing control or management
	plane functionality in specialized hardware or with limited		plane functionality in specialized hardware or with limited
	assistance from specialized hardware. This advise is based on		assistance from specialized hardware. This advise is based on
	expected control or management protocol loads and on the need for		expected control or management protocol loads and on the need for
	denial of service (DoS) protection.		denial of service (DoS) protection.
	1.1. Acronyms		1.1. Abbreviations
	The following acronyms are used.		The following abbreviations are used.
	AC Attachment Circuit ([RFC3985])		AC Attachment Circuit ([RFC3985])
	ACH Associated Channel Header (pseudowires)		ACH Associated Channel Header (pseudowires)
	ACK Acknowledgement (TCP flag and type of TCP packet)		ACK Acknowledgement (TCP flag and type of TCP packet)
	AIS Alarm Indication Signal (MPLS-TP OAM)		AIS Alarm Indication Signal (MPLS-TP OAM)
	ATM Asynchronous Transfer Mode (legacy switched circuits)		ATM Asynchronous Transfer Mode (legacy switched circuits)
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	LDP Label Distribution Protocol ([RFC5036])		LDP Label Distribution Protocol ([RFC5036])
	LER Label Edge Router ([RFC3031])		LER Label Edge Router ([RFC3031])
	LM Loss Measurement (MPLS-TP OAM)		LM Loss Measurement (MPLS-TP OAM)
	LSP Label Switched Path ([RFC3031])		LSP Label Switched Path ([RFC3031])
	LSR Label Switching Router ([RFC3031])		LSR Label Switching Router ([RFC3031])
	MP2MP Multipoint to Point		MP2MP Multipoint to Multipoint
	MPLS MultiProtocol Label Switching ([RFC3031])		MPLS MultiProtocol Label Switching ([RFC3031])
	MPLS-TP MPLS Transport Profile ([RFC5317])		MPLS-TP MPLS Transport Profile ([RFC5317])
	Mb/s Megabits per second (million bits per second)		Mb/s Megabits per second (million bits per second)
	NSP Native Service Processing ([RFC3985])		NSP Native Service Processing ([RFC3985])
	NTP Network Time Protocol		NTP Network Time Protocol
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	P2MP Point to Multi-Point		P2MP Point to Multi-Point
	PE Provider Edge router (LDP, RSVP-TE, other protocols)		PE Provider Edge router (LDP, RSVP-TE, other protocols)
	PHB Per-Hop-Behavior ([RFC2475])		PHB Per-Hop-Behavior ([RFC2475])
	PHP Penultimate Hop Popping ([RFC3443])		PHP Penultimate Hop Popping ([RFC3443])
	POS Packet over SONET		POS Packet over SONET
	PSC This acronym has multiple interpretations.		PSC This abbreviation has multiple interpretations.
	1. Packet Switch Capable ([RFC3471]		1. Packet Switch Capable ([RFC3471]
	2. PHB Scheduling Class ([RFC3270])		2. PHB Scheduling Class ([RFC3270])
	3. Protection State Coordination ([RFC6378])		3. Protection State Coordination ([RFC6378])
	PTP Precision Time Protocol		PTP Precision Time Protocol
	PW Pseudowire		PW Pseudowire
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	3. In networks where deep label stacks are encountered, they are not		3. In networks where deep label stacks are encountered, they are not
	rare. Full packet rate performance is required regardless of		rare. Full packet rate performance is required regardless of
	label stack depth, except where multiple pop operations are		label stack depth, except where multiple pop operations are
	required. See Section 2.1.		required. See Section 2.1.
	4. Research has shown that long bursts of short packets with 40 byte		4. Research has shown that long bursts of short packets with 40 byte
	or 44 byte IP payload sizes in these bursts are quite common.		or 44 byte IP payload sizes in these bursts are quite common.
	This is due to TCP ACK compression [ACK-compression]. The		This is due to TCP ACK compression [ACK-compression]. The
	following two sub-bullets constitutes advice that reflects very		following two sub-bullets constitutes advice that reflects very
	common hard requirements of providers. Implementers may ignore		common non-negotiable requirements of providers. Implementers
	this advice but should consider the risk of doing so.		may ignore this advice but should consider the risk of doing so.
	a. A forwarding engine SHOULD, if practical, be able to sustain		a. A forwarding engine SHOULD, if practical, be able to sustain
	an arbitrarily long sequence of small packets arriving at		an arbitrarily long sequence of small packets arriving at
	full interface rate.		full interface rate.
	b. If indefinite full packet rate for small packets is not		b. If indefinite full packet rate for small packets is not
	practical, a forwarding engine MUST be able to buffer a long		practical, a forwarding engine MUST be able to buffer a long
	sequence of small packets inbound to the on-chip decision		sequence of small packets inbound to the on-chip decision
	engine and sustain full interface rate for some reasonable		engine and sustain full interface rate for some reasonable
	average packet rate. Absent this small on-chip buffering,		average packet rate. Absent this small on-chip buffering,
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 36 ¶
	3. Provide a checklist of features and performance specifications to		3. Provide a checklist of features and performance specifications to
	request. (audience: systems designer, deployer)		request. (audience: systems designer, deployer)
	4. Provide a set of tests to perform. (audience: systems designer,		4. Provide a set of tests to perform. (audience: systems designer,
	deployer).		deployer).
	The implementer, systems designer, and deployer have a transitive		The implementer, systems designer, and deployer have a transitive
	supplier customer relationship. It is in the best interest of the		supplier customer relationship. It is in the best interest of the
	supplier to review their product against their customer's checklist		supplier to review their product against their customer's checklist
	and customer's customer's checklist if applicable.		and secondary customer's checklist if applicable.
			This document identifies and explains many details and potential pit-
			falls of MPLS forwarding. It is likely that the identified set of
			potential pit-falls will later prove to be an incomplete set.
	2. Forwarding Issues		2. Forwarding Issues
	A brief review of forwarding issues is provided in the subsections		A brief review of forwarding issues is provided in the subsections
	that follow. This section provides some background on why some of		that follow. This section provides some background on why some of
	these requirements exist. The questions to ask of suppliers is		these requirements exist. The questions to ask of suppliers is
	covered in Section 3. Some guidelines for testing are provided in		covered in Section 3. Some guidelines for testing are provided in
	Section 4.		Section 4.
	2.1. Forwarding Basics		2.1. Forwarding Basics
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 26 ¶
	the labels to a general purpose CPU or other highly programmable		the labels to a general purpose CPU or other highly programmable
	hardware. For example, ELI will only be sent to LSR which have		hardware. For example, ELI will only be sent to LSR which have
	signaled support for [RFC6790] and high OAM packet rate must be		signaled support for [RFC6790] and high OAM packet rate must be
	negotiated among endpoints.		negotiated among endpoints.
	[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not		[RFC3429] reserves a label for ITU-T Y.1711, however Y.1711 does not
	work with multipath and its use is strongly discouraged.		work with multipath and its use is strongly discouraged.
	The current list of special purpose labels can be found on the		The current list of special purpose labels can be found on the
	"Multiprotocol Label Switching Architecture (MPLS) Label Values"		"Multiprotocol Label Switching Architecture (MPLS) Label Values"
	registry reachable at IANA's pages at http://www.iana.org.		registry reachable at IANA's pages at [1].
	[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended		[I-D.ietf-mpls-special-purpose-labels] introduces an IANA "Extended
	Special Purpose MPLS Label Values" registry and makes use of the		Special Purpose MPLS Label Values" registry and makes use of the
	"extension" label, label 15, to indicate that the next label is an		"extension" label, label 15, to indicate that the next label is an
	extended special purpose label and requires special handling. The		extended special purpose label and requires special handling. The
	range of only 16 values for special purpose labels allows a table to		range of only 16 values for special purpose labels allows a table to
	be used. The range of extended special purpose labels with 20 bits		be used. The range of extended special purpose labels with 20 bits
	available for use may have to be handled in some other way in the		available for use may have to be handled in some other way in the
	unlikely event that in the future the range of currently reserved		unlikely event that in the future the range of currently reserved
	values 256-1048575 are used. If only the standards action range,		values 256-1048575 are used. If only the standards action range,
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 11 ¶
	general purpose CPU by default. If this capability is supported,		general purpose CPU by default. If this capability is supported,
	there must be an option to either drop or rate limit such packets on		there must be an option to either drop or rate limit such packets on
	a per special purpose label value basis.		a per special purpose label value basis.
	2.1.2. MPLS Differentiated Services		2.1.2. MPLS Differentiated Services
	[RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence		[RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence
	(Prec) fields and replaces them with the Differentiated Services		(Prec) fields and replaces them with the Differentiated Services
	Field more commonly known as the Differentiated Services Code Point		Field more commonly known as the Differentiated Services Code Point
	(DSCP) field. [RFC2475] defines the Differentiated Services		(DSCP) field. [RFC2475] defines the Differentiated Services
	architecture, which in other forum is often called a Quality of		architecture, which in other forums, is often called a Quality of
	Service (QoS) architecture.		Service (QoS) architecture.
	MPLS uses the Traffic Class (TC) field to support Differentiated		MPLS uses the Traffic Class (TC) field to support Differentiated
	Services [RFC5462]. There are two primary documents describing how		Services [RFC5462]. There are two primary documents describing how
	DSCP is mapped into TC.		DSCP is mapped into TC.
	1. [RFC3270] defines E-LSP and L-LSP. E-LSP use a static mapping of		1. [RFC3270] defines E-LSP and L-LSP. E-LSP use a static mapping of
	DSCP into TC. L-LSP uses a per LSP mapping of DSCP into TC, with		DSCP into TC. L-LSP uses a per LSP mapping of DSCP into TC, with
	one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use		one PHB Scheduling Class (PSC) per L-LSP. Each PSC can use
	multiple Per-Hop Behavior (PHB) values. For example, the Assured		multiple Per-Hop Behavior (PHB) values. For example, the Assured
	skipping to change at page 16, line 13 ¶		skipping to change at page 16, line 27 ¶
	or otherwise switched over. The use of detour FRR doubles the number		or otherwise switched over. The use of detour FRR doubles the number
	of LSP terminating at any given hop and will increase the number of		of LSP terminating at any given hop and will increase the number of
	LSP within a network by a factor dependent on the average detour path		LSP within a network by a factor dependent on the average detour path
	length.		length.
	The bypass method makes use of a tunnel that is unused when no fault		The bypass method makes use of a tunnel that is unused when no fault
	exists but may carry many LSP when a local repair is required. There		exists but may carry many LSP when a local repair is required. There
	is no presignaling indicating which working LSP will be diverted into		is no presignaling indicating which working LSP will be diverted into
	any specific bypass LSP. The merge LSR (egress LSR of the bypass		any specific bypass LSP. The merge LSR (egress LSR of the bypass
	LSP) MUST use platform label space (as defined in [RFC3031]) so that		LSP) MUST use platform label space (as defined in [RFC3031]) so that
	an LSP working path on any give interface can be backed up using a		an LSP working path on any given interface can be backed up using a
	bypass LSP terminating on any other interface. Hardware assistance		bypass LSP terminating on any other interface. Hardware assistance
	is needed if necessary to accomplish local repair of a large number		is needed if necessary to accomplish local repair of a large number
	of LSP within the 10s of milliseconds target. For each affected LSP		of LSP within the 10s of milliseconds target. For each affected LSP
	a swap operation must be reprogrammed or otherwise switched over with		a swap operation must be reprogrammed or otherwise switched over with
	an additional push of the bypass LSP label. The use of platform		an additional push of the bypass LSP label. The use of platform
	label space impacts the size of the LSR ILM for LSR with a very large		label space impacts the size of the LSR ILM for LSR with a very large
	number of interfaces.		number of interfaces.
	2.1.8. Pseudowire Encapsulation		2.1.8. Pseudowire Encapsulation
	skipping to change at page 16, line 46 ¶		skipping to change at page 17, line 11 ¶
	The pseudowire encapsulation is out of scope for this document.		The pseudowire encapsulation is out of scope for this document.
	Pseudowire impact on MPLS forwarding at midpoint LSR is within scope.		Pseudowire impact on MPLS forwarding at midpoint LSR is within scope.
	The impact on ingress MPLS push and egress MPLS UHP pop are within		The impact on ingress MPLS push and egress MPLS UHP pop are within
	scope. While pseudowire encapsulation is out of scope, some advice		scope. While pseudowire encapsulation is out of scope, some advice
	is given on sequence number support.		is given on sequence number support.
	2.1.8.1. Pseudowire Sequence Number		2.1.8.1. Pseudowire Sequence Number
	Pseudowire (PW) sequence number support is most important for PW		Pseudowire (PW) sequence number support is most important for PW
	payload types with a high expectation of lossless and/or in-order		payload types with a high expectation of lossless and/or in-order
	delivery. Identifying lost PW packets and exact amount of lost		delivery. Identifying lost PW packets and the exact amount of lost
	payload is critical for PW services which maintain bit timing, such		payload is critical for PW services which maintain bit timing, such
	as Time Division Multiplexing (TDM) services since these services		as Time Division Multiplexing (TDM) services since these services
	MUST compensate lost payload on a bit-for-bit basis.		MUST compensate lost payload on a bit-for-bit basis.
	With PW services which maintain bit timing, packets that have been		With PW services which maintain bit timing, packets that have been
	received out of order also MUST be identified and may be either re-		received out of order also MUST be identified and MAY be either re-
	ordered or dropped. Reordering requires, in addition to sequence		ordered or dropped. Resequencing requires, in addition to sequence
	numbering, a "reorder buffer" in the egress PE, and ability to		numbering, a "reorder buffer" in the egress PE, and ability to
	reorder is limited by the depth of this buffer. The down side of		reorder is limited by the depth of this buffer. The down side of
	maintaining a large reorder buffer is added end-to-end service delay.		maintaining a large reorder buffer is added end-to-end service delay.
	For PW services which maintain bit timing or any other service where		For PW services which maintain bit timing or any other service where
	jitter must be bounded, a jitter buffer is always necessary. The		jitter must be bounded, a jitter buffer is always necessary. The
	jitter buffer is needed regardless of whether reordering is done. In		jitter buffer is needed regardless of whether reordering is done. In
	order to be effective, a reorder buffer must often be larger than a		order to be effective, a reorder buffer must often be larger than a
	jitter buffer needs to be creating a tradeoff between reducing loss		jitter buffer needs to be creating a tradeoff between reducing loss
	and minimizing delay.		and minimizing delay.
	skipping to change at page 17, line 36 ¶		skipping to change at page 17, line 47 ¶
	MPLS-TP, then this reordering may be acceptable.		MPLS-TP, then this reordering may be acceptable.
	Reducing jitter is best done by an end-system, given that the		Reducing jitter is best done by an end-system, given that the
	tradeoff of loss vs delay varies among services. For example with		tradeoff of loss vs delay varies among services. For example with
	interactive real time services low delay is preferred, while with		interactive real time services low delay is preferred, while with
	non-interactive (one way) real time services low loss is preferred.		non-interactive (one way) real time services low loss is preferred.
	The same end-site may be receiving both types of traffic. Regardless		The same end-site may be receiving both types of traffic. Regardless
	of this, bounded jitter is sometimes a requirement for specific		of this, bounded jitter is sometimes a requirement for specific
	deployments.		deployments.
	Packet reorder should be rare except in a small number of		Packet reordering should be rare except in a small number of
	circumstances, most of which are due to network design or equipment		circumstances, most of which are due to network design or equipment
	design errors:		design errors:
	1. The most common case is where reordering is rare, occurring only		1. The most common case is where reordering is rare, occurring only
	when a network or equipment fault forces traffic on a new path		when a network or equipment fault forces traffic on a new path
	with different delay. The packet loss that accompanies a network		with different delay. The packet loss that accompanies a network
	or equipment fault is generally more disruptive than any		or equipment fault is generally more disruptive than any
	reordering which may occur.		reordering which may occur.
	2. A path change can be caused by reasons other than a network or		2. A path change can be caused by reasons other than a network or
	skipping to change at page 23, line 34 ¶		skipping to change at page 24, line 4 ¶
	significantly. Therefore in a network where a significant number of		significantly. Therefore in a network where a significant number of
	parallel 10 Gb/s links exists, even a 1 Gb/s pseudowire or other		parallel 10 Gb/s links exists, even a 1 Gb/s pseudowire or other
	large microflow that could not otherwise be subdivided into smaller		large microflow that could not otherwise be subdivided into smaller
	flows should carry a flow label or entropy label if possible.		flows should carry a flow label or entropy label if possible.
	Active management of the hash space to better accommodate large		Active management of the hash space to better accommodate large
	microflows has been implemented and deployed in the past, however		microflows has been implemented and deployed in the past, however
	such techniques are out of scope for this document.		such techniques are out of scope for this document.
	2.4.3. Pseudowire Flow Label		2.4.3. Pseudowire Flow Label
	Unlike a pseudowire control word, a pseudowire flow label [RFC6391],		Unlike a pseudowire control word, a pseudowire flow label [RFC6391],
	is required only for relatively large capacity pseudowires. There		is required only for relatively large capacity pseudowires. There
	are many cases where a pseudowire flow label makes sense. Any		are many cases where a pseudowire flow label makes sense. Any
	service such as a VPN which carries IP traffic within a pseudowire		service such as a VPN which carries IP traffic within a pseudowire
	can make use of a pseudowire flow label.		can make use of a pseudowire flow label.
	Any pseudowire carried over MPLS which makes use of the pseudowire		Any pseudowire carried over MPLS which makes use of the pseudowire
	control word and does not carry a flow label is in effect a single		control word and does not carry a flow label is in effect a single
	microflow (in [RFC2475] terms) and may result in the types of		microflow (in [RFC2475] terms) and may result in the types of
	problems described in Section 2.4.2.		problems described in Section 2.4.2.
	2.4.4. MPLS Entropy Label		2.4.4. MPLS Entropy Label
	The MPLS entropy label simplifies flow group identification [RFC6790]		The MPLS entropy label simplifies flow group identification [RFC6790]
	at midpoint LSR. Prior to the MPLS entropy label midpoint LSR needed		at midpoint LSRs. Prior to the MPLS entropy label midpoint LSRs
	to inspect the entire label stack and often the IP headers to provide		needed to inspect the entire label stack and often the IP headers to
	an adequate distribution of traffic when using multipath techniques		provide an adequate distribution of traffic when using multipath
	(see Section 2.4.5). With the use of MPLS entropy label, a hash can		techniques (see Section 2.4.5). With the use of MPLS entropy label,
	be performed closer to network edges, placed in the label stack, and		a hash can be performed closer to network edges, placed in the label
	used by midpoint LSR without fully reinspecting the label stack and		stack, and used by midpoint LSRs without fully reinspecting the label
	inspecting the payload.		stack and inspecting the payload.
	The MPLS entropy label is capable of avoiding full label stack and		The MPLS entropy label is capable of avoiding full label stack and
	payload inspection within the core where performance levels are most		payload inspection within the core where performance levels are most
	difficult to achieve (see Section 2.3). The label stack inspection		difficult to achieve (see Section 2.3). The label stack inspection
	can be terminated as soon as the first entropy label is encountered,		can be terminated as soon as the first entropy label is encountered,
	which is generally after a small number of labels are inspected.		which is generally after a small number of labels are inspected.
	In order to provide these benefits in the core, LSR closer to the		In order to provide these benefits in the core, LSR closer to the
	edge must be capable of adding an entropy label. This support may		edge must be capable of adding an entropy label. This support may
	not be required in the access tier, the tier closest to the customer,		not be required in the access tier, the tier closest to the customer,
	skipping to change at page 25, line 24 ¶		skipping to change at page 25, line 43 ¶
	5. The most entropy is generally found in the label stack entries		5. The most entropy is generally found in the label stack entries
	near the bottom of the label stack (innermost label, closest to		near the bottom of the label stack (innermost label, closest to
	S=1 bit). If the entire label stack cannot be used (or entire		S=1 bit). If the entire label stack cannot be used (or entire
	stack up to an EL), then it is better to use as many labels as		stack up to an EL), then it is better to use as many labels as
	possible closest to the bottom of stack.		possible closest to the bottom of stack.
	6. If no ELI is encountered, and the first nibble of payload		6. If no ELI is encountered, and the first nibble of payload
	contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support		contains a 4 (IPv4) or 6 (IPv6), an implementation SHOULD support
	the ability to interpret the payload as IPv4 or IPv6 and extract		the ability to interpret the payload as IPv4 or IPv6 and extract
	and use appropriate fields from the IP headers. This feature is		and use appropriate fields from the IP headers. This feature is
	considered a hard requirement by many service providers. If		considered a non-negotiable requirement by many service
	supported, there MUST be a way to disable it (if, for example, PW		providers. If supported, there MUST be a way to disable it (if,
	without CW are used). This ability to disable this feature is		for example, PW without CW are used). This ability to disable
	considered a hard requirement by many service providers.		this feature is considered a non-negotiable requirement by many
	Therefore an implementation has a very strong incentive to		service providers. Therefore an implementation has a very strong
	support both options.		incentive to support both options.
	7. A label which is popped at egress (UHP pop) SHOULD NOT be used.		7. A label which is popped at egress (UHP pop) SHOULD NOT be used.
	A label which is popped at the penultimate hop (PHP pop) SHOULD		A label which is popped at the penultimate hop (PHP pop) SHOULD
	be used.		be used.
	Apparently some chips have made use of the TC (formerly EXP) bits as		Apparently some chips have made use of the TC (formerly EXP) bits as
	a source of entropy. This is very harmful since it will reorder		a source of entropy. This is very harmful since it will reorder
	Assured Forwarding (AF) traffic [RFC2597] when a subset does not		Assured Forwarding (AF) traffic [RFC2597] when a subset does not
	conform to the configured rates and is remarked but not dropped at a		conform to the configured rates and is remarked but not dropped at a
	prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be		prior LSR. Traffic which uses MPLS ECN [RFC5129] can also be
	skipping to change at page 26, line 42 ¶		skipping to change at page 27, line 16 ¶
	used. There MAY be an option to reverse the order of these		used. There MAY be an option to reverse the order of these
	addresses, improving the ability to provide symmetric paths in		addresses, improving the ability to provide symmetric paths in
	some cases. Many service providers require that both addresses		some cases. Many service providers require that both addresses
	be used.		be used.
	2. Implementations SHOULD allow inspection of the IP protocol field		2. Implementations SHOULD allow inspection of the IP protocol field
	and use of the UDP or TCP port numbers. For many service		and use of the UDP or TCP port numbers. For many service
	providers this feature is considered mandatory, particularly for		providers this feature is considered mandatory, particularly for
	enterprise, data center, or edge equipment. If this feature is		enterprise, data center, or edge equipment. If this feature is
	provided, it SHOULD be possible to disable use of TCP and UDP		provided, it SHOULD be possible to disable use of TCP and UDP
	ports. Many service providers consider it a hard requirement		ports. Many service providers consider it a non-negotiable
	that use of UDP and TCP ports can be disabled. Therefore there		requirement that use of UDP and TCP ports can be disabled.
	is a stong incentive for implementations to provide both options.		Therefore there is a strong incentive for implementations to
			provide both options.
	3. Equipment suppliers MUST NOT make assumptions that because the IP		3. Equipment suppliers MUST NOT make assumptions that because the IP
	version field is equal to 4 (an IPv4 packet) that the IP protocol		version field is equal to 4 (an IPv4 packet) that the IP protocol
	will either be TCP (IP protocol 6) or UDP (IP protocol 17) and		will either be TCP (IP protocol 6) or UDP (IP protocol 17) and
	blindly fetch the data at the offset where the TCP or UDP ports		blindly fetch the data at the offset where the TCP or UDP ports
	would be found. With IPv6, TCP and UDP port numbers are not at		would be found. With IPv6, TCP and UDP port numbers are not at
	fixed offsets. With IPv4 packets carrying IP options, TCP and		fixed offsets. With IPv4 packets carrying IP options, TCP and
	UDP port numbers are not at fixed offsets.		UDP port numbers are not at fixed offsets.
	4. The IPv6 header flow field SHOULD be used. This is the explicit		4. The IPv6 header flow field SHOULD be used. This is the explicit
	skipping to change at page 30, line 17 ¶		skipping to change at page 30, line 24 ¶
	isolation from potentially malicious payload. Used alone, the		isolation from potentially malicious payload. Used alone, the
	compromise of a single node, including a small computer at a		compromise of a single node, including a small computer at a
	network operations center, could compromise an entire network.		network operations center, could compromise an entire network.
	Implementations which send all G-ACh/GAL traffic directly to a		Implementations which send all G-ACh/GAL traffic directly to a
	routing engine CPU are subject to DoS attack as a result of such		routing engine CPU are subject to DoS attack as a result of such
	a compromise.		a compromise.
	Cryptographic Authentication		Cryptographic Authentication
	Cryptographic authentication can very effectively prevent		Cryptographic authentication can very effectively prevent
	malicious injection of control or management traffic.		malicious injection of control or management traffic.
	Cryptographic authentication can is some circumstances be subject		Cryptographic authentication can in some circumstances be subject
	to DoS attack by overwhelming the capacity of the decryption with		to DoS attack by overwhelming the capacity of the decryption with
	a high volume of malicious traffic. For very low speed		a high volume of malicious traffic. For very low speed
	interfaces, cryptographic authentication can be performed by the		interfaces, cryptographic authentication can be performed by the
	general purpose CPU used as a routing engine. For all other		general purpose CPU used as a routing engine. For all other
	cases, cryptographic hardware may be needed. For very high speed		cases, cryptographic hardware may be needed. For very high speed
	interfaces, even cryptographic hardware can be overwhelmed.		interfaces, even cryptographic hardware can be overwhelmed.
	Some control and management protocols are often carried with payload		Some control and management protocols are often carried with payload
	traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is		traffic. This is commonly the case with BGP, T-LDP, and SNMP. It is
	often the case with RSVP-TE. Even when carried over G-ACh/GAL		often the case with RSVP-TE. Even when carried over G-ACh/GAL
	skipping to change at page 36, line 4 ¶		skipping to change at page 36, line 13 ¶
	forwarding hardware.		forwarding hardware.
	The customer (system supplier or provider) should not dictate design,		The customer (system supplier or provider) should not dictate design,
	but should independently validate target functionality and		but should independently validate target functionality and
	performance. However, it is not uncommon for service providers and		performance. However, it is not uncommon for service providers and
	system implementers to insist on reviewing design details (under NDA)		system implementers to insist on reviewing design details (under NDA)
	due to past experiences with suppliers and to reject suppliers who		due to past experiences with suppliers and to reject suppliers who
	are unwilling to provide details.		are unwilling to provide details.
	2.7. Number and Size of Flows		2.7. Number and Size of Flows
	Service provider networks may carry up to hundreds of millions of		Service provider networks may carry up to hundreds of millions of
	flows on 10 Gb/s links. Most flows are very short lived, many under		flows on 10 Gb/s links. Most flows are very short lived, many under
	a second. A subset of the flows are low capacity and somewhat long		a second. A subset of the flows are low capacity and somewhat long
	lived. When Internet traffic dominates capacity a very small subset		lived. When Internet traffic dominates capacity a very small subset
	of flows are high capacity and/or very long lived.		of flows are high capacity and/or very long lived.
	Two types of limitations with regard to number and size of flows have		Two types of limitations with regard to number and size of flows have
	been observed.		been observed.
	1. Some hardware cannot handle some very large flows because of		1. Some hardware cannot handle some high capacity flows because of
	internal paths which are limited, such as per packet backplane		internal paths which are limited, such as per packet backplane
	paths or paths internal or external to chips such as buffer		paths or paths internal or external to chips such as buffer
	memory paths. Such designs can handle aggregates of smaller		memory paths. Such designs can handle aggregates of smaller
	flows. Some hardware with acknowledged limitations has been		flows. Some hardware with acknowledged limitations has been
	successfully deployed but may be increasingly problematic if the		successfully deployed but may be increasingly problematic if the
	capacity of large microflows in deployed networks continues to		capacity of large microflows in deployed networks continues to
	grow.		grow.
	2. Some hardware approaches cannot handle a large number of flows,		2. Some hardware approaches cannot handle a large number of flows,
	or a large number of large flows due to attempting to count per		or a large number of large flows due to attempting to count per
	skipping to change at page 39, line 22 ¶		skipping to change at page 39, line 31 ¶
	be used in the hash? If so, which IP fields, payload types and		be used in the hash? If so, which IP fields, payload types and
	payload fields are supported?		payload fields are supported?
	Q#20 At what maximum MPLS label stack depth can Bottom of Stack and		Q#20 At what maximum MPLS label stack depth can Bottom of Stack and
	an IP header appear without impacting packet rate performance?		an IP header appear without impacting packet rate performance?
	Q#21 Are special purpose labels excluded from the label stack hash?		Q#21 Are special purpose labels excluded from the label stack hash?
	Are extended purpose labels excluded from the label stack hash?		Are extended purpose labels excluded from the label stack hash?
	See Section 2.4.5.1.		See Section 2.4.5.1.
	Q#22 How is multipath performance affected by very large flows or an		Q#22 How is multipath performance affected by high capacity flows or
	extremely large number of flows, or by very short lived flows?		an extremely large number of flows, or by very short lived flows?
	See Section 2.7.		See Section 2.7.
	3.4. Pseudowire Capabilities and Performance		3.4. Pseudowire Capabilities and Performance
	Q#23 Is the pseudowire control word supported?		Q#23 Is the pseudowire control word supported?
	Q#24 What is the maximum rate of pseudowire encapsulation and		Q#24 What is the maximum rate of pseudowire encapsulation and
	decapsulation? Apply the same questions as in Base Performance		decapsulation? Apply the same questions as in Base Performance
	for any packet based pseudowire such as IP VPN or Ethernet.		for any packet based pseudowire such as IP VPN or Ethernet.
	skipping to change at page 42, line 25 ¶		skipping to change at page 42, line 35 ¶
	test (DUT) is the egress of these LSP. Create test packets such		test (DUT) is the egress of these LSP. Create test packets such
	that the swap operation is performed after pop operations,		that the swap operation is performed after pop operations,
	increasing the number of pop operations until forwarding of small		increasing the number of pop operations until forwarding of small
	packets at full line rate can no longer be supported. Also check		packets at full line rate can no longer be supported. Also check
	to see how many pop operations can be supported before the full		to see how many pop operations can be supported before the full
	set of counters can no longer be maintained. This requirement is		set of counters can no longer be maintained. This requirement is
	particularly relevant for MPLS-TP.		particularly relevant for MPLS-TP.
	T#6 Send all traffic on one LSP and see if the counters become		T#6 Send all traffic on one LSP and see if the counters become
	inaccurate. Often counters on silicon are much smaller than the		inaccurate. Often counters on silicon are much smaller than the
	64 bit packet and byte counters in IETF MIB. System developers		64 bit packet and byte counters in various IETF MIBs. System
	should consider what counter polling rate is necessary to		developers should consider what counter polling rate is necessary
	maintain accurate counters and whether those polling rates are		to maintain accurate counters and whether those polling rates are
	practical. Relevant MIBs for MPLS are discussed in [RFC4221] and		practical. Relevant MIBs for MPLS are discussed in [RFC4221] and
	[RFC6639].		[RFC6639].
	4.3. Multipath Capabilities and Performance		4.3. Multipath Capabilities and Performance
	Multipath capabilities do not apply to MPLS-TP but apply to MPLS and		Multipath capabilities do not apply to MPLS-TP but apply to MPLS and
	apply if MPLS-TP is carried in MPLS.		apply if MPLS-TP is carried in MPLS.
	T#7 Send traffic at a rate well exceeding the capacity of a single		T#7 Send traffic at a rate well exceeding the capacity of a single
	multipath component link, and where entropy exists only below the		multipath component link, and where entropy exists only below the
	skipping to change at page 44, line 28 ¶		skipping to change at page 44, line 42 ¶
	and EL) are removed from the label stack during UHP and PHP		and EL) are removed from the label stack during UHP and PHP
	operations.		operations.
	T#24 Insure that operations on the TC field when adding and removing		T#24 Insure that operations on the TC field when adding and removing
	entropy label are correctly carried out. If TC is changed during		entropy label are correctly carried out. If TC is changed during
	a swap operation, the ability to transfer that change MUST be		a swap operation, the ability to transfer that change MUST be
	provided. The ability to suppress the transfer of TC MUST also		provided. The ability to suppress the transfer of TC MUST also
	be provided. See "pipe", "short pipe", and "uniform" models in		be provided. See "pipe", "short pipe", and "uniform" models in
	[RFC3443].		[RFC3443].
	T#25 Repeat performance tests for midpoint LSR with entropy labels		T#25 Repeat performance tests for a midpoint LSR with entropy labels
	found at various label stack depths.		found at various label stack depths.
	4.6. DoS Protection		4.6. DoS Protection
	T#26 Actively attack LSR under high protocol churn load and determine		T#26 Actively attack LSR under high protocol churn load and determine
	control plane performance impact or successful DoS under test		control plane performance impact or successful DoS under test
	conditions. Specifically test for the following.		conditions. Specifically test for the following.
	a. TCP SYN attack against control plane and management plane		a. TCP SYN attack against control plane and management plane
	protocols using TCP, including CLI access (typically SSH		protocols using TCP, including CLI access (typically SSH
	skipping to change at page 46, line 25 ¶		skipping to change at page 46, line 38 ¶
	Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1		Alexander (Sasha) Vainshtein pointed out errors in Section 2.1.8.1
	and suggested new text which after lengthy discussion resulted in		and suggested new text which after lengthy discussion resulted in
	restating the summarization of requirements from PWE3 RFCs and more		restating the summarization of requirements from PWE3 RFCs and more
	clearly stating the benefits and drawbacks of packet resequencing		clearly stating the benefits and drawbacks of packet resequencing
	based on PW sequence number.		based on PW sequence number.
	Loa Anderson provided useful comments and corrections prior to WGLC.		Loa Anderson provided useful comments and corrections prior to WGLC.
	Adrian Farrel provided useful comments and corrections prior as part		Adrian Farrel provided useful comments and corrections prior as part
	of the AD review.		of the AD review.
			Discussion with Steve Kent during SecDir review resulted in expansion
			of Section 7, briefly summarizing security considerations related to
			forwarding in normative references. Tom Petch pointed out some
			editorial errors in private email. Al Morton during OpsDir review
			prompted clarification in the target audience section, suggested more
			clear wording in places, and found numerous editorial errors.
	6. IANA Considerations		6. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	7. Security Considerations		7. Security Considerations
	This document reviews forwarding behavior specified elsewhere and		This document reviews forwarding behavior specified elsewhere and
	points out compliance and performance requirements. As such it		points out compliance and performance requirements. As such it
	introduces no new security requirements or concerns.		introduces no new security requirements or concerns.
	Some advice on hardware support and other equipment hardening against		Discussion of hardware support and other equipment hardening against
	DoS attack can be found in Section 4.6.		DoS attack can be found in Section 2.6.1. Section 3.6 provides a
			list of question regarding DoS to be asked of suppliers. Section 4.6
			suggests types of testing that can provide some assurance of the
			effectiveness of supplier DoS hardening claims.
	Knowledge of potential performance shortcomings may serve to help new		Knowledge of potential performance shortcomings may serve to help new
	implementations avoid pitfalls. It is unlikely that such knowledge		implementations avoid pitfalls. It is unlikely that such knowledge
	could be the basis of new denial of service as these pitfalls are		could be the basis of new denial of service as these pitfalls are
	already widely known in the service provider community and among		already widely known in the service provider community and among
	leading equipment suppliers. In practice extreme data and packet		leading equipment suppliers. In practice extreme data and packet
	rate are needed to affect existing equipment and to affect networks		rate are needed to affect existing equipment and to affect networks
	that may be still vulnerable due to failure to implement adequate		that may be still vulnerable due to failure to implement adequate
	protection. The extreme data and packet rates make this type of		protection. The extreme data and packet rates make this type of
	denial of service unlikely and make undetectable denial of service of		denial of service unlikely and make undetectable denial of service of
	this type impossible.		this type impossible.
			The set of normative references each contain security considerations.
			A brief summarization of MPLS security considerations applicable to
			forwarding follows:
			1. MPLS encapsulation does not support an authentication extension.
			This is reflected in the security section of [RFC3032].
			Documents which clarify MPLS header fields such as TTL
			[RFC3443], the explicit null label [RFC4182], renaming EXP to TC
			[RFC5462], ECN for MPLS [RFC5129], and MPLS Ethernet
			encapsulation [RFC5332] make no changes to security
			considerations in [RFC3032].
			2. Some cited RFCs are related to Diffserv forwarding. [RFC3270]
			refers to MPLS and Diffserv security. [RFC2474] mentions theft
			of service and denial of service due to mismarking. [RFC2474]
			mentions IPsec interaction, but with MPLS, not being carried by
			IP, this type of interaction in [RFC2474] is not relevant.
			3. [RFC3209] is cited here due only to make-before-break forwarding
			requirements. This is related to resource sharing and the theft
			of service and denial of service concerns in [RFC2474] apply.
			4. [RFC4090] defines FRR which provides protection but does not add
			security concerns. RFC4201 defines link bundling but raises no
			additional security concerns.
			5. Various OAM control channels are defined in [RFC4385] (PW CW),
			[RFC5085] (VCCV), [RFC5586] (G-Ach and GAL). These documents
			describe potential abuse of these OAM control channels.
			6. [RFC4950] defines ICMP extensions when MPLS TTL expires and
			payload is IP. This provides MPLS header information which is
			of no use to an IP attacker, but sending this information can be
			suppressed through configuration.
			7. GTSM [RFC5082] provides a means to improve protection against
			high traffic volume spoofing as a form of DoS attack.
			8. BFD [RFC5880] [RFC5884] [RFC5885] provides a form of OAM used in
			MPLS and MPLS-TP. The security considerations related to the
			OAM control channel are relevant. The BFD payload supports
			authentication unlike the MPLS encapsulation or MPLS or PW
			control channel encapsulation is carried in. Where an IP return
			OAM path is used IPsec is suggested as a means of securing the
			return path.
			9. Other forms of OAM are supported by [RFC6374] [RFC6375] (Loss
			and Delay Measurement), [RFC6428] (Connectivity Check/
			Verification based on BFD), and [RFC6427] (Fault Management).
			The security considerations related to the OAM control channel
			are relevant. IP return paths, where used, can be secured with
			IPsec.
			10. Linear protection is defined by [RFC6378] and updated by
			[I-D.ietf-mpls-psc-updates]. Security concerns related to MPLS
			encapsulation and OAM control channels apply. Security concerns
			reiterate [RFC5920] as applied to protection switching.
			11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790]
			affect multipath load balancing. Security concerns reiterate
			[RFC5920]. Security impacts would be limited to load
			distribution.
			MPLS security including data plane security is discussed in greater
			detail in [RFC5920] (MPLS/GMPLS Security Framework). The MPLS-TP
			security framework [RFC6941] build upon this, focusing largely on the
			MPLS-TP OAM additions and OAM channels with some attention given to
			using network management in place of control plane setup. In both
			security framework documents MPLS is assumed to run within a "trusted
			zone", defined as being where a single service provider (SP) has
			total operational control over that part of the network.
			If control plane security and management plane security are
			sufficiently robust, compromise of a single network element may
			result in chaos in the data plane anywhere in the network through
			denial of service attacks, but not a Byzantine security failure in
			which other network elements are fully compromised.
			MPLS security, or lack of, can affect whether traffic can be
			misrouted and lost, or intercepted, or intercepted and reinserted (a
			man-in-the-middle attack) or spoofed. End user applications,
			including control plane and management plane protocols used by the
			SP, are expected to make use of appropriate end-to-end authentication
			and where appropriate end-to-end encryption.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-mpls-psc-updates]		[I-D.ietf-mpls-psc-updates]
	Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-		Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
	updates-01 (work in progress), January 2014.		updates-01 (work in progress), January 2014.
	[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.
	skipping to change at page 49, line 10 ¶		skipping to change at page 51, line 20 ¶
	[RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,		[RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
	and D. Ward, "MPLS Fault Management Operations,		and D. Ward, "MPLS Fault Management Operations,
	Administration, and Maintenance (OAM)", RFC 6427, November		Administration, and Maintenance (OAM)", RFC 6427, November
	2011.		2011.
	[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive		[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
	Connectivity Verification, Continuity Check, and Remote		Connectivity Verification, Continuity Check, and Remote
	Defect Indication for the MPLS Transport Profile", RFC		Defect Indication for the MPLS Transport Profile", RFC
	6428, November 2011.		6428, November 2011.
	[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
	Mechanism (GTSM) for the Label Distribution Protocol
	(LDP)", RFC 6720, August 2012.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, November 2012.		RFC 6790, November 2012.
	8.2. Informative References		8.2. Informative References
	[ACK-compression]		[ACK-compression]
	, , , "Observations and Dynamics of a Congestion Control		, , , "Observations and Dynamics of a Congestion Control
	Algorithm: The Effects of Two-Way Traffic", Proc. ACM		Algorithm: The Effects of Two-Way Traffic", Proc. ACM
	SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,		SIGCOMM, ACM Computer Communications Review (CCR) Vol 21,
	skipping to change at page 52, line 24 ¶		skipping to change at page 54, line 28 ¶
	2009.		2009.
	[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for		[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
	Operations, Administration, and Maintenance (OAM) in MPLS		Operations, Administration, and Maintenance (OAM) in MPLS
	Transport Networks", RFC 5860, May 2010.		Transport Networks", RFC 5860, May 2010.
	[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network		[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
	Time Protocol Version 4: Protocol and Algorithms		Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, June 2010.
			[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
			Networks", RFC 5920, July 2010.
	[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,		[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
	D., and S. Mansfield, "Guidelines for the Use of the "OAM"		D., and S. Mansfield, "Guidelines for the Use of the "OAM"
	Acronym in the IETF", BCP 161, RFC 6291, June 2011.		Acronym in the IETF", BCP 161, RFC 6291, June 2011.
	[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,		[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
	Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,		Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations,
	Administration, and Maintenance (OAM) Message Mapping",		Administration, and Maintenance (OAM) Message Mapping",
	RFC 6310, July 2011.		RFC 6310, July 2011.
	[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and		[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
	skipping to change at page 53, line 34 ¶		skipping to change at page 55, line 39 ¶
	[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,		[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
	Administration, and Maintenance (OAM) Toolset for MPLS-		Administration, and Maintenance (OAM) Toolset for MPLS-
	Based Transport Networks", RFC 6669, July 2012.		Based Transport Networks", RFC 6669, July 2012.
	[RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a		[RFC6670] Sprecher, N. and KY. Hong, "The Reasons for Selecting a
	Single Solution for MPLS Transport Profile (MPLS-TP)		Single Solution for MPLS Transport Profile (MPLS-TP)
	Operations, Administration, and Maintenance (OAM)", RFC		Operations, Administration, and Maintenance (OAM)", RFC
	6670, July 2012.		6670, July 2012.
			[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
			Mechanism (GTSM) for the Label Distribution Protocol
			(LDP)", RFC 6720, August 2012.
	[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label		[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
	Switched Path (LSP) Ping for Pseudowire Forwarding		Switched Path (LSP) Ping for Pseudowire Forwarding
	Equivalence Classes (FECs) Advertised over IPv6", RFC		Equivalence Classes (FECs) Advertised over IPv6", RFC
	6829, January 2013.		6829, January 2013.
			[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
			Graveman, "MPLS Transport Profile (MPLS-TP) Security
			Framework", RFC 6941, April 2013.
	[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,		[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
	and R. Qiu, "MPLS and Ethernet Operations, Administration,		and R. Qiu, "MPLS and Ethernet Operations, Administration,
	and Maintenance (OAM) Interworking", RFC 7023, October		and Maintenance (OAM) Interworking", RFC 7023, October
	2013.		2013.
	[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS		[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS
	Switching Capability and Type Fields", RFC 7074, November		Switching Capability and Type Fields", RFC 7074, November
	2013.		2013.
	[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and		[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and
End of changes. 49 change blocks.
	71 lines changed or deleted		177 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/