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

From: Acee Lindem <[email-masked]>
Date: Wed, 1 Aug 2012 20:25:45 -0400

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Aug 2012 15:03:48 +0100

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:[email-masked]] 
Sent: 02 August 2012 01:26
To: [email-masked]
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.

  

  

  

 
 
Abstract

---

From: Acee Lindem <[email-masked]>
Date: Sun, 5 Aug 2012 11:39:55 -0400

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. 

> 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 

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