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

[Acee Lindem <[e-mail]>]

Hi Adrian, 

On Aug 5, 2012, at 10:03 AM, Adrian Farrel wrote:

> 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.

This was my problem. IETF announce was copied but of course it bounced. 


>  
> 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.

Other than including the two paragraphs describing ASON terminology, the change is basically "s/ASON SCN/ASON SNPP/". 
Furthermore, the ASON term SNPP is included in section 3.9.2 of RFC 4397 and Appendix A of this draft. 

>  
> 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."

I'm about to go on a vacation for a couple weeks and this was my attempt to handle the comment swiftly. Since "s/ASON SCN/ASON SNPP/" is viewed as a less than innocuous editorial change, I'll leave it to Lyndon, Stephen, or someone else participating in the ITU.    

>  
> Don't just propose changes. Give reasons.

It was my understanding that the term "ASON SCN" was viewed as incorrect. However, I'll defer to Stephen. 

Thanks,
Acee 

>  
> 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.
>