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

["BELOTTI, SERGIO (SERGIO)" <[e-mail]>]

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]