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

[Lou Berger <[e-mail]>]

Sergio,
	At a minimum, the solutions draft MUST cover what happens when a
pre-G709v3 (or non-G709v3) GMPLS node exchanges CP messages with a
G709v3 GMPLS node.  For example, what happens when a G709v3 GMPLS node
exchanges messages with a node supporting only LSC or ethernet. You can
even just state something as simple as what's in rfc6002 section 2.1.
This is just a matter of correct protocol behavior and should not be a
"big" deal or discussion.

You seem to also want to cover G.709v1 and G709v3 interoperability.
This is a fine thing to consider, but has nothing to do with the comment.

Lou

On 11/30/2011 4:29 AM, BELOTTI, SERGIO (SERGIO) wrote:
> 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:[e-mail]] 
> 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: [phone]
>> *[e-mail]*
>>  
>>  
>>  
>>  
>>  
>>
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>