--- 1/draft-ietf-ccamp-lmp-behavior-negotiation-02.txt 2011-04-07 11:17:00.000000000 +0200 +++ 2/draft-ietf-ccamp-lmp-behavior-negotiation-03.txt 2011-04-07 11:17:00.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group Dan Li Internet Draft Huawei Updates: RFC4204 D. Ceccarelli Category: Standards Track Ericsson -Expires: September 2011 March 14, 2011 +Expires: October 2011 April 7, 2011 Behavior Negotiation in The Link Management Protocol - draft-ietf-ccamp-lmp-behavior-negotiation-02.txt + draft-ietf-ccamp-lmp-behavior-negotiation-03.txt 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. @@ -23,21 +23,21 @@ 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 September 13, 2011. + This Internet-Draft will expire on October 7, 2011. 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 @@ -63,28 +63,28 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction ................................................ 2 2. LMP Behavior Negotiation Procedure........................... 3 3. Backward Compatibility....................................... 5 4. Security Considerations...................................... 6 - 5. IANA Considerations ......................................... 6 - 5.1. New LMP Class Type...................................... 6 + 5. IANA Considerations ......................................... 7 + 5.1. New LMP Class Type...................................... 7 5.2. New Capabilities Registry............................... 7 - 6. Contributors ................................................ 7 + 6. Contributors ................................................ 8 7. Acknowledgments ............................................. 8 8. References .................................................. 8 8.1. Normative References.................................... 8 - 8.2. Informative References.................................. 8 + 8.2. Informative References.................................. 9 9. Authors' Addresses .......................................... 9 1. Introduction The Link Management Protocol (LMP) [RFC4204] has been successfully deployed in Generalized Multiprotocol Label Switching (GMPLS)- controlled networks. New LMP behaviors and protocol extensions have been introduced in a number of IETF documents as set out later in this section. It is @@ -151,21 +151,21 @@ report and negotiate currently defined LMP mechanisms and behaviors, and to allow future LMP extensions to be reported and negotiated. - C-Type = 3, BEHAVIOR_CONFIG The format of the new type of CONFIG Class is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Length |B|S|D|C| Reserved | + | Length |B|S|D|C| MUST_BE_ZERO | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 8 bits This field indicates the total length of the objects expressed in multiples of 4 bytes. Flags: B: 1 bit @@ -183,22 +183,22 @@ This bit indicates support for the DWDM behavior defined in [RFC4209]. C: 1 bit This bit indicates support for the data channel consistency check behavior defined in [RFC5818]. Further bits may be defined in future documents. - The Reserved field MUST be sent as zero and MUST NOT be ignored on - receipt. This allows the detection of unsupported or unknown LMP + The MUST_BE_ZERO field MUST be sent as zero and MUST NOT be ignored + on receipt. This allows the detection of unsupported or unknown LMP behaviors when new bits are allocated to indicate further capabilities and are sent as one. Upon receiving a bit set related to an unsupported or unknown behavior, a ConfigNack message MUST be sent with a object, the BEHAVIOR_CONFIG C-Type representing the supported LMP behaviors. An LSR receiving such a ConfigNack SHOULD select a supported set of capabilities and send a further Config message, or MAY raise an alert to the management system (or log an error) and stop trying to perform LMP communications with its neighbor. @@ -256,20 +256,24 @@ new object defined in this document. The operation of the procedures described in this document does not of itself constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane, or to cause LMP peers to consider that they could or could not operate protocol extensions, and so the use of the LMP security measures are RECOMMENDED. + Note, however, that [RFC4204] refers to [RFC2401], which has been + replaced by [RFC4301]. Also, the reference to IKEv2 in [RFC4301] is + out of date, and the current reference for IKEv2 is [RFC5996]. + 5. IANA Considerations 5.1. New LMP Class Type IANA maintains the "Link Management Protocol (LMP)" registry which has a subregistry called "LMP Object Class name space and Class type (C-Type)". IANA is requested to make an assignment from this registry as follows: @@ -312,29 +316,39 @@ Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736 Email: diego.caviglia@ericsson.com 7. Acknowledgments - Thanks to Adrian Farrel and Lou Berger for their useful comments. + Thanks to Adrian Farrel, Lou Berger and Richard Graveman for their + useful comments. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005 + + [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet Key + Exchange Protocol: IKEv2", RFC 5996, September 2010. + [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/ Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, October 2005. [RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line