Re: [CCAMP] ODUflex questons for OTN OSPF, draft-ietf-ccamp-gmpls-ospf-g709v3-00

Daniele Ceccarelli <> Fri, 23 December 2011 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A29D621F8AFA for <>; Fri, 23 Dec 2011 07:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.242
X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=5.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id evAvKOujQvO8 for <>; Fri, 23 Dec 2011 07:15:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3B3A621F84FC for <>; Fri, 23 Dec 2011 07:15:49 -0800 (PST)
X-AuditID: c1b4fb3d-b7cfeae000005b81-02-4ef49b23b263
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 30.97.23425.32B94FE4; Fri, 23 Dec 2011 16:15:48 +0100 (CET)
Received: from ([]) by ([]) with mapi; Fri, 23 Dec 2011 16:15:47 +0100
From: Daniele Ceccarelli <>
To: "Gruman, Fred" <>, "" <>
Date: Fri, 23 Dec 2011 16:15:47 +0100
Thread-Topic: ODUflex questons for OTN OSPF, draft-ietf-ccamp-gmpls-ospf-g709v3-00
Thread-Index: Acy8Mofory5BxbUCSdOvhwpwn2mrjgFUUeFA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
acceptlanguage: it-IT, en-US
Content-Type: multipart/alternative; boundary="_000_B5630A95D803744A81C51AD4040A6DAA2294C26CC6ESESSCMS0360e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [CCAMP] ODUflex questons for OTN OSPF, draft-ietf-ccamp-gmpls-ospf-g709v3-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Dec 2011 15:15:50 -0000

Hi Fred,

please find answers in line.

BR and once again thanks for the careful review.

From: [] On Behalf Of Gruman, Fred
Sent: venerdì 16 dicembre 2011 21.38
Subject: [CCAMP] ODUflex questons for OTN OSPF, draft-ietf-ccamp-gmpls-ospf-g709v3-00

Hi Daniele,

I have a few questions on the advertisement of ODUflex.

1) For the advertisement of the Max LSP Bandwidth of the ODUflex(CBR) signal type, it is not clear how the Max LSP BW should be computed. Specifically, should the BW advertisement take into account the HO-OPU bit rate tolerance?  I see a couple of possibilities:
  a. Max LSP BW ODUflex (CBR) = (# available TS) * (ODTUk.ts nominal bit rate)
  b. Max LSP BW ODUflex (CBR) = (# available TS) * (ODTUk.ts nominal bit rate) * (1-HO OPUk bit rate tolerance)
[[DC]] I had the chance to speack only with some of the authors and not all, but our preference would be b. It should be easier for the head node from a computational point of view. I don't see any other difference between the two options. Is there any other one i'm missing?

If bit rate tolerance is not accounted in the BW advertisement, then the path computation function would need to adjust for this factor based on an implicit assumption of the tolerance, which is 20 ppm for the HO OPUk supported at this time.

In general, it would be nice to have examples of the Max LSP BW for ODUflex(CBR) and ODUflex(GFP).

2) It is my understanding that the TSG bits indicate the tributary slot granularity when the ODUk serves as a HO-ODU. It is not clear how to fill in the TSG field for those ODUk signal types that do not support the muxing of LO-ODU. This would apply to ODU0, ODU2e and ODUflex. Should the field be set to 00 (currently reserved) or a different value?

There was a more general question on if this field was still needed on a per signal type. Given that link bundling requires the same multiplexing hierarchy across all links in the bundle, does the need for this field go away. Or do we foresee that there could be cases where different TSG could be supported in different levels of the multiplexing hierarchy.
[[DC]] Issue already solved in the -01 version. The -01 version has not been published yet as we were waiting for the SC issue to be solved. By the way the idea was to have

      - TSG: Tributary Slot Granularity (3bit): Used for the
      advertisement of the supported Tributary Slot granularity

         - 0 - Reserved

         - 1 - 1.25 Gbps/2.5Gbps

         - 2 - 2.5 Gbps only

         - 3 - 1.25 Gbps only

         - 4 - Don't care

         - 5-7 - Reserved

      Where value 1 is used on those interfaces where the fallback
      procedure is enabled and the default value of 1.25 Gbps can be
       falled back to 2.5 if needed.  Values 2 and 3 are used where there
      is no chance to modify the TSG.  In the former case the interface
      being advertised is a G.709v1 and in the latter the interface is a
      G.709v3 with fallback procedure disabled.  Value 4 is used for non
      multiplexed signal (i.e. non OTN client).

3) For a link that supports the 3 types of ODUflex (CBR, GFP-resizable, GFP-non-resizable), an implementation would need to advertise the Max LSP BW and Unreserved BW against signal types of 20, 21, and 22. For efficiency, is it permitted for implementations that support both GFP-resizable and GFP-non-resizable, they MAY advertise the BW under the resizable signal type (21) and have it implicitly understood that it also supports GFP-non-resizable with the same BW.  (Note that implementations could advertise them separately, especially if the BW were different).  Or MUST implementations advertise GFP-resizable (ST=21) and GFP-non-resizable (ST=22) explicitly.
[[DC]] MAY should be fine.