Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82

Sergio,
	My comment actually comes from two meetings ago and was based on the
routing and signaling drafts each having their own compatibility
sections (sections 6 and 6.5, respectively), and the framework not
having one at all.  As you note, control plane compatibility is
something typically addressed in GMPLS.  I think the framework needs to
cover what approach is being taken to ensure *control plane* operation
when a pre-G709v3 GMPLS node exchanges CP messages with a G709v3 GMPLS
node.  In short, the framework should say *what* is being done with
respect to CP compatibility, the routing and signaling documents should
say *how* CP compatibility is supported.

Note that my request was not about data plane compatibility.

Lou

On 11/25/2011 3:52 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Hi CCAMP,
>  
> as outcome of the Framework and Information model for G.709 Optical
> Transport Networks (OTN) presentation, Lou Berger asked co-authors to
> provide a new section in the framework document dealing with backward
> compatibility, as summary with respect to what is already present/will
> be present in the  encoding documents.
>  
> In our opinion, the first thing to do is deciding which are the
> scenarios that have to be taken into account.
>  
> As hypothesis we would like to consider network element domains 
> composed either of G.709v1 or G709v3 network elements,
> so without having a mix of network element in the same domains. The
> motivation for this is that operators
> would not be happy with the mix because managing control plane versions
> implementing very different features
> is not practical from a network operation point of view. 
>  
> Please note that backward compatibility issues are to be considered
> between GMPLS versions. So for G.709v1 NE we mean
> a network element with G.709v1 HW and support of RFC4328 only.
>  
> The case of a NE with G709v1 HW supporting our GMPLS drafts does not
> have backward compatibility issues because it can be considered as a
> new  node with limitations.
>  
> Said this the candidate scenarios may be:
>  
> 1)  Interworking between a G.709v1 domain with a G.709v3 domain (path is
> terminated by one G.709v1 node and G.709v3  node)
>  
> 2) Interworking in the case of  a G.709v1 domain – a G.709v3 domain –
> G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. The
> path being terminated on G.709v1 equipment.)
>  
> We'd like to hear the opinion of the WG whether CCAMP consider
> exhaustive the type of scenarios proposed, before proceeding with any
> modification to the document.
>  
> Thanks
>  
> Sergio and co-authors
>  
>  
> *SERGIO BELOTTI*
>  
> ALCATEL-LUCENT
> Terrestrial System Architect
> Optics Portfolio Evolution
>  
> via Trento 30 , Vimercate(MI)  Italy
> T: +39 0396863033
> *Sergio.Belotti@alcatel-lucent.com*
>  
>  
>  
>  
>  
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp