--- 1/draft-ietf-ccamp-lmp-behavior-negotiation-06.txt 2012-12-10 20:15:24.169342236 +0100 +++ 2/draft-ietf-ccamp-lmp-behavior-negotiation-07.txt 2012-12-10 20:15:24.197343759 +0100 @@ -1,55 +1,56 @@ Network Working Group Dan Li Internet Draft Huawei Updates: 4204, 4207, 4209, 5818 D. Ceccarelli Category: Standards Track Ericsson Lou Berger LabN -Expires: January 2013 July 30, 2012 +Expires: June 2013 December 5, 2012 Link Management Protocol Behavior Negotiation and Configuration Modifications - draft-ietf-ccamp-lmp-behavior-negotiation-06.txt + draft-ietf-ccamp-lmp-behavior-negotiation-07.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) 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. + This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818. + Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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 January 29, 2013. + This Internet-Draft will expire on June 5, 2013. Copyright Notice Copyright (c) 2010 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 @@ -149,21 +150,21 @@ LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies the ConfigAck message to include CONFIG objects so that acceptable parameters are explicitly identified. It also describes how a node which supports the extensions defined in this document interacts with a legacy LMP node. 2. LMP Message Modifications LMP Config, ConfigNack and ConfigAck messages are modified by this document to allow for the inclusion of multiple CONFIG objects. The - Config and ConfigNack messages were only defined to carry on CONFIG + Config and ConfigNack messages were only defined to carry one CONFIG object in [RFC4204]. The ConfigAck message, which was defined without carrying any CONFIG objects in [RFC4204], is modified to enable explicit identification of negotiated configuration parameters. The inclusion of CONFIG objects in ConfigAck messages is triggered by the use of the BehaviorConfig object (defined below) in a received Config message. 2.1. Modified Message Formats The format of the Config message as updated by this document is as @@ -194,26 +195,26 @@ 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. Nodes which 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. (But not when the neighbor is known to not support the - extensions.) Inclusion of other CONFIG objects in a Config message - is at the discretion of the message sender, and is based on the - rules defined by as part of CONFIG object definition. Nodes MAY - include, HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object types in - a single message. + 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 based on the processing of a received Config message. Per [RFC4204] "Parameters where agreement was reached MUST NOT be included in the ConfigNack Message." As such, a ConfigNack message MUST NOT include CONFIG objects which are acceptable and MUST include any CONFIG objects which are not acceptable. When a CONFIG object is included in a ConfigNack message, per [RFC4204], the object is to include "acceptable alternate values for negotiable parameters".