Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, ccamp mailing list <email@example.com>, ccamp chair <firstname.lastname@example.org> Subject: Document Action: 'Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network' to Informational RFC The IESG has approved the following document: - 'Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network ' <draft-ietf-ccamp-pc-and-sc-reqs-06.txt> as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-06.txt
Technical Summary From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This informational document sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Working Group Summary There were no problems with consensus for this document. In the early stages there were some very strong opinions about the value of this work. Some vendors and operators did not believe that the function would be useful in the networks they build. However, over time, other vendors and operators strongly supported the function, and since it is described as an optional function in equipment and deployment, the working group did not object to this work proceeding. See proto writeup by Deborah Brungard. Document Quality This is a requirements specification, and cannot be implemented. Note that work is already in progress within the CCAMP working group to develop protocol solutions. Personnel Deborah Brungard is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. There are no IANA actions for this document. RFC Editor Note Please move the "Conventions used in this document" to be at the end of section 1 (introduction), as section 1.1, and please replace its text with the following text: NEW Although this requirements document is an informational document not a protocol specification, 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 RFC 2119 [RFC2119] for clarity of requirement specification. In section 6, please make the following substitution: OLD If SNMP MIBs are used for configuration, then the Management Plane should support authentication for PC-SC configuration changes as specified in [RFC3414]. NEW The Management Plane interactions MUST be supported through protocols that can offer adequate security mechanisms to secure the configuration and protect the operation of the devices that are managed. These mechanisms MUST include at least cryptographic security and the ability to ensure that the entity giving access to configuration parameters is properly configured to give access only to those principals (users) that have legitimate rights to read/create/change/delete the parameters. IETF standard management protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these mechanisms.