Re: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787bis-01

[Acee Lindem <[e-mail]>]

Hi Stephen,

I know this response is late but I want to close the loop on your comments with the CCAMP WG before we issue another version. My understanding from discussions with my co-authors is that you will work with us on the terminology comments (1, 2, 3, and 5a). 

As for comments 4 and 5b, I don't think we can change the TLV advertisement requirements for all OSPF TE, RFC 3630, et al,  since these changes would not be backward compatible nor required for all OSPF TE applications. I do, however, think we could relax the general requirement to advertise the Link-ID TLV in the cases where the Local and Remote TE Router ID sub-TLVs are advertised. 

Thanks,
Acee

On Oct 26, 2010, at 2:08 PM, Shew, Stephen wrote:

> I have read draft-malis-ccamp-rfc5787bis-01.txt and was involved in the discussion of it at the recent ITU-T Q12/15 interim meeting.  I have the following comments on it:
> 
> The main comment I have on the draft is that it is requires more clarity on address/name spaces that various identifiers are part of, especially distinguishing between the IP network address space and other address/namespaces.  In transport networks, there are different name spaces associated with services, resources (data plane), management functions, and the communications between those functions.  ASON (G.8080) can be viewed as another transport management function and thus has the following name spaces:
> 
> Services - UNI and ENNI Transport Resource identifiers (known in OIF IAs as Transport Network Addresses)
> Resources - Subnetwork Point Pool (SNPP) names
> Functions - Component (RC, NCC, CC, LRM, TAP, DS) names and Protocol Controller names
> Communications - The Signalling Communications Network (SCN) has identifiers that are used for the purpose of sending information between ASON components.  These have similar meaning as L3 IP reachable addresses.
> 
> Reading the draft then with this view of name spaces we make the following comments:
> 1. General. The term "reachability" can be confusing as the semantics differ with the name space to which it is applied.  If applied to the resource or data plane, it means that the resource is visible in some topology.  If applied in the SCN context, it means that information can be sent to that address using an IP network.  If applied to the component name space, it usually means that the information can be sent to that component via the SCN.
> 
> 2. Section 3.  In an ASON context, "TE router ID" is in the resource name space and identifies a node/matrix in the transport network.  The "OSPF router ID" is in a component name space and represents the routing function.
> 
> 3. Section 4. The term "reachability" should be clarified in this section to mean identifiers in the resource plane that are advertised by the routing function.  They are not reachable in the same sense as functions are pinged in IP.  What can be confusing is that these addresses may use the IPv4 or IPv6 address format, but are in a different name space from IP routable addresses.
> 
> 4. Section 6.1.  I would like to suggest that consideration be given to always advertising the Local and Remote TE Router ID sub-TLV.  This would provide a consistent advertising behaviour for the ASON case and make it possible to increase the scope of an OSPF router from one to two TE Router IDs without changing the advertising format.
> 
> 5. Section 6.2.  The term "reachability" should be clarified as noted above (point 3). Also, I suggest that consideration be given to always advertising the Local TE Router ID sub-TLV for the same reason given above (point 4).
> 
> Stephen Shew | Director, Standards
> [e-mail] | 3500 Carling Ave. | Ottawa CANADA K2H 8E9
> Direct +1.613.763.2462
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Acee Lindem
> Sent: 23 September, 2010 09:49
> To: [e-mail]
> Subject: Re: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787bis-01
> 
> Most of the changes in the this revision are an attempt to make the document easier to understand for people unfamiliar with ITU ASON terminology. This is in response to comments from Julien Meuric and others at the IETF 78 CCAMP meeting. 
> 
>        - Section 2 now contains text better explaining the hierarchical relationship between RAs. Much of this is taken from RFC 4258. 
>        - Section 3 has been rewritten with the description of an OSPF router advertising on behalf multiple ASON transport nodes simplified. The subscripted variables (Ri, Pi, and Li) have been removed in favor of this simplified terminology.
>        - Section 5 includes solely editorial changes. Some of the longer sentences have been split and some ambiguous language has been clarified. 
>        - Section 6 has been rewritten to reflect the simplified terminology introduced in section 3. Additionally, we have clarified when the rules for inclusion of the new section 6 Sub-TLVs. We also removed the restriction on when these new Sub-TLVs may be specified. 
>        - Section 7 includes some changes to reflect the new section 3 terminology, as well as, a couple editorial changes. 
> 
> Lyndon Ong will coordinate review of this revision with the ITU Q.12/15 SG at their Shanghai meeting. 
> 
> Thanks,
> Acee
> 
> On Sep 22, 2010, at 5:44 AM, IETF I-D Submission Tool wrote:
> 
>> 
>> A new version of I-D, draft-malis-ccamp-rfc5787bis-01.txt has been successfully submitted by Andrew Malis and posted to the IETF repository.
>> 
>> Filename:	 draft-malis-ccamp-rfc5787bis
>> Revision:	 01
>> Title:		 Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis)
>> Creation_date:	 2010-09-22
>> WG ID:		 Independent Submission
>> Number_of_pages: 20
>> 
>> 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.
>> 
>> 
>> 
>> The IETF Secretariat.
>> 
>> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp