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

Lou,
Thanks for clarification , I understood during my presentation that the comment was a remind referred to another past meeting (in which I was not present).
The aim of the mail is trying to understand how to address the "what is being done" that cannot be independent of the type of possible network scenarios. 
We need to understand , particularly from company-people with per-G.709.v3 implementation(John has perfectly pointed out the issue), what could be the typical scenarios to be addressed.
We have tried to set the focus on two out of them, and we'd like to hear from WG the approval or not to work on them.
We cannot start to work before an agreement on that.

Sergio   

-----Messaggio originale-----
Da: Lou Berger [mailto:lberger@labn.net] 
Inviato: martedì 29 novembre 2011 13.02
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP
Oggetto: 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