Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network
RFC 5493
Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
ccamp mailing list <ccamp@ops.ietf.org>,
ccamp chair <ccamp-chairs@tools.ietf.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
Ballot Text
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.