Re: [CCAMP] Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt> (ASON Routing for OSPFv2 Protocols) to Proposed Standard

Acee Lindem <acee.lindem@ericsson.com> Thu, 02 August 2012 00:26 UTC

Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5611E80EC; Wed, 1 Aug 2012 17:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.535
X-Spam-Level:
X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKp21jr2GioE; Wed, 1 Aug 2012 17:25:58 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE81411E80BA; Wed, 1 Aug 2012 17:25:57 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q720PqoE022473; Wed, 1 Aug 2012 19:25:53 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 1 Aug 2012 20:25:46 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "iesg-secretary@ietf.org" <iesg-secretary@ietf.org>
Date: Wed, 01 Aug 2012 20:25:45 -0400
Thread-Topic: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt> (ASON Routing for OSPFv2 Protocols) to Proposed Standard
Thread-Index: Ac1wRVt1dEOeYFePQ1qlx24ZFc+WlQ==
Message-ID: <76B81EC9-E7C5-45E3-9245-B07F013F8324@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-23-487725107"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>, Andy Malis <andrew.g.malis@verizon.com>
Subject: Re: [CCAMP] Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt> (ASON Routing for OSPFv2 Protocols) to Proposed Standard
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 00:26:00 -0000

All,

The authors have received comments from Stephen Shew regarding our references to ASON name spaces and would like to 
change the text to clarify these references. The proposed changes are included below. Unless anyone 
has any serious objections, we intend to make these changes as part of the IETF last call process. 
Any further discussion will take place on the CCAMP list.

Thanks,
Acee Lindem


dhcp-421c:Desktop ealflin$ diff -c draft-ietf-ccamp-rfc5787bis-05.txt.orig draft-ietf-ccamp-rfc5787bis-05.txt
*** draft-ietf-ccamp-rfc5787bis-05.txt.orig	2012-07-24 20:51:22.000000000 -0400
--- draft-ietf-ccamp-rfc5787bis-05.txt	2012-07-31 21:26:18.000000000 -0400
***************
*** 354,366 ****
     and corresponding identifiers defined for GMPLS routing, and how
     these support the physical (or logical) separation of transport plane
     entities and control plane components.  GMPLS supports this
!    separation of identifiers and planes.
  
     In the context of OSPF Traffic Engineering (TE), an ASON transport
     node corresponds to a unique OSPF TE node.  An OSPF TE node is
     uniquely identified by the TE Router Address TLV [RFC3630]. In this
     document, this TE Router Address is referred to as the TE Router ID,
!    which is in the ASON SCN name space.  The TE Router ID should not be
     confused with the OSPF Router ID which uniquely identifies an OSPF
     router within an OSPF routing domain [RFC2328] and is in a name space
     for control plane components.
--- 354,387 ----
     and corresponding identifiers defined for GMPLS routing, and how
     these support the physical (or logical) separation of transport plane
     entities and control plane components.  GMPLS supports this
!    separation of identifiers and planes. 
! 
!    ASON refers to transport plane identifiers as SubNetwork Points or 
!    (SNPs). An SNP is an abstraction that represents an actual or 
!    potential underlying connection point (CP) (or connection termination
!    point (CTP)) or an actual or potential termination connection point
!    (TCP) or trail termination point (TTP). Several SNPs (in different 
!    subnetwork partitions) may represent the same TCP or CP [G.8080]. 
!    A collection of SNPs used for ASON routing is referred to as the
!    SubNetork Point Pool (SNPP) and its identifiers are from the SNPP
!    name space. In this context, an SNPP would refer to Optical 
!    Transport Network (OTN) switch and an SNP would be an identifier
!    for an optical channel. 
! 
!    Conversely, the Signaling Control Network (SCN) consists of the 
!    communication paths over which ASON Protocol Controller (PC) 
!    adjacencies are established, and the control plane consists of the
!    ASON PC instances and their corresponding adjacencies.  Given 
!    that OSPF is always transpored over IP, the SCN and control plane
!    will normally coincide. However, a given ASON PC instance may 
!    establish adjacencies over multiple SCNs and multiple ASON PC 
!    instances can use the same SCN.
  
     In the context of OSPF Traffic Engineering (TE), an ASON transport
     node corresponds to a unique OSPF TE node.  An OSPF TE node is
     uniquely identified by the TE Router Address TLV [RFC3630]. In this
     document, this TE Router Address is referred to as the TE Router ID,
