draft-ietf-ccamp-lmp-behavior-negotiation-07.txt		draft-ietf-ccamp-lmp-behavior-negotiation-08.txt
	Network Working Group Dan Li		Network Working Group Dan Li
	Internet Draft Huawei		Internet Draft Huawei
	Updates: 4204, 4207, 4209, 5818 D. Ceccarelli		Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
	Category: Standards Track Ericsson		Category: Standards Track Ericsson
	Lou Berger		Lou Berger
	LabN		LabN
	Expires: June 2013 December 5, 2012		Expires: June 2013 December 19, 2012
	Link Management Protocol Behavior Negotiation and		Link Management Protocol Behavior Negotiation and
	Configuration Modifications		Configuration Modifications
	draft-ietf-ccamp-lmp-behavior-negotiation-07.txt		draft-ietf-ccamp-lmp-behavior-negotiation-08.txt
	Abstract		Abstract
	The Link Management Protocol (LMP) is used to coordinate the		The Link Management Protocol (LMP) is used to coordinate the
	properties, use, and faults of data links in Generalized		properties, use, and faults of data links in Generalized
	Multiprotocol Label Switching (GMPLS) networks. This document		Multiprotocol Label Switching (GMPLS) networks. This document
	defines an extension to LMP to negotiate capabilities and indicate		defines an extension to LMP to negotiate capabilities and indicate
	support for LMP extensions. The defined extension is compatible		support for LMP extensions. The defined extension is compatible
	with non-supporting implementations.		with non-supporting implementations.
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any 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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on June 5, 2013.		This Internet-Draft will expire on June 18, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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		carefully, as they describe your rights and restrictions with
	respect to this document. Code Components extracted from this		respect to this document. Code Components extracted from this
	document must include Simplified BSD License text as described in		document must include Simplified BSD License text as described in
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction ................................................ 3		1. Introduction ................................................ 3
	2. LMP Message Modifications.................................... 4		2. LMP Message Modifications.................................... 4
	skipping to change at page 3, line 30		skipping to change at page 3, line 39
	features can be enabled. There are no such procedures defined in the		features can be enabled. There are no such procedures defined in the
	base LMP specification [RFC4204]. [RFC4209] defined a specific		base LMP specification [RFC4204]. [RFC4209] defined a specific
	mechanism to identify support for the functions defined in that		mechanism to identify support for the functions defined in that
	document. This document defines an LMP extension to support the		document. This document defines an LMP extension to support the
	identification of supported LMP functions in a generic fashion, as		identification of supported LMP functions in a generic fashion, as
	well as how a node supporting these extensions would communicate		well as how a node supporting these extensions would communicate
	with legacy nodes.		with legacy nodes.
	In [RFC4204], the basic behaviors have been defined around the use		In [RFC4204], the basic behaviors have been defined around the use
	of the standard LMP messages, which include Config, Hello, Verify,		of the standard LMP messages, which include Config, Hello, Verify,
	Test, LinkSummary, and ChannelStatus. Per [RCF4204], these behaviors		Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors
	MUST be supported when LMP is implemented, and the message types		MUST be supported when LMP is implemented, and the message types
	from 1 to 20 have been assigned by IANA for these messages. Support		from 1 to 20 have been assigned by IANA for these messages. Support
	for all functions required by [RFC4204] is assumed by this document.		for all functions required by [RFC4204] is assumed by this document.
	In [RFC4207], the SONET/SDH technology-specific behavior and		In [RFC4207], the SONET/SDH technology-specific behavior and
	information for LMP is defined. The Trace behavior is added to LMP,		information for LMP is defined. The Trace behavior is added to LMP,
	and the message types from 21 to 31 were assigned by IANA for the		and the message types from 21 to 31 were assigned by IANA for the
	messages that provide the TRACE function. The Trace function has		messages that provide the TRACE function. The Trace function has
	been extended for the support of OTNs (Optical Transport Networks)		been extended for the support of OTNs (Optical Transport Networks)
	in [LMP-TEST].		in [LMP TEST].
	In [RFC4209], extensions to LMP are defined to allow it to be used		In [RFC4209], extensions to LMP are defined to allow it to be used
	between a peer node and an adjacent Optical Line System (OLS). The		between a peer node and an adjacent Optical Line System (OLS). The
	LMP object class type and sub-object class name have been extended		LMP object class type and sub-object class name have been extended
	to support DWDM behavior.		to support DWDM behavior.
	In [RFC5818], the data channel consistency check behavior is defined,		In [RFC5818], the data channel consistency check behavior is defined,
	and the message types from 32 to 34 have been assigned by IANA for		and the message types from 32 to 34 have been assigned by IANA for
	messages that provide this behavior.		messages that provide this behavior.
	skipping to change at page 5, line 27		skipping to change at page 5, line 37
	ConfigNack message. A maximum of a single object of any particular		ConfigNack message. A maximum of a single object of any particular
	C-type SHALL be included. A node which receives a message with		C-type SHALL be included. A node which receives a message with
	multiple CONFIG objects of the same C-type SHALL process the first		multiple CONFIG objects of the same C-type SHALL process the first
	object of a particular C-type and ignore any subsequent CONFIG		object of a particular C-type and ignore any subsequent CONFIG
	objects of the same C-type. Unless specified as part of the CONFIG		objects of the same C-type. Unless specified as part of the CONFIG
	object definition, ordering of CONFIG objects is not significant.		object definition, ordering of CONFIG objects is not significant.
	Nodes which support the extensions defined in this document MUST		Nodes which support the extensions defined in this document MUST
	include a BehaviorConfig type object when sending a Config message		include a BehaviorConfig type object when sending a Config message
	to a neighbor whose support for the extensions is either known or		to a neighbor whose support for the extensions is either known or
	unknown. (When the neighbor is known to not support the extensions,		unknown. When the neighbor is known to not support the extensions,
	the object MUST NOT be sent.) Inclusion of other CONFIG objects in a		the object MUST NOT be sent. Inclusion of other CONFIG objects in a
	Config message is at the discretion of the message sender, and is		Config message is at the discretion of the message sender, and is
	based on the rules defined as part of CONFIG object definition.		based on the rules defined as part of CONFIG object definition.
	Nodes MAY include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig		Nodes MAY include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig
	object types in a single message.		object types in a single message.
	Inclusion of multiple CONFIG objects in a ConfigNack message is		Inclusion of multiple CONFIG objects in a ConfigNack message is
	based on the processing of a received Config message. Per [RFC4204]		based on the processing of a received Config message. Per [RFC4204]
	"Parameters where agreement was reached MUST NOT be included in the		"Parameters where agreement was reached MUST NOT be included in the
	ConfigNack Message." As such, a ConfigNack message MUST NOT include		ConfigNack Message." As such, a ConfigNack message MUST NOT include
	CONFIG objects which are acceptable and MUST include any CONFIG		CONFIG objects which are acceptable and MUST include any CONFIG
	skipping to change at page 8, line 45		skipping to change at page 9, line 5
	new CONFIG object defined in this document.		new CONFIG object defined in this document.
	The procedures described in this document do not of itself		The procedures described in this document do not of itself
	constitute a security risk since they do not cause any change in		constitute a security risk since they do not cause any change in
	network state. It would be possible, if the messages were		network state. It would be possible, if the messages were
	intercepted or spoofed to cause bogus alerts in the management plane,		intercepted or spoofed to cause bogus alerts in the management plane,
	or to cause LMP peers to consider that they could or could not		or to cause LMP peers to consider that they could or could not
	operate protocol extensions, and so the use of the LMP security		operate protocol extensions, and so the use of the LMP security
	measures are RECOMMENDED.		measures are RECOMMENDED.
	Note, however, that [RFC4204] refers to [RFC2401], which has been		Note, however that [RFC4204] references for security have been
	replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is		updated with [RFC4301] and the current reference for IKEv2 is
	out of date, and the current reference for IKEv2 is [RFC5996].		[RFC5996].
	6. IANA Considerations		6. IANA Considerations
	6.1. New LMP Class Type		6.1. New LMP Class Type
	IANA maintains the "Link Management Protocol (LMP)" registry which		IANA maintains the "Link Management Protocol (LMP)" registry which
	has a subregistry called "LMP Object Class name space and Class type		has a subregistry called "LMP Object Class name space and Class type
	(C-Type)".		(C-Type)".
	IANA is requested to make an assignment from this registry as		IANA is requested to make an assignment from this registry as
End of changes. 9 change blocks.
	11 lines changed or deleted		23 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/