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

John,
	Sure, and CP compatibility doesn't need to imply interoperability, and
certainly wasn't intended in the original comment.

Lou

On 11/29/2011 8:24 AM, John E Drake wrote:
> Lou,
> 
> My point was that control plane interoperability with G.709v1 is non-trivial and before we start working on it we should know whether anyone wants it.
> 
> Thanks,
> 
> John 
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, November 29, 2011 4:05 AM
>> To: John E Drake
>> Cc: BELOTTI, SERGIO (SERGIO); CCAMP
>> Subject: 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
> 
> 
> 
>