draft-ietf-ccamp-lmp-behavior-negotiation-10.txt		draft-ietf-ccamp-lmp-behavior-negotiation-11.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: July 2013 January 24, 2013		Expires: August 2013 February 8, 2013
	Link Management Protocol Behavior Negotiation and		Link Management Protocol Behavior Negotiation and
	Configuration Modifications		Configuration Modifications
	draft-ietf-ccamp-lmp-behavior-negotiation-10.txt		draft-ietf-ccamp-lmp-behavior-negotiation-11.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)-controlled networks. This		Multiprotocol Label Switching (GMPLS)-controlled networks. This
	document defines an extension to LMP to negotiate capabilities and		document defines an extension to LMP to negotiate capabilities and
	indicate support for LMP extensions. The defined extension is		indicate support for LMP extensions. The defined extension is
	compatible with non-supporting implementations.		compatible 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 July 21, 2013.		This Internet-Draft will expire on August 5, 2013.
	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 5, line 25		skipping to change at page 5, line 27
	The format of the ConfigNack message as updated by this document is		The format of the ConfigNack message as updated by this document is
	as follows:		as follows:
	<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>		<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
	<LOCAL_NODE_ID> <REMOTE_CCID>		<LOCAL_NODE_ID> <REMOTE_CCID>
	<MESSAGE_ID_ACK> <REMOTE_NODE_ID>		<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
	<CONFIG> [ <CONFIG> ... ]		<CONFIG> [ <CONFIG> ... ]
	2.2. Processing		2.2. Processing
	Nodes which support the extensions defined in this document MAY		Nodes that support the extensions defined in this document MAY
	include multiple CONFIG objects when sending a Config, ConfigAck and		include multiple CONFIG objects when sending a Config, ConfigAck and
	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 with different C-type
			values is not significant.
	Nodes which support the extensions defined in this document MUST		Nodes that 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 object		Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object
	types in a single message.		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
	skipping to change at page 7, line 18		skipping to change at page 7, line 23
	[RFC4209].		[RFC4209].
	C: 1 bit		C: 1 bit
	This bit indicates support for the data channel consistency check		This bit indicates support for the data channel consistency check
	behavior defined in [RFC5818].		behavior defined in [RFC5818].
	Must Be Zero (MBZ): Variable length		Must Be Zero (MBZ): Variable length
	The remaining bits in the flags field MUST be set to zero (0).		The remaining bits in the flags field MUST be set to zero (0).
	The number of bits present is based on the Length field of the		This field MUST be sized to ensure 32 bit alignment of the object.
	LMP object header and MUST include enough bits so the Length
	field MUST be at least 8, and MUST be a multiple of 4.
	Other bits may be defined in future documents, in which case the		Other bits may be defined in future documents, in which case the
	number of bits in MBZ field is expected to change.		number of bits in MBZ field is expected to change.
	3.2. Processing		3.2. Processing
	The inclusion of a BehaviorConfig type object in a message is		The inclusion of a BehaviorConfig type object in a message is
	discussed above in Section 2.2.		discussed above in Section 2.2.
	When sending a BehaviorConfig type object, the N-bit (negotiable) in		When sending a BehaviorConfig type object, the N-bit (negotiable) in
	skipping to change at page 8, line 4		skipping to change at page 8, line 6
	of the flags field MUST be interpreted as unacceptable. Processing		of the flags field MUST be interpreted as unacceptable. Processing
	related to unacceptable values in CONFIG objects is defined in		related to unacceptable values in CONFIG objects is defined in
	[RFC4204] and is not modified by this document.		[RFC4204] and is not modified by this document.
	4. Backward Compatibility		4. Backward Compatibility
	The required use of the BehaviorConfig type CONFIG object enables		The required use of the BehaviorConfig type CONFIG object enables
	nodes which support the extensions defined in this document to		nodes which support the extensions defined in this document to
	explicitly identify when a neighboring node does not. When a non-		explicitly identify when a neighboring node does not. When a non-
	supporting node receives a Config message with the BehaviorConfig		supporting node receives a Config message with the BehaviorConfig
	type CONFIG object or multiple CONFIG objects its behavior is likely		type CONFIG object or multiple CONFIG objects its behavior is to be
	to be one of the following behaviors:		one of the following behaviors:
	a) Reject the Config message because of the unknown BehaviorConfig		a) Reject the Config message because of the unknown BehaviorConfig
	object type and send a ConfigNack message which includes the		object type and send a ConfigNack message which includes the
	unsupported C-type.		unsupported C-type.
	b) Reject the message because of multiple CONFIG objects and send a		b) Reject the message because of multiple CONFIG objects and send a
	ConfigNack message which includes all but one of the CONFIG		ConfigNack message which includes all but one of the CONFIG
	objects.		objects.
	c) Silently ignore the one or more of the CONFIG object, and respond		c) Silently ignore the one or more of the CONFIG object, and respond
End of changes. 8 change blocks.
	11 lines changed or deleted		10 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/