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

John,
	I think the gist of my comment (from 2 meetings ago) got lost.   The WG
needs to ensure that any changes / additions to GMPLS don't break
existing GMPLS implementations.  Please see the message I just sent to
Sergio.

Lou

On 11/28/2011 11:53 AM, John E Drake wrote:
> I would suggest that those folks with deployed G.709v1 networks write an
> I-D detailing their requirements for an interworking function.
> 
>  
> 
> *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On
> Behalf Of *BELOTTI, SERGIO (SERGIO)
> *Sent:* Friday, November 25, 2011 12:53 AM
> *To:* CCAMP
> *Subject:* [CCAMP] Framework and Information model for G.709 Optical
> Transport Networks (OTN) consideration post-IETF82
> 
>  
> 
> 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