< draft-ietf-pwe3-vccv-for-gal-01.txt		draft-ietf-pwe3-vccv-for-gal-02.txt >
	Network Working Group T. Nadeau
	Internet-Draft Juniper Networks
	Intended status: Standards Track
	Expires: November 27, 2012 L. Martini
	Cisco Systems, Inc.
	May 8, 2012		PWE3 T. Nadeau
			Internet-Draft lucidvision
			Updates: 5085 (if approved) L. Martini
			Intended status: Standards Track S. Bryant
			Expires: March 6, 2015 Cisco Systems
			September 2, 2014
	A Unified Control Channel for Pseudowires		A Unified Control Channel for Pseudowires
	draft-ietf-pwe3-vccv-for-gal-01.txt		draft-ietf-pwe3-vccv-for-gal-02
	Abstract		Abstract
	This document describes a unified mode of operation for Virtual		This document describes a unified mode of operation for Virtual
	Circuit Connectivity Verification (VCCV), which provides a control		Circuit Connectivity Verification (VCCV), which provides a control
	channel that is associated with a pseudowire (PW). VCCV applies to		channel that is associated with a pseudowire (PW). VCCV applies to
	all supported access circuit and transport types currently defined		all supported access circuit and transport types currently defined
	for PWs, as well as those being transported by The MPLS Transport		for PWs, as well as those being transported by the MPLS Transport
	Profile. This new mode is intended to augment those described in		Profile. This new mode is intended to augment those described in
	RFC5085, but this document describes new rules requiring this mode		RFC5085. It describes new rules requiring this mode to be used as
	to be used as the default/mandatory mode of operation for		the default/mandatory mode of operation for VCCV. The older VCCV
	VCCV. The older types will remain optional.		types will remain optional.
	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 November 4, 2012.		This Internet-Draft will expire on March 6, 2015.
	Copyright Notice		Copyright Notice
	VCCV 2 May 8, 2012
	Copyright (c) 2012 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.
	Requirements Language		Table of Contents
			1. Requirements Language and Terminology . . . . . . . . . . . . 2
			2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
			3. VCCV Control Channel When The Control Word is Used . . . . . 5
			4. VCCV Control Channel When The Control Word is Not Used . . . 6
			5. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 7
			6. Manageability Considerations . . . . . . . . . . . . . . . . 7
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
			8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 7
			8.2. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
			10.1. Normative References . . . . . . . . . . . . . . . . . . 8
			10.2. Informative References . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
			1. Requirements Language and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC-2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	Table of Contents		AC Attachment Circuit [RFC3985].
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. VCCV Control Channel When The Control Word is Used . . . . . . 6
	3. VCCV Control Channel When The Control Word is Not Used . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	4.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19
	4.1.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . 19
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
	7.2. Informative References . . . . . . . . . . . . . . . . . . 26
	1. Introduction		AVP Attribute Value Pair [RFC3931].
			CC Control Channel (used as CC Type).
			CE Customer Edge.
			CV Connectivity Verification (used as CV Type).
			CW Control Word [RFC3985].
			L2SS L2-Specific Sublayer [RFC3931].
			LCCE L2TP Control Connection Endpoint [RFC3931].
			OAM Operation and Maintenance.
			PE Provider Edge.
			PSN Packet Switched Network [RFC3985].
			PW Pseudowire [RFC3985].
			PW-ACH PW Associated Channel Header [RFC4385].
			VCCV Virtual Circuit Connectivity Verification [RFC5085].
			2. Introduction
	There is a need for fault detection and diagnostic mechanisms that		There is a need for fault detection and diagnostic mechanisms that
	can be used for end-to-end fault detection and diagnostics for a		can be used for end-to-end fault detection and diagnostics for a
	Pseudowire, as a means of determining the PW's true operational		Pseudowire, as a means of determining the PW's true operational
	state. Operators have indicated in [RFC4377], [RFC3916].		state. Operators have indicated in [RFC4377], and [RFC3916] that
	that such a tool is required for PW operation and maintenance. To		such a tool is required for PW operation and maintenance. To this
	this end, the IETF's PWE3 Working Group defined The Virtual		end, the IETF's PWE3 Working Group defined the Virtual Circuit
	Circuit Connectivity Verification Protocol (VCCV) in [RFC5085].		Connectivity Verification Protocol (VCCV) in [RFC5085] . Since then a
	Since then a number of interoperability issues have arisen with the		number of interoperability issues have arisen with the protocol as it
	protocol as it is defined.		is defined.
	VCCV 2 May 8, 2012
	Over time, a variety of VCCV options or "modes" have been created to		Over time, a variety of VCCV options or "modes" have been created to
	support legacy hardware, the use of the control word in some cases,		support legacy hardware, these modes use of the CW in some cases,
	while in others not. The difficulty of operating these		while in others the CW is not used. The difficulty of operating
	different combinations of "modes" have been detailed in an		these different combinations of "modes" have been detailed in an
	implementation survey the PWE3 Working Group conducted. Many of the		implementation survey conducted by the PWE3 Working Group and
	motivations of this survey are detailed in [MAN-CW]. This document		documented in [RFC7079]. The implementation survey and the PWE3
			Working Group have concluded that operators have difficulty deploying
	and the implementation survey concluded that operators have had		the VCCV OAM protocol due to the number of combinations and options
	difficulty deploying the protocol given the number of combinations		for its use.
	and options for its use.
	In addition to the implementation issues just described, the ITU-T		In addition to the implementation issues just described, the ITU-T
	and IETF have set out to enhance MPLS to make it suitable as an		and IETF have set out to enhance MPLS to make it suitable as an
	optical transport protocol. The requirements for this protocol are		optical transport protocol. The requirements for this protocol are
	defined as the MPLS Transport Profile (MPLS-TP). The requirements		defined as the MPLS Transport Profile (MPLS-TP). The requirements
	for this protocol can be found in [RFC5654]. In order to support		for MPLS-TP can be found in [RFC5654]. In order to support VCCV when
	VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created;		an MPLS-TP PSN is in use, the GAL-ACH had to be created [RFC5586].
	this effectively resulted in another mode of operation.		This resulted in yet another mode of VCCV operation.
	This document defines two modes of operation of VCCV: 1) with		This document defines two modes of operation of VCCV: 1) with a
	a control word or 2) without a control word, but		control word or 2) without a control word, both with a ACH
	with a ACH encapsulation making it possible to handle all of the		encapsulation making it possible to handle all of the other cases
	other cases handled by the other modes of VCCV. In either case, it		handled by the other modes of VCCV. The modes of operation defined
	will be mandatory to implement and use that mode under that		in this document MUST be implemented.
	scenario.
	Figure 1 depicts the architecture of a pseudowire as defined in		Figure 1 depicts the architecture of a pseudowire as defined in
	[RFC3985]. It further depicts where the VCCV control channel resides		[RFC3985]. It further depicts where the VCCV control channel resides
	within this architecture, which will be discussed in detail shortly.		within this architecture, which will be discussed in detail later in
			this document.
	|<-------------- Emulated Service ---------------->|
	| |<---------- VCCV ---------->| |
	| |<------- Pseudowire ------->| |
	| | | |
	| | |<-- PSN Tunnel -->| | |
	| V V V V |
	V AC +----+ +----+ AC V
	+-----+ | | PE1|==================| PE2| | +-----+
	| |----------|............PW1.............|----------| |
	| CE1 | | | | | | | | CE2 |
	| |----------|............PW2.............|----------| |
	+-----+ ^ | | |==================| | | ^ +-----+
	^ | +----+ +----+ | | ^
	| | Provider Edge 1 Provider Edge 2 | |
	| | | |
	Customer | | Customer
	VCCV 2 May 8, 2012
	Edge 1 | | Edge 2		|<-------------- Emulated Service ---------------->|
	| |		| |<---------- VCCV ---------->| |
	| |		| |<------- Pseudowire ------->| |
	Native service Native service		| | | |
			| | |<-- PSN Tunnel -->| | |
			| V V V V |
			V AC +----+ +----+ AC V
			+-----+ | | PE1|==================| PE2| | +-----+
			| |----------|............PW1.............|----------| |
			| CE1 | | | | | | | | CE2 |
			| |----------|............PW2.............|----------| |
			+-----+ ^ | | |==================| | | ^ +-----+
			^ | +----+ +----+ | | ^
			| | Provider Edge 1 Provider Edge 2 | |
			| | | |
			Customer | | Customer
			Edge 1 | | Edge 2
			| |
			| |
			Native service Native service
	Figure 1: PWE3 VCCV Operation Reference Model		Figure 1: PWE3 VCCV Operation Reference Model
	From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to		From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to
	the emulated service via Attachment Circuits (ACs), and to each of		the emulated service via Attachment Circuits (AC), and to each of the
	the Provider Edge (PE) routers (PE1 and PE2, respectively). An AC		Provider Edge (PE) routers (PE1 and PE2, respectively). An AC can be
	can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM		a Frame Relay Data Link Connection Identifier (DLCI), an ATM Virtual
	Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an		Path Identifier / Virtual Channel Identifier (VPI/VCI), an Ethernet
	Ethernet port, etc. The PE devices provide pseudowire emulation,		port, or any other attachment type for which a PW is defined. The PE
	enabling the CEs to communicate over the PSN. A pseudowire exists		devices provide pseudowire emulation, enabling the CEs to communicate
	between these PEs traversing the provider network. VCCV provides		over the PSN. A pseudowire exists between these PEs traversing the
	several means of creating a control channel over the PW, between the		provider network. VCCV provides several means of creating a control
	PE routers that attach the PW.		channel over the PW, between the PE routers that attach the PW.
	Figure 2 depicts how the VCCV control channel is associated with the		Figure 2 depicts how the VCCV control channel is associated with the
	pseudowire protocol stack.		pseudowire protocol stack.
	+-------------+ +-------------+		+-------------+ +-------------+
	| Layer2 | | Layer2 |		| Layer2 | | Layer2 |
	| Emulated | < Emulated Service > | Emulated |		| Emulated | < Emulated Service > | Emulated |
	| Services | | Services |		| Services | | Services |
	+-------------+ +-------------+		+-------------+ +-------------+
	| | VCCV/PW | |		| | VCCV/PW | |
	|Demultiplexer| < Control Channel > |Demultiplexer|		|Demultiplexer| < Control Channel > |Demultiplexer|
	+-------------+ +-------------+		+-------------+ +-------------+
	| PSN | < PSN Tunnel > | PSN |		| PSN | < PSN Tunnel > | PSN |
	+-------------+ +-------------+		+-------------+ +-------------+
	| Physical | | Physical |		| Physical | | Physical |
	+-----+-------+ +-----+-------+		+-----+-------+ +-----+-------+
	| |		| |
	| ____ ___ ____ |		| ____ ___ ____ |
	| _/ \___/ \ _/ \__ |		| _/ \___/ \ _/ \__ |
	| / \__/ \_ |		| / \__/ \_ |
	| / \ |		| / \ |
	+--------| MPLS/MPLS-TP or IP Network |---+		+--------| MPLS/MPLS-TP or IP Network |---+
	\ /		\ /
	\ ___ ___ __ _/		\ ___ ___ __ _/
	\_/ \____/ \___/ \____/		\_/ \____/ \___/ \____/
	Figure 2: PWE3 Protocol Stack Reference Model including the VCCV		Figure 2: PWE3 Protocol Stack Reference Model including the VCCV
	Control Channel		Control Channel
	VCCV messages are encapsulated using the PWE3 encapsulation as		VCCV messages are encapsulated using the PWE3 encapsulation as
	described in Sections 2 and 3, so that they are handled and processed		described in Section 3 and Section 4, so that they are handled and
	VCCV 2 May 8, 2012		processed in the same manner (or in some cases, a similar manner) the
			PW PDUs for which they provide a control channel. These VCCV
	in the same manner (or in some cases, a similar manner) as the PW		messages are exchanged only after the capability (the VCCV Control
	PDUs for which they provide a control channel. These VCCV messages		Channel and Connectivity Verification types) and the desire to
	are exchanged only after the capability (expressed as two VCCV type		exchange VCCV traffic has been advertised between the PEs (see
	spaces, namely the VCCV Control Channel and Connectivity Verification		Sections 5.3 and 6.3 of [RFC5085]), and VCCV type to use have been
	Types) and desire to exchange such traffic has been advertised		chosen.
	between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.
	1.2. Acronyms
	AC Attachment Circuit [RFC3985].
	AVP Attribute Value Pair [RFC3931].
	CC Control Channel (used as CC Type).
	CE Customer Edge.
	CV Connectivity Verification (used as CV Type).
	CW Control Word [RFC3985].
	L2SS L2-Specific Sublayer [RFC3931].
	LCCE L2TP Control Connection Endpoint [RFC3931].		[EDITOR'S NOTE - Why are we talking about 6.3 which is L2TPv3 related
			in a text on GAL?]
	OAM Operation and Maintenance.		3. VCCV Control Channel When The Control Word is Used
	PE Provider Edge.		When the PWE3 Control Word is used to encapsulate pseudowire traffic,
			the rules described for encapsulating VCCV CC Type 1 as specified in
			section 9.5.1 of [RFC6073] and section 5.1.1 of [RFC5085] MUST be
			used. In this case the advertised CC Type is 1, and Associated
			Channel Types of 21, 07, or 57 are allowed.
	PSN Packet Switched Network [RFC3985].		4. VCCV Control Channel When The Control Word is Not Used
	PW Pseudowire [RFC3985].		When the PWE3 Control Word is not used a new CC Type 4 is defined as
			follows:
	PW-ACH PW Associated Channel Header [RFC4385].		0 1
			2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	VCCV Virtual Circuit Connectivity Verification [RFC5085].		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PW LSE |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| GAL LSE |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|0 0 0 1|Version| Reserved | Associated Channel Type |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ VCCV Message Body ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2. VCCV Control Channel When The Control Word is Used		EDITOR's note = when we wrote RFC3985 I seem to remember that TTL=1
			was problematic do we want to specify TTL=1 in the text below?
	When the PWE3 Control Word is used to encapsulate pseudowire		EDITOR's note = not sure if it should be MUST or SHOULD in the text
	traffic, the rules described for encapsulating VCCV CC Type 1 as		below.
	specified in section 9.5.1 [RFC6073] and section 5.1.1 of [RFC5085]
	MUST be used. In this case the advertised CC Type is 1, and
	Associated Channel Types of 21, 07, or 57 are allowed.
	VCCV 2 May 8, 2012		When the PW is a single segment PW, the TTL field of the PW Label
			Stack Entry (LSE) SHOULD be set to 1. In the case of multi-segment
			pseudo-wires, the PW LSE TTL SHOULD be set to the value needed to
			reach the intended destination PE as described in [RFC6073].
	3. VCCV Control Channel When The Control Word is Not Used		The GAL LSE MUST contain the GAL reserved label as defined in
			[RFC5586].
	When the PWE3 Control Word is not used a new CC Type 4 is		As defined in [RFC4385] and [RFC4446] the first nibble of the next
	defined as follows.		field is set to 0001b to indicate an ACH associated with a pseudowire
			instead of PW data. The Version and the Reserved fields MUST be set
			to 0, and the Channel Type is set to 0x0021 for IPv4, 0x0057 for IPv6
			payloads [RFC5085] or 0x0007 for BFD payloads [RFC5885].
	0 1 2 3		The Associated Channel Type defines how the "VCCV Message Body" field
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		is to be interpreted by the receiver.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PW Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GAL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1|Version| Reserved | Associated Channel Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ VCCV Message Body ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The PW Label must set the TTL field to 1. In the case		5. VCCV Capability Advertisement
	of multi-segment pseudo-wires, the PW Label TTL MUST be set to the
	correct value to reach the intended destination PE as described
	in [RFC6073].
	The GAL field MUST contain the reserved label as defined in		The capability advertisement MUST match the c-bit setting that is
	[RFC5586].		advertised in the PW FEC element. If the c-bit is set, indicating
			the use of the control word, type 1 MUST be advertised and type 4
			MUST NOT be advertised. If the c-bit is not set, indicating that the
			control word is not in use, type 4 MUST be advertised, and type 1
			MUST NOT be advertised.
	The first nibble of the next field is set to 0001b to indicate		A PE supporting Type 4 MAY advertise other CC types as defined in
	an ACH associated with a pseudowire (see Section 5 of [RFC4385]		[RFC5085] . If the remote PE also supports Type 4, then Type 4 MUST
	and Section 3.6 of [RFC4446]) instead of PW data. The Version and		be used superseding the Capability Advertisement Selection rules of
	the Reserved fields MUST be set to 0, and the Channel Type is		section 7 from [RFC5085] . If a remote PE does not support Type 4,
	set to 0x0021 for IPv4, 0x0057 for IPv6 payloads [RFC5085] or		then the rules from section 7 of [RFC5085] apply. If a CW is in use,
	0x0007 for BFD payloads [RFC5885].		then Type 4 is not applicable, and therefore the normal capability
			advertisement selection rules of section 7 from [RFC5085] apply.
	The "VCCV Message Body" field is defined based on the Associated		6. Manageability Considerations
	Channel Type and defined therein.
	4. VCCV Capability Advertisement		Editor's note - this is a placeholder - I am not sure if it sis
			needed
	The capability advertisement MUST match that c-bit setting		7. Security Considerations
	that is advertised in the PW FEC element. If the c-bit is set,
	indicating the use of the control word, type 1 MUST be advertised
	and type 4 MUST NOT be advertised. If the c-bit is not set,
	indicating that the control word is not in use, type 4 MUST
	be advertised, and type 1 MUST NOT be advertised.
	VCCV 2 May 8, 2012		This document does not by itself raise any new security
			considerations beyond those described in [RFC5085].
	A PE supporting Type 4 MAY advertise other CC types		8. IANA Considerations
	as defined in RFC5085. If the remote PE also supports Type
	4, then Type 4 MUST be used superceding the Capability
	Advertisement Selection rules of section 7 from RFC5085.
	If a remote PE does not support Type 4, then the rules
	from section 7 of RFC5085 apply. If a CW is in use, then
	Type 4 is not applicable, and therefore the normal
	capability advertisement selection rules of section 7
	from RFC5085 apply.
	4. IANA Considerations		8.1. VCCV Interface Parameters Sub-TLV
	4.1. VCCV Interface Parameters Sub-TLV		EDITOR'S NOTE ASFAICS this section can be deleted.
	The VCCV Interface Parameters Sub-TLV codepoint is defined in		The VCCV Interface Parameters Sub-TLV code point is defined in
	[RFC4446]. IANA has created and will maintain registries for the CC		[RFC4446]. IANA has created and will maintain registries for the CC
	Types and CV Types (bitmasks in the VCCV Parameter ID). The CC Type		Types and CV Types (bit masks in the VCCV Parameter ID). The CC Type
	and CV Type new registries (see Sections 8.1.1 and 8.1.2,		and CV Type new registries (see Sections 8.1.1 and 8.1.2,
	respectively) have been created in the Pseudo Wires Name Spaces,		respectively of[RFC5085] ) have been created in the Pseudo Wires Name
	reachable from [IANA.pwe3-parameters]. The allocations must be done		Spaces, . The allocations must be done using the "IETF Review" policy
	using the "IETF Consensus" policy defined in [RFC5226].		defined in [RFC5226].
	4.1.1. MPLS VCCV Control Channel (CC) Type 4
	IANA is requested to augment the registry of "MPLS VCCV Control
	Channel Types" with the new type defined below. As defined in
	RFC5058, this new bitfield is to be assigned by IANA using
	the "IETF Consensus" policy defined in [RFC5226]. A VCCV
	Control Channel Type description and a reference to an RFC approved
	by the IESG are required for any assignment from this registry.
	MPLS Control Channel (CC) Types:
	Bit (Value) Description
	============ ==========================================
	Bit 3 (0x08) - Type 4
	The most significant (high order) bit is labeled Bit 7, and the least		8.2. MPLS VCCV Control Channel (CC) Type 4
	significant (low order) bit is labeled Bit 0, see parenthetical
	"Value".
	5. Security Considerations		IANA is requested to assign a new bit from the MPLS VCCV Control
			Channel (CC) Types registry in the PWE3-parameters name space in
			order to identify VCCV type 4. It is recommended that Bit 3 be
			assigned to this purpose which would have a value of 0x08.
	This document does not by itself raise any particular security		MPLS VCCV Control Channel (CC) Types
	considerations that differ from those described in RFC5085.
	VCCV 2 May 8, 2012		Bit (Value) Description Reference
			============ =========== ====================
			Bit X (0x0Y) Type 4 [This Specification]
	6. Acknowledgements		9. Acknowledgements
	7. References		10. References
	7.1. Normative References		10.1. Normative References
	[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.
	[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling		[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
	Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.		Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
	[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,		[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
	"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for		"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
	Use over an MPLS PSN", RFC 4385, February 2006.		Use over an MPLS PSN", RFC 4385, February 2006.
	[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge		[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
	Emulation (PWE3)", BCP 116, RFC 4446, April 2006.		Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
	[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit		[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
	Connectivity Verification (VCCV): A Control Channel for		Connectivity Verification (VCCV): A Control Channel for
	Pseudowires", RFC 5085, December 2007.		Pseudowires", RFC 5085, December 2007.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,		[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
	"MPLS Generic Associated Channel", RFC 5586, June 2009.		Associated Channel", RFC 5586, June 2009.
	[RFC5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
	Forwarding Detection (BFD) for the Pseudowire Virtual
	Circuit Connectivity Verification (VCCV)", RFC 5885,
	June 2010.
	[RFC5654] Niven-Jenkins, B., Brungard, D., and M. Betts,
	"Requirements of an MPLS Transport Profile", RFC 5654,
	September 2009
	[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and
	M. Aissaoui, "Segmented Pseudowire", RFC 6073,
	January 2011.
	12.2. Informative References
	[IANA.l2tp-parameters]		[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
	Internet Assigned Numbers Authority, "Layer Two Tunneling		and S. Ueno, "Requirements of an MPLS Transport Profile",
	Protocol "L2TP"", April 2007,		RFC 5654, September 2009.
	<http://www.iana.org/assignments/l2tp-parameters>.
	VCCV 2 May 8, 2012		[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
			Detection (BFD) for the Pseudowire Virtual Circuit
			Connectivity Verification (VCCV)", RFC 5885, June 2010.
	[IANA.pwe3-parameters]		[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
	Internet Assigned Numbers Authority, "Pseudo Wires Name		Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
	Spaces", June 2007,
	<http://www.iana.org/assignments/pwe3-parameters>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing		10.2. Informative References
	an IANA Considerations Section in RFCs", BCP 26,
	RFC 5226, May 2008.
	[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for		[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
	Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,		Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
	September 2004.		September 2004.
	[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-		[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
	Edge (PWE3) Architecture", RFC 3985, March 2005.		Edge (PWE3) Architecture", RFC 3985, March 2005.
	[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.		[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
	Matsushima, "Operations and Management (OAM) Requirements		Matsushima, "Operations and Management (OAM) Requirements
	for Multi-Protocol Label Switched (MPLS) Networks",		for Multi-Protocol Label Switched (MPLS) Networks", RFC
	RFC 4377, February 2006.		4377, February 2006.
	[MAN-CW] Del Regno, N., Nadeau, T., Manral, V., Ward, D.,		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	"Mandatory Use of Control Word for PWE3 Encapsulations",		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	"Work in progress", October 2010.		May 2008.
	8. Authors' Addresses		[RFC7079] Del Regno, N. and A. Malis, "The Pseudowire (PW) and
			Virtual Circuit Connectivity Verification (VCCV)
			Implementation Survey Results", RFC 7079, November 2013.
			Authors' Addresses
	Thomas D. Nadeau		Thomas D. Nadeau
	Juniper Networks		lucidvision
	Email: tnadeau@juniper.net
			Email: tnadeau@lucidvision.com
	Luca Martini		Luca Martini
	Cisco Systems, Inc.		Cisco Systems
	9155 East Nichols Avenue, Suite 400
	Englewood, CO, 80112 USA
	EMail: lmartini@cisco.com		Email: lmartini@cisco.com
			Stewart Bryant
			Cisco Systems
			Email: stbryant@cisco.com
End of changes. 66 change blocks.
	274 lines changed or deleted		258 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/