draft-ietf-mpls-tp-itu-t-identifiers-02.txt		draft-ietf-mpls-tp-itu-t-identifiers-03.txt
	Network Working Group R. Winter, Ed.		Network Working Group R. Winter, Ed.
	Internet-Draft NEC		Internet-Draft NEC
	Intended status: Standards Track E. Gray, Ed.		Intended status: Standards Track E. Gray, Ed.
	Expires: May 3, 2012 Ericsson		Expires: September 7, 2012 Ericsson
	H. van Helvoort		H. van Helvoort
	Huawei Technologies Co., Ltd.		Huawei Technologies Co., Ltd.
	M. Betts		M. Betts
	ZTE		ZTE
	October 31, 2011		March 6, 2012
	MPLS-TP Identifiers Following ITU-T Conventions		MPLS-TP Identifiers Following ITU-T Conventions
	draft-ietf-mpls-tp-itu-t-identifiers-02		draft-ietf-mpls-tp-itu-t-identifiers-03
	Abstract		Abstract
	This document specifies an extension to the identifiers to be used in		This document specifies an extension to the identifiers to be used in
	the Transport Profile of Multiprotocol Label Switching (MPLS-TP).		the Transport Profile of Multiprotocol Label Switching (MPLS-TP).
	Identifiers that follow IP/MPLS conventions have already been		Identifiers that follow IP/MPLS conventions have already been
	defined. This memo augments that set of identifiers for MPLS-TP		defined. This memo augments that set of identifiers for MPLS-TP
	management and OAM functions to include identifier information in a		management and OAM functions to include identifier information in a
	format typically used by the ITU-T.		format typically used by the ITU-T.
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 May 3, 2012.		This Internet-Draft will expire on September 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Requirements notation . . . . . . . . . . . . . . . . . . . 4		1.2. Requirements notation . . . . . . . . . . . . . . . . . . 4
	2. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 4		1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 4
	3. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . . . 4		2. Named Entities . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. ICC_Operator_ID-based MEG Identifiers . . . . . . . . . . . . . 5		3. Uniquely Identifying an Operator - the ICC_Operator_ID . . . . 5
	5. ICC_Operator_ID-based MEP Identifiers . . . . . . . . . . . . . 5		3.1. Use of the ICC_Operator_ID . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		4. Node and Interface Identifiers . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		5. MPLS-TP Tunnel and LSP Identifiers . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. MPLS-TP Point-to-Point Tunnel Identifiers . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 6		5.2. MPLS-TP LSP Identifiers . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . . 7		5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers . . 8
			6. Pseudowire Path Identifiers . . . . . . . . . . . . . . . . . 9
			7. Maintenance Identifiers . . . . . . . . . . . . . . . . . . . 9
			7.1. MEG Identifiers . . . . . . . . . . . . . . . . . . . . . 9
			7.2. MEP Identifiers . . . . . . . . . . . . . . . . . . . . . 10
			7.3. MIP Identifiers . . . . . . . . . . . . . . . . . . . . . 10
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
			10.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document augments the initial set of identifiers to be used in		This document augments the initial set of identifiers to be used in
	the Transport Profile of Multiprotocol Label Switching (MPLS-TP)		the Transport Profile of Multiprotocol Label Switching (MPLS-TP)
	specified in RFC 6370 [RFC6370].		specified in [RFC6370].
	RFC 6370 [RFC6370] defines a set of MPLS-TP transport and management		[RFC6370] defines a set of MPLS-TP transport and management entity
	entity identifiers to support bidirectional (co-routed and		identifiers to support bidirectional (co-routed and associated)
	associated) point-to-point MPLS-TP LSPs, including PWs and Sections		point-to-point MPLS-TP LSPs, including PWs and Sections which follow
	which follow the IP/MPLS conventions.		the IP/MPLS conventions.
	This document specifies an alternative way to uniquely identify an		This document specifies an alternative way to uniquely identify an
	operator/service provider based on ITU-T conventions and specifies		operator/service provider based on ITU-T conventions and specifies
	how this operator/service provider identifier can be used to make the		how this operator/service provider identifier can be used to make the
	existing set of MPLS-TP transport and management entity identifiers,		existing set of MPLS-TP transport and management entity identifiers,
	defined by RFC 6370 [RFC6370], globally unique.		defined by [RFC6370], globally unique.
	This document solely defines those identifiers. Their use and		This document solely defines those identifiers. Their use and
	possible protocols extensions to carry them is out of scope in this		possible protocols extensions to carry them is out of scope in this
	document.		document.
	In this document, we follow the notational convention laid out in RFC		In this document, we follow the notational convention laid out in
	6370 [RFC6370].		[RFC6370], which is included in this document for convenience in
			Section 1.3.
	1.1. Terminology		1.1. Terminology
	CC: Country Code		CC: Country Code
	ICC: ITU-T Carrier Code		ICC: ITU Carrier Code
	ITU-T: International Telecommunication Union Telecommunication		ITU-T: International Telecommunication Union Telecommunication
	Standardization Sector		Standardization Sector
	LSP: Label Switched Path		LSP: Label Switched Path
	MEG: Maintenance Entity Group		MEG: Maintenance Entity Group
	MEP: Maintenance Entity Group End Point		MEP: Maintenance Entity Group End Point
			MIP: Maintenance Entity Group Intermediate Point
	MPLS: Multi-Protocol Label Switching		MPLS: Multi-Protocol Label Switching
	PW: Pseudowire		PW: Pseudowire
	TSB: (ITU-T) Telecommunication Standardization Bureau		TSB: (ITU-T) Telecommunication Standardization Bureau
	UMC: Unique MEG ID Code		UMC: Unique MEG ID Code
	1.2. Requirements notation		1.2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Uniquely Identifying an Operator - the ICC_Operator_ID		1.3. Notational Conventions
	In RFC 6370 [RFC6370] an operator is uniquely identified by the		All multiple-word atomic identifiers use underscores (_) between the
	Global_ID which is based on the AS number of the operator. The ITU-T		words to join the words. Many of the identifiers are composed of a
	however traditionally identifies operators/service providers based on		set of other identifiers. These are expressed by listing the latter
	the ITU-T Carrier Code (ICC) as specified in [M1400].		identifiers joined with double-colon "::" notation.
			Where the same identifier type is used multiple times in a
			concatenation, they are qualified by a prefix joined to the
			identifier by a dash (-). For example, A1-Node_ID is the Node_ID of
			a node referred to as A1.
			The notation defines a preferred ordering of the fields.
			Specifically, the designation A1 is used to indicate the lower sort
			order of a field or set of fields and Z9 is used to indicate the
			higher sort order of the same. The sort is either alphanumeric or
			numeric depending on the field's definition. Where the sort applies
			to a group of fields, those fields are grouped with {...}.
			Note, however, that the uniqueness of an identifier does not depend
			on the ordering, but rather, upon the uniqueness and scoping of the
			fields that compose the identifier. Further, the preferred ordering
			is not intended to constrain protocol designs by dictating a
			particular field sequence or even what fields appear in which
			objects.
			2. Named Entities
			This document makes modest changes to the set of identifiers defined
			in [RFC6370]. Most changes replace certain parts in the already
			defined identifiers that are themselves composed of a set of atomic
			identifiers. The set of identifiers defined in [RFC6370] are:
			o Global_ID
			o Node
			o Interface
			o Tunnel
			o LSP
			o PW
			o MEG
			o MEP
			o MIP
			The following sections go through this list of identifiers one by
			one. The structure of this document is loosely aligned with the
			structure of [RFC6370].
			3. Uniquely Identifying an Operator - the ICC_Operator_ID
			In [RFC6370] an operator is uniquely identified by the Global_ID
			which is based on the AS number of the operator. The ITU-T however
			traditionally identifies operators/service providers based on the
			ITU-T Carrier Code (ICC) as specified in [M1400].
	The ITU-T Telecommunication Standardization Bureau (TSB) maintains a		The ITU-T Telecommunication Standardization Bureau (TSB) maintains a
	list of assigned ICCs [ICC-list]. Note that ICCs can be assigned to		list of assigned ICCs [ICC-list]. Note that ICCs can be assigned to
	both, ITU-T members as well as non-members, all of which are		both, ITU-T members as well as non-members, all of which are
	referenced at [ICC-list]. The national regulatory authorities act as		referenced at [ICC-list]. The national regulatory authorities act as
	an intermediary between the ITU/TSB and operators/service providers.		an intermediary between the ITU/TSB and operators/service providers.
	Amongst the things that the national authorities are responsible for		Amongst the things that the national authorities are responsible for
	in the process of assigning an ICC is to ensure that the Carrier		in the process of assigning an ICC is to ensure that the Carrier
	Codes are unique within their country.		Codes are unique within their country.
	The ICC itself is a string of one to six characters, each character		The ICC itself is a string of one to six characters, each character
	being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9).		being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9).
	Alphabetic characters in the ICC SHOULD be represented with upper		Alphabetic characters in the ICC SHOULD be represented with upper
	case letters.		case letters.
	Global uniqueness is assured by concatenating the ICC with a Country		Global uniqueness is assured by concatenating the ICC with a Country
	Code (CC). The Country Code (alpha-2) is a string of two alphabetic		Code (CC). The Country Code (alpha-2) is a string of two alphabetic
	characters represented with upper case letters (i.e., A-Z). The		characters represented with upper case letters (i.e., A-Z). The
	Country Code format is defined in ISO 3166-1 [ISO3166-1]. Together,		Country Code format is defined in ISO 3166-1 [ISO3166-1]. Together,
	the CC and the ICC form the ICC_Operator_ID as CC::ICC.		the CC and the ICC form the ICC_Operator_ID as:
	3. Use of the ICC_Operator_ID		CC::ICC
			3.1. Use of the ICC_Operator_ID
	The ICC_Operator_ID is used as a replacement for the Global_ID as		The ICC_Operator_ID is used as a replacement for the Global_ID as
	specified in RFC 6370 [RFC6370], i.e. its purpose is to provide a		specified in [RFC6370], i.e. its purpose is to provide a globally
	globally unique context for other MPLS-TP identifiers.		unique context for other MPLS-TP identifiers.
	As an example, an Interface Identifier (IF_ID) in RFC 6370 [RFC6370]		As an example, an Interface Identifier (IF_ID) in [RFC6370] is
	is specified as the concatenation of the Node_ID (a unique 32-bit		specified as the concatenation of the Node_ID (a unique 32-bit value
	value assigned by the operator) and the Interface Number (IF_Num, a		assigned by the operator) and the Interface Number (IF_Num, a 32-bit
	32-bit unsigned integer assigned by the operator that is unique		unsigned integer assigned by the operator that is unique within the
	within the scope of a Node_ID). To make this IF_ID globally unique		scope of a Node_ID). To make this IF_ID globally unique the
	the Global_ID is prefixed. This memo specifies the ICC_Operator_ID		Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an
	as an alternative format which, just like the Global_ID, is prefixed		alternative format which, just like the Global_ID, is prefixed to the
	to the IF_ID. Using the notation from RFC 6370 [RFC6370]:		IF_ID. Using the notation from RFC 6370 [RFC6370]:
	Global_ID::Node_ID::IF_Num		Global_ID::Node_ID::IF_Num
	is functionally equivalent to:		is functionally equivalent to:
	ICC_Operator_ID::Node_ID::IF_Num		ICC_Operator_ID::Node_ID::IF_Num
	The same substitution procedure applies to all identifiers specified		The same substitution procedure applies to all identifiers specified
	in RFC 6370 [RFC6370] except for the other alternatives mentioned in		in [RFC6370] with the exception of the MEG ID, MEP ID and MIP ID.
	this document.		MEG, MEP and MIP identifiers are redefined in this document (see
			Section 7.1, Section 7.2 and Section 7.3 respectively).
	4. ICC_Operator_ID-based MEG Identifiers		4. Node and Interface Identifiers
	The ITU-T format of MEG_IDs for MPLS-TP Sections, LSPs and		The format of the node and interface identifiers are not changed by
	Pseudowires is based on the globally unique ICC_Operator_ID. In this		this memo except for the case when global uniqueness is required.
	case, the MEG_ID is a string of up to 15 characters. It consists of
	three subfields: the Country Code (as described in Section 2), the		[RFC6370] defines the node identifier (Node_ID) as a unique 32-bit
	ICC (as described in Section 2) which together form the		value assigned by the operator within the scope of a Global_ID. The
			structure of the Node_ID itself is not defined as it is left to the
			operator to choose an appropriate value. The value zero however is
			reserved and MUST NOT be used.
			This draft does not change the above definition. However, in case
			global uniqueness is required, the Node_ID is prefixed with the
			ICC_Operator_ID as defined in Section 3.
			[RFC6370] further defines interface numbers (IF_Num) as 32-bit
			unsigned integers which can be freely assigned by the operator and
			must be unique in the scope of the respective Node_ID. The IF_Num
			value 0 has a special meaning and therefore it MUST NOT be used to
			identify an MPLS-TP interface.
			An interface identifier (IF_ID) identifies an interface uniquely
			within the context of an ICC_Operator_ID. It is formed by
			concatenating the Node_ID with the IF_Num to result in a 64-bit
			identifier formed as Node_ID::IF_Num.
			Global uniqueness of the IF_ID, if needed, can be assured by
			prefixing the identifier with the ICC_Operator_ID.
			5. MPLS-TP Tunnel and LSP Identifiers
			This document does not change the definition for local tunnel and LSP
			IDs. When global uniqueness is needed, the format of these
			identifiers is as described in Section 5.1 and Section 5.2 below.
			5.1. MPLS-TP Point-to-Point Tunnel Identifiers
			Tunnel IDs (Tunnel_ID) are based on the end points' Node_IDs and
			locally assigned tunnel numbers (Tunnel_Num) which identify the
			tunnel at each end point. The tunnel number is a 16-bit unsigned
			integer unique within the context of the Node_ID. A full tunnel ID
			is represented by the concatenation of these two end point-specific
			identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID
			is:
			A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}
			Where global uniqueness is required, using ITU-T conventions, the
			ICC_Operator_ID is prefixed to the Tunnel_IDs. Thus, a globally
			unique Tunnel_ID becomes:
			A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: Z9-
			{ICC_Operator_ID::Node_ID::Tunnel_Num}
			As per [RFC6370], when an MPLS-TP Tunnel is configured, it MUST be
			assigned a unique IF_ID at each end point as defined in Section 4.
			5.2. MPLS-TP LSP Identifiers
			The following sub-sections define identifiers for MPLS-TP co-routed
			bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub-
			Path Maintenance Entities (SPMEs) are also LSPs, they use the same
			form of IDs.
			5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers
			The LSP identifier (LSP_ID) for a co-routed bidirectional LSP is
			formed by adding a 16-bit unsigend integer LSP number (LSP_Num) to
			the tunnel ID. Consequently, the format of an MPLS-TP co-routed
			bidirectional LSP_ID is:
			A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
			[RFC6370] notes that, the "uniqueness of identifiers does not depend
			on the A1/Z9 sort ordering".
			A co-routed bidirectional LSP is provisioned or signaled as a single
			entity and therefore a single LSP_Num is used for both unidirectional
			LSPs. These can be referenced by the following identifiers:
			A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and
			Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively.
			Global uniqueness is accomplished by using globally unique Node_IDs.
			A globally unique LSP_ID consequently becomes:
			A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
			Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num
			5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers
			Associated bidirectional LSPs need an LSP_Num for each unidirectional
			LSP it consists of. The LSP number is again a 16-bit unsigned
			integer which needs to be unique within the scope of the ingress'
			Tunnel_Num. Consequently, the format of an MPLS-TP associated
			bidirectional LSP_ID is:
			A1-{Node_ID::Tunnel_Num::LSP_Num}::
			Z9-{Node_ID::Tunnel_Num::LSP_Num}
			Each of the unidirectional LSPs of which the associated bidirectional
			LSP consists of may be referenced by one of the following
			identifiers:
			A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and
			Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID, respectively.
			A globally unique LSP_ID is constructed using the globally unique
			Node_IDs as defined before. Consequently, a globally unique LSP_ID
			is formulated as:
			A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}::
			Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}
			6. Pseudowire Path Identifiers
			The PW Path Identifier (PW_Path_ID) is structured in a similar manner
			as the LSP IDs described before. It uses the concept of a group ID
			(Group_ID) as described in RFC 4447 together with a PW number
			(PW_Num). Both are 16 bit quantaties. In a statically configure
			environment, both the group ID and the PW number need to be equal on
			both ends of the PW. Together with the node ID these values form the
			PW_Path_ID as follows:
			A1-{Node_ID::Group_ID::PW_Num}::Z9-{Node_ID::Group_ID::PW_Num}
			A globally unique PW_Path_ID is constructed using the globally unique
			Node_IDs as defined earlier in this document. A globally unique
			PW_Path_ID is formulated as:
			A1-{ICC_Operator_ID::Node_ID::Group_ID::PW_Num}::
			Z9-{ICC_Operator_ID::Node_ID::Group_ID::PW_Num}
			7. Maintenance Identifiers
			A Maintenance Entity Group (MEG) as defined by [RFC6371] is a
			collection of one or more maintenance enties that belong to the same
			transport path. These maintenance entities can be e.g. Maintenance
			Entity Group End Points (MEPs) or Maintenance Entity Group
			Intermediate Points (MIPs). The following sub-sections define the
			identifiers for the various maintenance-related groups and entities.
			In contrast to the IDs defined in [RFC6370], this document does not
			define separate maintenance identifiers for sections, PWs and LSPs.
			7.1. MEG Identifiers
			MEG_IDs for MPLS-TP Sections, LSPs and Pseudowires following ITU-T
			conventions are based on the globally unique ICC_Operator_ID. In
			this case, the MEG_ID is a string of up to 15 characters and consists
			of three subfields: the Country Code (as described in Section 3), the
			ICC (as described in Section 3) which together form the
	ICC_Operator_ID, followed by a Unique MEG ID Code (UMC) as defined in		ICC_Operator_ID, followed by a Unique MEG ID Code (UMC) as defined in
	[Y.1731_cor1].		[Y.1731_cor1].
	The resulting MEG_ID therefore looks like the following:		The resulting MEG_ID is:
	CC:ICC:UMC		CC:ICC:UMC
	To avoid the potential for a short (i.e. less than 6 Character) ICC		To avoid the potential for the concatenation of a short (i.e. less
	code in combination with a UMC not being unique the UMC MUST start		than 6 Character) ICC with a UMC not being unique the UMC MUST start
	with a special character that is not allowed in the ICC such as the		with the "/" character which is not allowed in the ICC itself. This
	"/" character. A side effect of this is that the MEG_ID can be		way, the MEG_ID can also be easily decomposed into its individual
	decomposed into its individual components by a receiver.		components by a receiver.
	The UMC MUST be unique within the organization identified by the		The UMC MUST be unique within the organization identified by the
	combination of CC and ICC.		combination of CC and ICC.
	The ICC_Operator_ID-based MEG_ID may be applied equally to a single		The ICC_Operator_ID-based MEG_ID may be applied equally to a single
	MPLS-TP Section, LSP or Pseudowire.		MPLS-TP Section, LSP or Pseudowire.
	5. ICC_Operator_ID-based MEP Identifiers		7.2. MEP Identifiers
	ICC_Operator_ID-based MEP_IDs for MPLS-TP LSPs and Pseudowires are		ICC_Operator_ID-based MEP_IDs for MPLS-TP LSPs and Pseudowires are
	formed by appending a 16-bit index to the MEG_ID defined in Section 4		formed by appending a 32-bit index to the MEG_ID defined in
	above. Within the context of a particular MEG, we call the		Section 7.1 above. Within the context of a particular MEG, we call
	identifier associated with a MEP the MEP Index (MEP_Index). The		the identifier associated with a MEP the MEP Index (MEP_Index). The
	MEP_Index is administratively assigned. It is encoded as a 16-bit		MEP_Index is administratively assigned. It is encoded as a 32-bit
	unsigned integer and MUST be unique within the MEG. An		unsigned integer and MUST be unique within the MEG. An
	ICC_Operator_ID-based MEP_ID is structured as:		ICC_Operator_ID-based MEP_ID is structured as:
	MEG_ID::MEP_Index		MEG_ID::MEP_Index
	An ICC_Operator_ID-based MEP ID is globally unique by construction		An ICC_Operator_ID-based MEP ID is globally unique by construction
	given the ICC_Operator_ID-based MEG_ID's global uniqueness.		given the ICC_Operator_ID-based MEG_ID's global uniqueness.
	6. Security Considerations		7.3. MIP Identifiers
	This document extends an existing information model and, as such,		ICC_Operator_ID-based MIP_IDs are formed the same way MEP_IDs are
	does in itself not introduce new security concerns. But, as		constructed, i.e. by appending a 32-bit MIP Index (MIP_Index) to the
	mentioned in the security considerations section of the document that		MEG_ID. The MIP_Index is administratively assigned and encoded as a
	is being augmented, protocol specifications that describe use of this		32-bit unsigned integer. It MUST be unique within the MEG. An
	information model may introduce security risks and concerns about		ICC_Operator_ID-based MIP_ID is structured as:
	authentication of participants. For this reason, these protocol
	specifications need to describe security and authentication concerns
	that may be raised by the particular mechanisms defined and how those
	concerns may be addressed.
	7. IANA Considerations		MEG_ID::MIP_Index
			An ICC_Operator_ID-based MIP ID is globally unique by construction
			given the ICC_Operator_ID-based MEG_ID's global uniqueness.
			8. Security Considerations
			This document extends an existing information model and does not
			introduce new security concerns. But, as mentioned in the security
			considerations section of [RFC6370] protocol specifications that
			describe use of this information model may introduce security risks
			and concerns about authentication of participants. For this reason,
			these protocol specifications need to describe security and
			authentication concerns that may be raised by the particular
			mechanisms defined and how those concerns may be addressed.
			9. IANA Considerations
	There are no IANA actions resulting from this document.		There are no IANA actions resulting from this document.
	8. References		10. References
	8.1. Normative References		10.1. Normative References
	[ISO3166-1]		[ISO3166-1]
	"Codes for the representation of names of countries and		"Codes for the representation of names of countries and
	their subdivisions -- Part 1: Country codes", ISO 3166-1.		their subdivisions -- Part 1: Country codes", ISO 3166-1.
	[M1400] "Designations for interconnections among operators'		[M1400] "Designations for interconnections among operators'
	networks", ITU-T Recommendation M.1400, July 2006,		networks", ITU-T Recommendation M.1400, July 2006,
	<http://www.itu.int/rec/T-REC-M.1400-200607-I/en>.		<http://www.itu.int/rec/T-REC-M.1400-200607-I/en>.
	[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.
	[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport		[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
	Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.		Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
			[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
			Maintenance Framework for MPLS-Based Transport Networks",
			RFC 6371, September 2011.
	[Y.1731_cor1]		[Y.1731_cor1]
	"OAM functions and mechanisms for Ethernet based networks		"OAM functions and mechanisms for Ethernet based networks
	- Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731		- Corrigendum 1", ITU-T Recommendation ITU-T G.8013/Y.1731
	(2011) Corrigendum 1.		(2011) Corrigendum 1.
	8.2. Informative References		10.2. Informative References
	[ICC-list]		[ICC-list]
	"List of ITU Carrier Codes (ICCs)",		"List of ITU Carrier Codes (ICCs)",
	<http://www.itu.int/oth/T0201>.		<http://www.itu.int/oth/T0201>.
	Authors' Addresses		Authors' Addresses
	Rolf Winter (editor)		Rolf Winter (editor)
	NEC		NEC
End of changes. 39 change blocks.
	85 lines changed or deleted		317 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/