--- 1/draft-ietf-ccamp-lmp-behavior-negotiation-10.txt 2013-02-08 03:46:34.055708011 +0100 +++ 2/draft-ietf-ccamp-lmp-behavior-negotiation-11.txt 2013-02-08 03:46:34.075708733 +0100 @@ -1,23 +1,23 @@ Network Working Group Dan Li Internet Draft Huawei Updates: 4204, 4207, 4209, 5818 D. Ceccarelli Category: Standards Track Ericsson Lou Berger LabN -Expires: July 2013 January 24, 2013 +Expires: August 2013 February 8, 2013 Link Management Protocol Behavior Negotiation and Configuration Modifications - draft-ietf-ccamp-lmp-behavior-negotiation-10.txt + draft-ietf-ccamp-lmp-behavior-negotiation-11.txt Abstract The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS)-controlled networks. This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. @@ -36,21 +36,21 @@ Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -195,30 +194,31 @@ The format of the ConfigNack message as updated by this document is as follows: ::= [ ... ] 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 ConfigNack message. A maximum of a single object of any particular C-type SHALL be included. A node which receives a message with multiple CONFIG objects of the same C-type SHALL process the first object of a particular C-type and ignore any subsequent 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 to a neighbor whose support for the extensions is either known or unknown. When the neighbor is known to not support the extensions, 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 based on the rules defined as part of CONFIG object definition. Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object types in a single message. Inclusion of multiple CONFIG objects in a ConfigNack message is @@ -280,23 +280,21 @@ [RFC4209]. C: 1 bit This bit indicates support for the data channel consistency check behavior defined in [RFC5818]. Must Be Zero (MBZ): Variable length 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 - LMP object header and MUST include enough bits so the Length - field MUST be at least 8, and MUST be a multiple of 4. + This field MUST be sized to ensure 32 bit alignment of the object. Other bits may be defined in future documents, in which case the number of bits in MBZ field is expected to change. 3.2. Processing The inclusion of a BehaviorConfig type object in a message is discussed above in Section 2.2. When sending a BehaviorConfig type object, the N-bit (negotiable) in @@ -313,22 +311,22 @@ of the flags field MUST be interpreted as unacceptable. Processing related to unacceptable values in CONFIG objects is defined in [RFC4204] and is not modified by this document. 4. Backward Compatibility The required use of the BehaviorConfig type CONFIG object enables nodes which support the extensions defined in this document to explicitly identify when a neighboring node does not. When a non- supporting node receives a Config message with the BehaviorConfig - type CONFIG object or multiple CONFIG objects its behavior is likely - to be one of the following behaviors: + type CONFIG object or multiple CONFIG objects its behavior is to be + one of the following behaviors: a) Reject the Config message because of the unknown BehaviorConfig object type and send a ConfigNack message which includes the unsupported C-type. b) Reject the message because of multiple CONFIG objects and send a ConfigNack message which includes all but one of the CONFIG objects. c) Silently ignore the one or more of the CONFIG object, and respond