!    which is in the ASON SNPP name space.  The TE Router ID should not be
     confused with the OSPF Router ID which uniquely identifies an OSPF
     router within an OSPF routing domain [RFC2328] and is in a name space
     for control plane components.
***************
*** 370,376 ****
     OSPF TE node IP address, i.e., the IP address is always reachable
     when there is IP connectivity to the associated OSPF TE node.
     However, in the context of the OSPF ASON operation, the TE Router ID
!    is an identifier within the ASON SCN. 
  
     ASON defines a Routing Controller (RC) as an entity that handles
     (abstract) information needed for routing and the routing information
--- 391,397 ----
     OSPF TE node IP address, i.e., the IP address is always reachable
     when there is IP connectivity to the associated OSPF TE node.
     However, in the context of the OSPF ASON operation, the TE Router ID
!    is an identifier within the ASON SNPP name space. 
  
     ASON defines a Routing Controller (RC) as an entity that handles
     (abstract) information needed for routing and the routing information
***************
*** 398,404 ****
  
     In ASON, reachability refers to the set of endpoints reachable in the
     transport plane by an associated ASON transport node. Reachable
!    entities are identified in the ASON SCN name space. 
  
     In order to advertise blocks of reachable address prefixes, a
     summarization mechanism is introduced that is based on the techniques
--- 419,426 ----
  
     In ASON, reachability refers to the set of endpoints reachable in the
     transport plane by an associated ASON transport node. Reachable
!    entities are identified in the ASON SNPP name space, and the transport
!    topology is identified from that name space. 
  
     In order to advertise blocks of reachable address prefixes, a
     summarization mechanism is introduced that is based on the techniques
***************
*** 636,642 ****
     of ASON information as described herein. If it is not included in a
     Node Attribute TLV or a value of 0 is specified for the Local TE
     Router Identifier, the Note Attribute TLV will not be used for
!    determining ASON SCN reachability.  Additionally, the condition
     SHOULD be logged for possible action by the network operator. 
  
  7.  Routing Information Dissemination
--- 658,664 ----
     of ASON information as described herein. If it is not included in a
     Node Attribute TLV or a value of 0 is specified for the Local TE
     Router Identifier, the Note Attribute TLV will not be used for
!    determining ASON SNPP reachability.  Additionally, the condition
     SHOULD be logged for possible action by the network operator. 
  
  7.  Routing Information Dissemination

> The IESG has received a request from the Common Control and Measurement
> Plane WG (ccamp) to consider the following document:
> - 'ASON Routing for OSPFv2 Protocols'
>   <draft-ietf-ccamp-rfc5787bis-05.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2012-08-17. Exceptionally, comments may be
> sent to iesg at ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting. This is a four-
> week last call period because it spans the IETF-84 meeting.
> 
> Abstract
> 
>    The ITU-T has defined an architecture and requirements for operating
>    an Automatically Switched Optical Network (ASON).
> 
>    The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
>    is designed to provide a control plane for a range of network
>    technologies including optical networks such as time division
>    multiplexing (TDM) networks including SONET/SDH and Optical Transport
>    Networks (OTNs), and lambda switching optical networks.
> 
>    The requirements for GMPLS routing to satisfy the requirements of
>    ASON routing, and an evaluation of existing GMPLS routing protocols
>    are provided in other documents.  This document defines extensions to
>    the OSPFv2 Link State Routing Protocol to meet the requirements for
>    routing in an ASON.
> 
>    Note that this work is scoped to the requirements and evaluation
>    expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
>    current when those documents were written.  Future extensions of
>    revisions of this work may be necessary if the ITU-T Recommendations
>    are revised or if new requirements are introduced into a revision of
>    RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786.
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-rfc5787bis/ballot/
> 
> No IPR declarations have been submitted directly on this I-D.