Subject: RE: Document Action: 'Framework for GMPLS-based Control of SDH/SONET Networks' to Informational RFC

From: "Vishal Sharma" <[email-masked]>
Date: Sun, 1 May 2005 20:52:21 -0700

Hi Adrian,

Just wanted to be sure what the next step is on this?
Are the author's required to make the changes suggested by the
RFC Editor and submit another version?

If so, to whom and by when?

Thanks,
-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of The IESG
> Sent: Friday, April 29, 2005 8:23 AM
> To: IETF-Announce
> Cc: Internet Architecture Board; RFC Editor; ccamp mailing list; ccamp
> chair; ccamp chair
> Subject: Document Action: 'Framework for GMPLS-based Control of
> SDH/SONET Networks' to Informational RFC
>
>
> The IESG has approved the following document:
>
> - 'Framework for GMPLS-based Control of SDH/SONET Networks '
>    <draft-ietf-ccamp-sdhsonet-control-05.txt> as an Informational RFC
>
> This document is the product of the Common Control and Measurement Plane
> Working Group.
>
> The IESG contact persons are Alex Zinin and Bill Fenner.
>
> Technical Summary
>
>    GMPLS consists of a suite of protocol extensions to MPLS to make
>    these protocols more generally applicable, to include - for example
>    - control of non-packet based switching, and particularly, optical
>    switching.  One area of prime consideration is to use Generalized
>    MPLS (GMPLS) protocols in upgrading the control plane of optical
>    transport networks.  This document illustrates this process by
>    describing those extensions to GMPLS protocols that are directed
>    towards controlling SDH/SONET networks.  SDH/SONET networks make
>    very good examples of this process since they possess a rich
>    multiplex structure, a variety of protection/restoration options,
>    are well defined, and are widely deployed. The document discusses
>    extensions to GMPLS routing protocols to disseminate information
>    needed in transport path computation and network operations,
>    together with the extensions to GMPLS label distribution protocols
>    needed for the provisioning of transport circuits. New capabilities
>    that an GMPLS control plane would bring to SDH/SONET networks, such
>    as new restoration methods and multi-layer circuit establishment,
>    are also discussed.
>
> Working Group Summary
>
>    The CCAMP WG had a consensus on advancing this document.
>
> Protocol Quality
>
>    The document has been reviewed by the RTG area directorate and
> Alex Zinin.
>
> RFC Editor Note
>
> Section 1.1 para 2
>
> OLD
>    An MPLS network consists of MPLS nodes called Label Switch Routers
>    (LSRs) connected via circuits called Label Switched Paths (LSPs). An
>    LSP is unidirectional and could be of several different types such
>    as point-to-point, point-to-multipoint, and multipoint-to-point.
> NEW
>    An MPLS network consists of MPLS nodes called Label Switch Routers
>    (LSRs) connected via Label Switched Paths (LSPs). An
>    LSP is unidirectional and could be of several different types such
>    as point-to-point, point-to-multipoint, and multipoint-to-point.
>
> Replace text in section 7 (Security Considerations) with the following.
>
>  NEW:
>
>   The use of a control plane to provision connectivity through a SONET/SDH
>   network shifts the security burden significantly from the
> management plane
>   to the control plane. Before the introduction of a control plane, the
>   communications that had to be secured were between the
> management stations
>   (Element Management Systems or Network Management Systems) and each
>   network element that participated in the network connection. After the
>   introduction of the control plane, the only management plane
> communication
>   that needs to be secured is that to the head-end (ingress)
> network node as
>   the end-to-end service is requested. On the other hand, the
> control plane
>   introduces a new requirement to secure signaling and routing
>   communications between adjacent nodes in the network plane.
>
>   The security risk from impersonated management stations is significantly
>   reduced by the use of a control plane. In particular, where unsecure
>   versions of network management protocols such as SNMP versions 1 and 2
>   were popular configuration tools in transport networks, the use of a
>   control plane may significantly reduce the security risk of
> malicious and
>   false assignment of network resources that could cause the
> interception or
>   disruption of data traffic.
>
>   On the other hand, the control plane may increase the number of security
>   relationships that each network node must maintain. Instead of a single
>   security relationship with its management element, each network
> node must
>   now maintain a security relationship with each of its signaling and
>   routing neighbors in the control plane.
>
>   There is a strong requirement for singaling and control plane
> exchanges to
>   be secured, and any protocols proposed for this purpose must be
> capable of
>   secure message exchanges. This is already the case for the
> existing GMPLS
>   routing and signaling protocols.
>
>