[CCAMP] OSPF OTN considerations post IETF 82

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Wed, 23 November 2011 18:18 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
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 448C021F8B3A for <ccamp@ietfa.amsl.com>; Wed, 23 Nov 2011 10:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.054
X-Spam-Level:
X-Spam-Status: No, score=-5.054 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, 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 Tqk7-BUQmSbX for <ccamp@ietfa.amsl.com>; Wed, 23 Nov 2011 10:18:36 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A62FA21F8B38 for <ccamp@ietf.org>; Wed, 23 Nov 2011 10:18:35 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-5b-4ecd38f945fc
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C0.FE.09514.9F83DCE4; Wed, 23 Nov 2011 19:18:33 +0100 (CET)
Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.32]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 23 Nov 2011 19:18:33 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: CCAMP <ccamp@ietf.org>
Date: Wed, 23 Nov 2011 19:18:31 +0100
Thread-Topic: OSPF OTN considerations post IETF 82
Thread-Index: AcypvXUM4uURSfqEQWyExafq21g2KwAAy7kQABLVdSA=
Message-ID: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: it-IT, en-US
Content-Type: multipart/related; boundary="_005_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_"; type="multipart/alternative"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [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: Wed, 23 Nov 2011 18:18:37 -0000

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@01CCA9C9.D9A14FD0]<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>