< draft-ietf-mpls-forwarding-01.txt		draft-ietf-mpls-forwarding-02.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: April 12, 2014 Contrail Systems		Expires: April 14, 2014 Contrail Systems
	S. Amante		S. Amante
	Level 3 Communications, Inc.		Level 3 Communications, Inc.
	A. Malis		A. Malis
	Verizon		Verizon
	C. Pignataro		C. Pignataro
	Cisco		Cisco
	October 9, 2013		October 11, 2013
	MPLS Forwarding Compliance and Performance Requirements		MPLS Forwarding Compliance and Performance Requirements
	draft-ietf-mpls-forwarding-01		draft-ietf-mpls-forwarding-02
	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 potentially 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.
	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 April 12, 2014.		This Internet-Draft will expire on April 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 22 ¶		skipping to change at page 2, line 22 ¶
	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 . . . . . . . . . . . . . . . 4		1. Introduction and Document Scope . . . . . . . . . . . . . . . 4
	1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8		1.2. Use of Requirements Language . . . . . . . . . . . . . . . 8
	1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9		1.3. Apparent Misconceptions . . . . . . . . . . . . . . . . . 9
	1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10		1.4. Target Audience . . . . . . . . . . . . . . . . . . . . . 10
	2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 10		2. Forwarding Issues . . . . . . . . . . . . . . . . . . . . . . 11
	2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11		2.1. Forwarding Basics . . . . . . . . . . . . . . . . . . . . 11
	2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 12		2.1.1. MPLS Special Purpose Labels . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . . . . 14
	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 . . . . . . . . . . . . . . . 17		2.1.9. Layer-2 and Layer-3 VPN . . . . . . . . . . . . . . . 18
	2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 18		2.2. MPLS Multicast . . . . . . . . . . . . . . . . . . . . . . 18
	2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 18		2.3. Packet Rates . . . . . . . . . . . . . . . . . . . . . . . 19
	2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 20		2.4. MPLS Multipath Techniques . . . . . . . . . . . . . . . . 21
	2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21		2.4.1. Pseudowire Control Word . . . . . . . . . . . . . . . 21
	2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 22		2.4.2. Large Microflows . . . . . . . . . . . . . . . . . . . 22
	2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22		2.4.3. Pseudowire Flow Label . . . . . . . . . . . . . . . . 22
	2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 22		2.4.4. MPLS Entropy Label . . . . . . . . . . . . . . . . . . 23
	2.4.5. Fields Used for Multipath Load Balance . . . . . . . . 23		2.4.5. Fields Used for Multipath Load Balance . . . . . . . . 23
	2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 23		2.4.5.1. MPLS Fields in Multipath . . . . . . . . . . . . . 23
	2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 25		2.4.5.2. IP Fields in Multipath . . . . . . . . . . . . . . 25
	2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 26		2.4.5.3. Fields Used in Flow Label . . . . . . . . . . . . 27
	2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 27		2.4.5.4. Fields Used in Entropy Label . . . . . . . . . . . 27
	2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27		2.5. MPLS-TP and UHP . . . . . . . . . . . . . . . . . . . . . 27
	2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 27		2.6. Local Delivery of Packets . . . . . . . . . . . . . . . . 28
	2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 28		2.6.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 28
	2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 30		2.6.2. MPLS OAM . . . . . . . . . . . . . . . . . . . . . . . 30
	2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 31		2.6.3. Pseudowire OAM . . . . . . . . . . . . . . . . . . . . 31
	2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31		2.6.4. MPLS-TP OAM . . . . . . . . . . . . . . . . . . . . . 31
	2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 32		2.6.5. MPLS OAM and Layer-2 OAM Interworking . . . . . . . . 33
	2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33		2.6.6. Extent of OAM Support by Hardware . . . . . . . . . . 33
	2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 34		2.7. Number and Size of Flows . . . . . . . . . . . . . . . . . 34
	3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 34		3. Questions for Suppliers . . . . . . . . . . . . . . . . . . . 35
	3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 35		3.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 35
	3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36		3.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 36
	3.3. Multipath Capabilities and Performance . . . . . . . . . . 37		3.3. Multipath Capabilities and Performance . . . . . . . . . . 37
	3.4. Pseudowire Capabilities and Performance . . . . . . . . . 37		3.4. Pseudowire Capabilities and Performance . . . . . . . . . 38
	3.5. Entropy Label Support and Performance . . . . . . . . . . 38		3.5. Entropy Label Support and Performance . . . . . . . . . . 38
	3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 38		3.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 38
	3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 38		3.7. OAM Capabilities and Performance . . . . . . . . . . . . . 39
	4. Forwarding Compliance and Performance Testing . . . . . . . . 39		4. Forwarding Compliance and Performance Testing . . . . . . . . 39
	4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 39		4.1. Basic Compliance . . . . . . . . . . . . . . . . . . . . . 40
	4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40		4.2. Basic Performance . . . . . . . . . . . . . . . . . . . . 40
	4.3. Multipath Capabilities and Performance . . . . . . . . . . 41		4.3. Multipath Capabilities and Performance . . . . . . . . . . 41
	4.4. Pseudowire Capabilities and Performance . . . . . . . . . 41		4.4. Pseudowire Capabilities and Performance . . . . . . . . . 42
	4.5. Entropy Label Support and Performance . . . . . . . . . . 42		4.5. Entropy Label Support and Performance . . . . . . . . . . 42
	4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 43		4.6. DoS Protection . . . . . . . . . . . . . . . . . . . . . . 43
	4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 43		4.7. OAM Capabilities and Performance . . . . . . . . . . . . . 43
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 44		7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 45		8.1. Normative References . . . . . . . . . . . . . . . . . . . 45
	8.2. Informative References . . . . . . . . . . . . . . . . . . 46		8.2. Informative References . . . . . . . . . . . . . . . . . . 46
	Appendix A. Organization of References Section . . . . . . . . . 51		Appendix A. Organization of References Section . . . . . . . . . 51
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
	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
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	VLAN Virtual Local Area Network (Ethernet)		VLAN Virtual Local Area Network (Ethernet)
	VOQ Virtual Output Queuing (switch fabric design)		VOQ Virtual Output Queuing (switch fabric design)
	VPN Virtual Private Network		VPN Virtual Private Network
	WG Working Group		WG Working Group
	1.2. Use of Requirements Language		1.2. Use of Requirements Language
	This document is informational. The key words "MUST", "MUST NOT",		This document is informational. The upper case [RFC2119] key words
	"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",		are not used in this document, except in the following cases.
	"RECOMMENDED", "MAY", and "OPTIONAL" are used only where the
	requirement is specified in an existing RFC. These keywords SHOULD
	be interpreted as described in RFC 2119 [RFC2119].
	Advice given in this document does not use the upper case RFC 2119		1. RFC 2119 keywords are used where requirements stated in this
	keywords, except where explicitly noted that the keywords indicate		document are called for in referenced RFCs. In most cases the
	that operator experiences indicate a requirement, but there are no		RFC containing the requirement is cited within the statement
	existing RFC requirements. Such advice may be ignored by		using an RFC 2119 keyword.
	implementations. Similarly, implementations not claiming conformance
	to specific RFCs may ignore the requirements of those RFCs. In both		2. RFC 2119 keywords are used where explicitly noted that the
	cases, implementers should consider the risk of doing so.		keywords indicate that operator experiences indicate a
			requirement, but there are no existing RFC requirements.
			Advice provided by this document may be ignored by implementations.
			Similarly, implementations not claiming conformance to specific RFCs
			may ignore the requirements of those RFCs. In both cases,
			implementers should consider the risk of doing so.
	1.3. Apparent Misconceptions		1.3. Apparent Misconceptions
	In early generations of forwarding silicon (which might now be behind		In early generations of forwarding silicon (which might now be behind
	us), there apparently were some misconceptions about MPLS. The		us), there apparently were some misconceptions about MPLS. The
	following statements provide clarifications.		following statements provide clarifications.
	1. There are practical reasons to have more than one or two labels		1. There are practical reasons to have more than one or two labels
	in an MPLS label stack. Under some circumstances the label stack		in an MPLS label stack. Under some circumstances the label stack
	can become quite deep. See Section 2.1.		can become quite deep. See Section 2.1.
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 9 ¶
	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 customer's customer's checklist if applicable.
	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 and		these requirements exist. The questions to ask of suppliers is
	testing is covered in the following sections, Section 3 and		covered in Section 3. Some guidelines for testing are provided in
	Section 4.		Section 4.
	2.1. Forwarding Basics		2.1. Forwarding Basics
	Basic MPLS architecture and MPLS encapsulation, and therefore packet		Basic MPLS architecture and MPLS encapsulation, and therefore packet
	forwarding are defined in [RFC3031] and [RFC3032]. RFC3031 and		forwarding are defined in [RFC3031] and [RFC3032]. RFC3031 and
	RFC3032 are somewhat LDP centric. RSVP-TE supports traffic		RFC3032 are somewhat LDP centric. RSVP-TE supports traffic
	engineering (TE) and fast reroute, features that LDP lacks. The base		engineering (TE) and fast reroute, features that LDP lacks. The base
	document for RSVP-TE based MPLS is [RFC3209].		document for RSVP-TE based MPLS is [RFC3209].
	skipping to change at page 11, line 33 ¶		skipping to change at page 11, line 37 ¶
	3. Differentiated Services is supported by [RFC3270] and [RFC4124].		3. Differentiated Services is supported by [RFC3270] and [RFC4124].
	The "EXP" field is renamed to "Traffic Class" in [RFC5462],		The "EXP" field is renamed to "Traffic Class" in [RFC5462],
	removing any misconception that it was available for		removing any misconception that it was available for
	experimentation or could be ignored.		experimentation or could be ignored.
	4. ECN is supported by [RFC5129].		4. ECN is supported by [RFC5129].
	5. The MPLS G-ACh and GAL are defined in [RFC5586].		5. The MPLS G-ACh and GAL are defined in [RFC5586].
			6. [RFC5332] redefines the two data link layer codepoints for MPLS
			packets.
			Tunneling encapsulations which may carry MPLS, such as MPLS in GRE,
			L2TP, or LDP, are out of scope.
	Other RFCs have implications to MPLS Forwarding and do not update		Other RFCs have implications to MPLS Forwarding and do not update
	RFC3032 or RFC3209, including:		RFC3032 or RFC3209, including:
	1. The pseudowire (PW) Associated Channel Header (ACH), defined by		1. The pseudowire (PW) Associated Channel Header (ACH), defined by
	[RFC5085], later generalized by the MPLS G-ACh [RFC5586].		[RFC5085], later generalized by the MPLS G-ACh [RFC5586].
	2. The entropy label indicator (ELI) and entropy label (EL) are		2. The entropy label indicator (ELI) and entropy label (EL) are
	defined by [RFC6790].		defined by [RFC6790].
	A few RFCs update RFC3209. Those that are listed as updating RFC3209		A few RFCs update RFC3209. Those that are listed as updating RFC3209
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 39 ¶
	MPLS deployments in the early part of the prior decade (circa 2000)		MPLS deployments in the early part of the prior decade (circa 2000)
	tended to support either LDP or RSVP-TE. LDP was favored by some for		tended to support either LDP or RSVP-TE. LDP was favored by some for
	its ability to scale to a very large number of PE devices at the edge		its ability to scale to a very large number of PE devices at the edge
	of the network, without adding deployment complexity. RSVP-TE was		of the network, without adding deployment complexity. RSVP-TE was
	favored, generally in the network core, where traffic engineering		favored, generally in the network core, where traffic engineering
	and/or fast reroute were considered important.		and/or fast reroute were considered important.
	Both LDP and RSVP-TE are used simultaneously within major Service		Both LDP and RSVP-TE are used simultaneously within major Service
	Provider networks using a technique known as "LDP over RSVP-TE		Provider networks using a technique known as "LDP over RSVP-TE
	Tunneling". This technique allows service providers to carry LDP		Tunneling". This technique allows service providers to carry LDP
	tunnels, originating and terminating at PEs, inside of RSVP-TE		tunnels inside RSVP-TE tunnels. This makes it possible to take
	tunnels, generally between Inter-City P routers, to take advantage of		advantage of the Traffic Engineering and Fast Re-Route on more
	Traffic Engineering and Fast Re-Route on more expensive Inter-City		expensive Inter-City and Inter-Continental transport paths. The
	and Inter-Continental Transport paths. LDP over RSVP-TE tunneling		ingress RSVP-TE PEs places many LDP tunnels on a single RSVP-TE LSP
	requires a minimum of two MPLS labels: one each for LDP and RSVP-TE.		and carries it to the egress RSVP-TE PE. The LDP PEs are situated
			further from the core, for example within a metro network. LDP over
			RSVP-TE tunneling requires a minimum of two MPLS labels: one each for
			LDP and RSVP-TE.
	The use of MPLS FRR [RFC4090] might add one more label to MPLS		The use of MPLS FRR [RFC4090] might add one more label to MPLS
	traffic, but only when FRR protection is in use (active). If LDP		traffic, but only when FRR protection is in use (active). If LDP
	over RSVP-TE is in use, and FRR protection is in use, then at least		over RSVP-TE is in use, and FRR protection is in use, then at least
	three MPLS labels are present on the label stack on the links through		three MPLS labels are present on the label stack on the links through
	which the Bypass LSP traverses. FRR is covered in Section 2.1.7.		which the Bypass LSP traverses. FRR is covered in Section 2.1.7.
	LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN		LDP L2VPN, LDP IPVPN, BGP L2VPN, and BGP IPVPN added support for VPN
	services that are deployed in the vast majority of service providers.		services that are deployed by the vast majority of service providers.
	These VPN services added yet another label, bringing the label stack		These VPN services added yet another label, bringing the label stack
	depth (when FRR is active) to four.		depth (when FRR is active) to four.
	Pseudowires and VPN are discussed in further detail in Section 2.1.8		Pseudowires and VPN are discussed in further detail in Section 2.1.8
	and Section 2.1.9.		and Section 2.1.9.
	MPLS hierarchy as described in [RFC4206] can in principle add up to		MPLS hierarchy as described in [RFC4206] can in principle add up to
	four additional labels. MPLS hierarchy is discussed in		four additional labels. MPLS hierarchy is discussed in
	Section 2.1.6.		Section 2.1.6.
	skipping to change at page 17, line 49 ¶		skipping to change at page 18, line 14 ¶
	2.1.9. Layer-2 and Layer-3 VPN		2.1.9. Layer-2 and Layer-3 VPN
	Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label		Layer-2 VPN [RFC4664] and Layer-3 VPN [RFC4110] add one or more label
	entry to the MPLS label stack. VPN encapsulations are out of scope		entry to the MPLS label stack. VPN encapsulations are out of scope
	for this document. Its impact on forwarding at midpoint LSR are		for this document. Its impact on forwarding at midpoint LSR are
	within scope.		within scope.
	Any of these services may be used on an MPLS entropy label enabled		Any of these services may be used on an MPLS entropy label enabled
	ingress and egress (see Section 2.4.4 for discussion of entropy		ingress and egress (see Section 2.4.4 for discussion of entropy
	label) which would add an additional label to the MPLS label stack.		label) which would add an additional two labels to the MPLS label
	The need to provide a useful entropy label value impacts the		stack. The need to provide a useful entropy label value impacts the
	requirements of the VPN ingress LER but is out of scope for this		requirements of the VPN ingress LER but is out of scope for this
	document.		document.
	2.2. MPLS Multicast		2.2. MPLS Multicast
	MPLS Multicast encapsulation is clarified in [RFC5332]. MPLS		MPLS Multicast encapsulation is clarified in [RFC5332]. MPLS
	Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388].		Multicast may be signaled using RSVP-TE [RFC4875] or LDP [RFC6388].
	[RFC4875] defines a root initiated RSVP-TE LSP setup rather than leaf		[RFC4875] defines a root initiated RSVP-TE LSP setup rather than leaf
	initiated join used in IP multicast. [RFC6388] defines a leaf		initiated join used in IP multicast. [RFC6388] defines a leaf
	skipping to change at page 19, line 9 ¶		skipping to change at page 19, line 21 ¶
	2.3. Packet Rates		2.3. Packet Rates
	While average packet size of Internet traffic may be large, long		While average packet size of Internet traffic may be large, long
	sequences of small packets have both been predicted in theory and		sequences of small packets have both been predicted in theory and
	observed in practice. Traffic compression and TCP ACK compression		observed in practice. Traffic compression and TCP ACK compression
	can conspire to create long sequences of packets of 40-44 bytes in		can conspire to create long sequences of packets of 40-44 bytes in
	payload length. If carried over Ethernet, the 64 byte minimum		payload length. If carried over Ethernet, the 64 byte minimum
	payload applies, yielding a packet rate of approximately 150 Mpps		payload applies, yielding a packet rate of approximately 150 Mpps
	(million packets per second) for the duration of the burst on a		(million packets per second) for the duration of the burst on a
	nominal 100 Gb/s link. The peak rate is higher for other		nominal 100 Gb/s link. The peak rate for other encapsulations can be
	encapsulations and can be as high as 250 Mpps (for example IP or MPLS		as high as 250 Mpps (for example IP or MPLS encapsulated using GFP
	encapsulated using GFP over OTN ODU4).		over OTN ODU4).
	It is also possible that the packet rates for a minimum payload size,		It is possible that the packet rates achieved by a specific
	such as 64 byte (64B) payload for Ethernet, is acceptable, but the		implementation is acceptable for a minimum payload size, such as 64
	rate declines for other packet sizes, such as 65B payload. There are		byte (64B) payload for Ethernet, but the acheived rate declines to an
	other packet rates of interest besides TCP ACK. For example, a TCP		unacceptable level for other packet sizes, such as 65B payload.
	ACK carried over an Ethernet PW over MPLS over Ethernet may occupy		There are other packet rates of interest besides TCP ACK. For
	82B or 82B plus an increment of 4B if additional MPLS labels are		example, a TCP ACK carried over an Ethernet PW over MPLS over
	present.		Ethernet may occupy 82B or 82B plus an increment of 4B if additional
			MPLS labels are present.
	A graph of packet rate vs. packet size often displays a sawtooth.		A graph of packet rate vs. packet size often displays a sawtooth.
	The sawtooth is commonly due to a memory bottleneck and memory		The sawtooth is commonly due to a memory bottleneck and memory
	widths, sometimes internal cache, but often a very wide external		widths, sometimes internal cache, but often a very wide external
	buffer memory interface. In some cases it may be due to a fabric		buffer memory interface. In some cases it may be due to a fabric
	transfer width. A fine packing, rounding up to the nearest 8B or 16B		transfer width. A fine packing, rounding up to the nearest 8B or 16B
	will result in a fine sawtooth with small degradation for 65B, and		will result in a fine sawtooth with small degradation for 65B, and
	even less for 82B packets. A course packing, rounding up to 64B can		even less for 82B packets. A course packing, rounding up to 64B can
	yield a sharper drop in performance for 65B packets, or perhaps more		yield a sharper drop in performance for 65B packets, or perhaps more
	important, a larger drop for 82B packets.		important, a larger drop for 82B packets.
	skipping to change at page 32, line 51 ¶		skipping to change at page 33, line 13 ¶
	assistance for BFD processing helps insure that protection recovery		assistance for BFD processing helps insure that protection recovery
	time requirements can be met even for faults affecting a large number		time requirements can be met even for faults affecting a large number
	of LSP.		of LSP.
	2.6.5. MPLS OAM and Layer-2 OAM Interworking		2.6.5. MPLS OAM and Layer-2 OAM Interworking
	[RFC6670] provides the reasons for selecting a single MPLS-TP OAM		[RFC6670] provides the reasons for selecting a single MPLS-TP OAM
	solution and examines the consequences were ITU-T to develop a second		solution and examines the consequences were ITU-T to develop a second
	OAM solution that is based on Ethernet encodings and mechanisms.		OAM solution that is based on Ethernet encodings and mechanisms.
	[RFC6310] and [I-D.ietf-pwe3-mpls-eth-oam-iwk] specifies the mapping		[RFC6310] and [RFC7023] specifies the mapping of defect states
	of defect states between many types of hardware Attachment Circuits		between many types of hardware Attachment Circuits (ACs) and
	(ACs) and associated Pseudowires (PWs). This functionality SHOULD be		associated Pseudowires (PWs). This functionality SHOULD be supported
	supported in forwarding hardware.		in forwarding hardware.
	It is beneficial if an MPLS OAM implementation can interwork with the		It is beneficial if an MPLS OAM implementation can interwork with the
	underlying server layer and provide a means to interwork with a		underlying server layer and provide a means to interwork with a
	client layer. For example, [RFC6427] specifies an inter-layer		client layer. For example, [RFC6427] specifies an inter-layer
	propagation of AIS and LDI from MPLS server layer to client MPLS		propagation of AIS and LDI from MPLS server layer to client MPLS
	layers. Where the server layer is a Layer-2, such as Ethernet, PPP		layers. Where the server layer is a Layer-2, such as Ethernet, PPP
	over SONET/SDH, or GFP over OTN, interwork among layers is also		over SONET/SDH, or GFP over OTN, interwork among layers is also
	beneficial. For high speed interfaces, supporting this interworking		beneficial. For high speed interfaces, supporting this interworking
	in forwarding hardware helps insure that protection based on this		in forwarding hardware helps insure that protection based on this
	interworking can meet recovery time requirements even for faults		interworking can meet recovery time requirements even for faults
	skipping to change at page 46, line 36 ¶		skipping to change at page 46, line 46 ¶
	"Dynamics of TCP Traffic over ATM Networks", IEEE Journal		"Dynamics of TCP Traffic over ATM Networks", IEEE Journal
	of Special Areas of Communication Vol 13 No 4, May 1995,		of Special Areas of Communication Vol 13 No 4, May 1995,
	pp. 633-641., May 1995.		pp. 633-641., May 1995.
	[I-D.ietf-mpls-special-purpose-labels]		[I-D.ietf-mpls-special-purpose-labels]
	Kompella, K., Andersson, L., and A. Farrel, "Allocating		Kompella, K., Andersson, L., and A. Farrel, "Allocating
	and Retiring Special Purpose MPLS Labels",		and Retiring Special Purpose MPLS Labels",
	draft-ietf-mpls-special-purpose-labels-03 (work in		draft-ietf-mpls-special-purpose-labels-03 (work in
	progress), July 2013.		progress), July 2013.
	[I-D.ietf-pwe3-mpls-eth-oam-iwk]
	Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
	and R. Qiu, "MPLS and Ethernet OAM Interworking",
	draft-ietf-pwe3-mpls-eth-oam-iwk-08 (work in progress),
	July 2013.
	[I-D.ietf-pwe3-vccv-impl-survey-results]		[I-D.ietf-pwe3-vccv-impl-survey-results]
	Malis, A., "The Pseudowire (PW) & Virtual Circuit		Malis, A., "The Pseudowire (PW) & Virtual Circuit
	Connectivity Verification (VCCV) Implementation Survey		Connectivity Verification (VCCV) Implementation Survey
	Results", draft-ietf-pwe3-vccv-impl-survey-results-03		Results", draft-ietf-pwe3-vccv-impl-survey-results-03
	(work in progress), October 2013.		(work in progress), October 2013.
	[I-D.ietf-tictoc-1588overmpls]		[I-D.ietf-tictoc-1588overmpls]
	Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.		Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
	Montini, "Transporting Timing messages over MPLS		Montini, "Transporting Timing messages over MPLS
	Networks", draft-ietf-tictoc-1588overmpls-05 (work in		Networks", draft-ietf-tictoc-1588overmpls-05 (work in
	skipping to change at page 51, line 14 ¶		skipping to change at page 51, line 19 ¶
	[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security		[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
	Mechanism (GTSM) for the Label Distribution Protocol		Mechanism (GTSM) for the Label Distribution Protocol
	(LDP)", RFC 6720, August 2012.		(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",		Equivalence Classes (FECs) Advertised over IPv6",
	RFC 6829, January 2013.		RFC 6829, January 2013.
			[RFC7023] Mohan, D., Bitar, N., Sajassi, A., DeLord, S., Niger, P.,
			and R. Qiu, "MPLS and Ethernet Operations, Administration,
			and Maintenance (OAM) Interworking", RFC 7023,
			October 2013.
	Appendix A. Organization of References Section		Appendix A. Organization of References Section
	The References section is split into Normative and Informative		The References section is split into Normative and Informative
	subsections. References that directly specify forwarding		subsections. References that directly specify forwarding
	encapsulations or behaviors are listed as normative. References		encapsulations or behaviors are listed as normative. References
	which describe signaling only, though normative with respect to		which describe signaling only, though normative with respect to
	signaling, are listed as informative. They are informative with		signaling, are listed as informative. They are informative with
	respect to MPLS forwarding.		respect to MPLS forwarding.
	Authors' Addresses		Authors' Addresses
End of changes. 32 change blocks.
	65 lines changed or deleted		77 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/