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

John E Drake <jdrake@juniper.net> Mon, 28 November 2011 16:55 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F321F8CBD for <ccamp@ietfa.amsl.com>; Mon, 28 Nov 2011 08:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.473
X-Spam-Level:
X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSRm7iQDpP40 for <ccamp@ietfa.amsl.com>; Mon, 28 Nov 2011 08:54:59 -0800 (PST)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 95F3221F8531 for <ccamp@ietf.org>; Mon, 28 Nov 2011 08:54:59 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTtO82ssFbP/ovSZgeUS6eACHTYzdGvnr@postini.com; Mon, 28 Nov 2011 08:54:59 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Nov 2011 08:53:18 -0800
From: John E Drake <jdrake@juniper.net>
To: "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, CCAMP <ccamp@ietf.org>
Date: Mon, 28 Nov 2011 08:53:19 -0800
Thread-Topic: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82
Thread-Index: AcyrT5Fr8/K9YKXwSVajMEKWu/H2CQCnmHnQ
Message-ID: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net>
References: <F050945A8D8E9A44A71039532BA344D8191305D4@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
In-Reply-To: <F050945A8D8E9A44A71039532BA344D8191305D4@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A4B531CFFCEMBX01HQjnprn_"
MIME-Version: 1.0
Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2011 16:55:01 -0000

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