Re: [CCAMP] OSPF OTN considerations post IETF 82

John E Drake <jdrake@juniper.net> Mon, 28 November 2011 16:48 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 6BE8621F8B5A for <ccamp@ietfa.amsl.com>; Mon, 28 Nov 2011 08:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Level:
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, 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 POmnrxKD1eqG for <ccamp@ietfa.amsl.com>; Mon, 28 Nov 2011 08:48:06 -0800 (PST)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9D921F8B59 for <ccamp@ietf.org>; Mon, 28 Nov 2011 08:48:06 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTtO7QW/0y6jNQoYO9cffc3yR9MkcymOD@postini.com; Mon, 28 Nov 2011 08:48:06 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 28 Nov 2011 08:45:03 -0800
From: John E Drake <jdrake@juniper.net>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, CCAMP <ccamp@ietf.org>
Date: Mon, 28 Nov 2011 08:45:03 -0800
Thread-Topic: OSPF OTN considerations post IETF 82
Thread-Index: AcypvXUM4uURSfqEQWyExafq21g2KwAAy7kQABLVdSAA+DFBkA==
Message-ID: <5E893DB832F57341992548CDBB333163A4B531CFE6@EMBX01-HQ.jnpr.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se>
In-Reply-To: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_005_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82
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:48:07 -0000

Daniele,

A single switching capability value and  advertise both Unreserved and Max LSP bandwidth.

Thanks,

John

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 23, 2011 10:19 AM
To: CCAMP
Subject: [CCAMP] OSPF OTN considerations post IETF 82

Hi CCAMP,

During the OTN OSPF draft presentation at the IETF meeting in Taipei two comments were raised with respect to the following issues:

- Issue 1: Using different switching caps for each ODU type
- Issue 2: Type 2 (unres bandwidth for variable containers) and Type 3 (MAX LSP bandwidth foe variable containers always used in tandem?

WRT issue 1: the proposal was to indicate the bottom most ODUk of the muxing hiearachy in the Switching Capability field of the ISCD. After a quick talk with the other authors of the ID, the idea was to reject the proposal as it would lead to an overloading of the meaning of the Switching Capability field. (even if the definition of PSC1-2-3-4 already overloads the meaning of the switching capability field)

WRT issue 2: it is analyzed in section 5.3 of the draft (version -00). I'm copying it below for your convenience

   In this example the advertisement of an ODUflex->ODU3 hierarchy is
   shown.  In case of ODUflex advertisement the MAX LSP bandwidth needs
   to be advertised but in some cases also information about the
   Unreserved bandwidth could be useful.  The amount of Unreserved
   bandwidth does not give a clear indication of how many ODUflex LSP
   can be set up either at the MAX LSP Bandwidth or at different rates,
   as it gives no information about the spatial allocation of the free
   TSs.

   An indication of the amount of Unreserved bandwidth could be useful
   during the path computation process, as shown in the following
   example.  Supposing there are two TE-links (A and B) with MAX LSP
   Bandwidth equal to 10 Gbps each.  In case 50Gbps of Unreserved
   Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex
   LSPs of 10 GBps each, have to be restored, for sure only one can be
   restored along Link B and it is probable (but not sure) that two of
   them can be restored along Link A.

Early proposal was to have, in the case of variable containers advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as a mandatory piece of information and the Unreserved bandiwdth TLV (Type 2) as an optional piece of information.
The comment received is that optional information can lead to interworking issues and the counter proposal was to have both pieces of information as mandatory and, as a consequence, merge the two TLVs into a single one.

We'd like to hear the opinion of the WG on both issues before proceeding with any modification to the document.

Thanks,
Daniele




DANIELE CECCARELLI
System & Technology - DU IP & Broadband

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750
daniele.ceccarelli@ericsson.com
www.ericsson.com


[cid:image002.jpg@01CCADAA.05A88EC0]<http://www.ericsson.com/>

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>