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

["Adrian Farrel" <[e-mail]>]

All,
 
I am worried by this...
 
1. The document is in IETF last call. Comments and discussions MUST be sent to
the IETF discussion list unless they are specifically sent direct to the IESG.
It is inappropriate to have the discussion in private or limited to the CCAMP
list.
 
2. I disagree with the changes made as they do not recognise how GMPLS is used
to provide the necessary naming and addressing.
 
3. I find the proposed inclusion of text on ASON terminology to be imprecise.
Furthermore, it is questionable whether it is appropriate to attempt to define
in an IETF document a term that is (or should be) defined in an ITU-T document.
Additionally, RFC 4397 was constructed to provide mapping of terminology and was
carefully reviewed in the IETF and ITU-T; any attempt to provide additional
mapping will require further cross-review.
 
Can we please start this from the top?
Action: Someone says on the IETF Discuss list: "I have the following concerns
and issues. I think they can be addressed by these text changes."
 
Don't just propose changes. Give reasons.
 
Thanks,
Adrian
 
From: Acee Lindem [mailto:[e-mail]] 
Sent: 02 August 2012 01:26
To: [e-mail]
Cc: CCAMP; Stephen Shew; Adrian Farrel; Andy Malis; Lyndon Ong; Dimitri
(Dimitri) Papadimitriou
Subject: RE: Last Call: <draft-ietf-ccamp-rfc5787bis-05.txt> (ASON Routing for
OSPFv2 Protocols) to Proposed Standard
 
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.