[CCAMP] R: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
"BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com> Wed, 30 January 2013 10:33 UTC
Return-Path: <sergio.belotti@alcatel-lucent.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 8E4D721F8788 for <ccamp@ietfa.amsl.com>; Wed, 30 Jan 2013 02:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.049
X-Spam-Level:
X-Spam-Status: No, score=-7.049 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3tv1w5PQdkl for <ccamp@ietfa.amsl.com>; Wed, 30 Jan 2013 02:33:27 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id B54B921F878F for <ccamp@ietf.org>; Wed, 30 Jan 2013 02:33:26 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0UAX6P2015168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jan 2013 11:33:21 +0100
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Jan 2013 11:33:05 +0100
From: "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>
To: Fatai Zhang <zhangfatai@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Date: Wed, 30 Jan 2013 11:33:03 +0100
Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
Thread-Index: AQHN/ZXCuS8hTs+eckmWtA0MM2hSFphf/XWAgAAfDYCAAAYXgIAA5eIAgACK3mCAABq0cA==
Message-ID: <F050945A8D8E9A44A71039532BA344D822405DE895@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
References: <5106DED0.3090008@labn.net> <B6585D85A128FD47857D0FD58D8120D3B372E9@xmb-rcd-x14.cisco.com> <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se> <51081AAF.8030601@labn.net> <4A1562797D64E44993C5CBF38CF1BE4807506B@ESESSMB301.ericsson.se> <F82A4B6D50F9464B8EBA55651F541CF835859ED0@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835859ED0@SZXEML552-MBX.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] R: Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
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, 30 Jan 2013 10:33:28 -0000
Hi Fatai, This is true but clearly would not match one of your motivation of preference ..that in fact I share "(3) I don't think option 3&4 are better than option 1&2 for interworking with early implementations. Leave apart other work on routing for which , with Daniele, we spent time in these months. So I would again push for Option 2. Cheers Sergio Belotti Sergio - System Architect ALCATEL-LUCENT Optics Division -----Messaggio originale----- Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Fatai Zhang Inviato: mercoledì 30 gennaio 2013 9.58 A: Daniele Ceccarelli; Lou Berger Cc: CCAMP Oggetto: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Hi Daniele and Lou, To avoid work back and forth, I would point out that we can still get the coincidence between signaling and routing if we adopt option 3 and change routing draft. Best Regards Fatai -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: Wednesday, January 30, 2013 4:36 PM To: Lou Berger Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Lou, it was really just a joke, no hidden meanings. If we find a reasonable solution for signaling that implies modifications to the routing we will modify the routing too (here I agree with Fred that alignment between signaling and routing is a SHOULD, if not a MUST). Indepndently from changes to the routing i still believe that option 2 is the most reasonable. The fact that it is one of the options that does not imply changes to the routing is just a coincidence. Thanks, Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: martedì 29 gennaio 2013 19.54 >To: Daniele Ceccarelli >Cc: CCAMP >Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG >Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > >Daniele, > Joking aside, I think it may add value to the >discussion to highlight your rational for not wanting to >change routing. (You are after all the editor of the routing draft.) > >Is it: >- Just avoiding work for the editor (i.e., your joke...)? >- Minimizing a change at this late date? >- Minimizing impact on an early implementation? >- Something completely different? > >If you don't mind sharing... > >Thanks, >Lou > >On 1/29/2013 1:31 PM, Daniele Ceccarelli wrote: >> Option 2 for me too. >> >> Main reason? I don't have to change the routing ID! :-) >...obviously joking. >> >> Other reasons? Agree with Fatai and Zafar. And prefer 2) to >1) because defines a new C-type. >> >> BR >> Daniele >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Zafar Ali (zali) >>> Sent: martedì 29 gennaio 2013 17.41 >>> To: Lou Berger; CCAMP >>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last >>> Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) >>> >>> Hi Lou, C-campers: >>> >>> I would pick Option 2; it's cleaner and addresses the >issue related >>> to overloading the same c-type. >>> >>> Thanks >>> >>> Regards…Zafar >>> >>> >>> -----Original Message----- >>> From: "lberger@labn.net" <lberger@labn.net> >>> Date: Monday, January 28, 2013 3:25 PM >>> To: "ccamp@ietf.org" <ccamp@ietf.org> >>> Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG >Last Call >>> comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) >>> >>>> All, >>>> We would like to try to close the discussion on the >>> G.709 drafts so >>>> that we can move rapidly towards publication request. The >>>> discussion of (one of my) LC comments has resulted in several >>>> options for the signaling ODU-related traffic parameters, and the >>>> point has >>> been raised >>>> that realigning routing with signaling should be discussed. >>>> >>>> Please keep in mind that the objective of any PS is >>>> interoperability, and that there may be early >implementations that match g709v3-04. >>>> >>>> The basic question is one of if N, the number of time slots needed >>>> to support a ODUflex(GFP) signal, should be carried as a >calculated IEEE >>>> floating point number or directly. Options 1 and 2 below >reflect the >>>> former, options 3 and 4 match the latter. It is worth noting >>> that only >>>> options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be >>>> calculated for ODUflex(CBR) signal types with all options. >>>> >>>> Please state your support for one the options and, if you >wish, the >>>> justification for your position: >>>> >>>> 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>> i.e., redefine [RFC4328] Traffic Parameters c-type when used with >>>> OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is >>>> encoded as: >>>> >>>> ... the Bit_Rate field for ODUflex(GFP) MUST >>>> equal to one of the 80 values listed below: >>>> >>>> 1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts; >>>> 9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts; >>>> 33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts. >>>> >>>> 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05 >>>> i.e., use a new C-type for OTN-TDM labels. Encoding details >>>> unchanged from g709v3-04. >>>> (This option addresses the issue of the same c-type needing to >>>> be parsed based on label/switching type.) >>>> >>>> 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06 >>>> i.e., use a new C-type for OTN-TDM labels. N is directly carried >>>> for ODUflex(GFP) only. >>>> >>>> 4) Discussed, but not in any draft >>>> Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all >>>> but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic >>>> Parameters based on g709v3-06, presumably with unused fields >>>> removed. >>>> (This also addresses the issue of the same c-type needing to be >>>> parsed based on label type, but means there are different types >>>> based on signal type.) >>>> >>>> Option 1 and 2 do not imply any changes to routing, while >>> options 3 and >>>> 4 may. Routing implications will be discussed based on the >>> results of >>>> this poll, and only if there is consensus to support >positions 3 or 4. >>>> >>>> We hope to make a consensus call by the end of the week, but will >>>> continue the discussion as needed. >>>> >>>> Much thanks, >>>> Lou (and Deborah) >>>> >>>> On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote: >>>>> All, >>>>> >>>>> I think the changes proposed are meaningful and would >>> support them in >>>>> an individual or early WG draft, but they don't seem to provide >>>>> significative advantages to risk interworking issues with early >>>>> implementations. >>>>> Moreover the changes don't allow us getting totally rid of of the >>>>> bit_rate field as it is still needed for ODUflex (CBR). >>>>> >>>>> My 2c >>>>> Daniele >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Zafar Ali (zali) [mailto:zali@cisco.com] >>>>>> Sent: lunedì 28 gennaio 2013 4.47 >>>>>> To: Lou Berger >>>>>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP; >>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>> >>>>>> Hi Lou- >>>>>> >>>>>> Please see in-line. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Regards...Zafar >>>>>> >>>>>> On 1/27/13 9:46 PM, "Lou Berger" <lberger@labn.net> wrote: >>>>>> >>>>>>> Zafar, >>>>>>> Is your comment with respect to just routing or both >>>>>> signaling and >>>>>>> routing? >>>>>> >>>>>> Both, including consistency between signaling and routing >>> attributes. >>>>>> >>>>>>> >>>>>>> Also, when you say "implementations based on draft versions", >>>>>> do these >>>>>>> implementations include support for ODUflex? (Which has really >>>>>>> been the focus of the discussion.) >>>>>> >>>>>> Yes, I was referring to ODUFlex. As you know, fixed ODU is >>> signaled >>>>>> via level (0 BW) so its not an issue. >>>>>> >>>>>>> >>>>>>> BTW I took Fred's comments as related to just the new >>>>>> OTN-specific ISCD >>>>>>> definitions (section 4.1.2 of ospf-g709v3-05, in >>> particular). Note >>>>>>> that section 4.1.1 already carries N (number of ODUs) not >>>>>> IEEE floating >>>>>>> point representations of available bandwidth. >>>>>> >>>>>> What I meant is Unreserved Bandwidth at priority x and Max LSP >>>>>> Bandwidth at priority x. >>>>>> >>>>>>> >>>>>>> Much thanks, >>>>>>> Lou >>>>>>> >>>>>>> On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote: >>>>>>>> All- >>>>>>>> >>>>>>>> This impacts existing implementations based on draft >>> versions (and >>>>>>>> hence interop with these implementations moving forward). >>>>>> IMO this is >>>>>>>> a bigger change for us to assume at the last call stage. >>>>>> Furthermore >>>>>>>> we have been using IEEE floating point format for Unreserved >>>>>>>> Bandwidth/ Max LSP BW in IEEE floating point format for other >>>>>>>> technologies. Overall, I think this change suffers from the >>>>>> "law of diminishing returns". >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Regards Š Zafar >>>>>>>> >>>>>>>> >>>>>>>> On 1/27/13 10:28 AM, "Gruman, Fred" >>>>>> <fred.gruman@us.fujitsu.com> wrote: >>>>>>>> >>>>>>>>> Hi Lou, Fatai, Daniele, >>>>>>>>> >>>>>>>>> I understand the latest change to the way bandwidth is >>>>>> signaled for >>>>>>>>> ODUflex(GFP), i.e., signaling the number of tributary slots >>>>>> N instead >>>>>>>>> of the bandwidth rate in bps. I believe that this >simplifies >>>>>>>>> the signaling and interoperability so I'm in agreement with >>>>>> this change. >>>>>>>>> >>>>>>>>> However, it seems we are now inconsistent between how we >>>>>> represent >>>>>>>>> bandwidth in routing and signaling for ODUflex(GFP). Routing >>>>>>>>> advertises the bandwidth using a floating point >representation >>>>>>>>> of bandwidth, while signaling is using the number of >>> tributary slots. >>>>>>>>> It seems the same benefits would be obtained by >>>>>> advertising the max >>>>>>>>> LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in >>>>>> terms of >>>>>>>>> the number of tributary slots. >>>>>>>>> >>>>>>>>> Fred >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: ccamp-bounces@ietf.org >[mailto:ccamp-bounces@ietf.org] On >>>>>>>>> Behalf Of Lou Berger >>>>>>>>> Sent: Wednesday, January 23, 2013 9:08 AM >>>>>>>>> To: Fatai Zhang >>>>>>>>> Cc: CCAMP; >>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>> >>>>>>>>> Fatai, >>>>>>>>> >>>>>>>>> On 1/23/2013 6:49 AM, Fatai Zhang wrote: >>>>>>>>>> Hi Lou, >>>>>>>>>> >>>>>>>>>> For ODUflex(CBR), the formula is from [G.709-2012] and it >>>>>> has been >>>>>>>>>> discussed before, so please trust that there is no >>>>>> opportunity for >>>>>>>>>> misinterpretation. (Note that there are two cases, one is >>>>>>>>>> ODUflex(CBR) and another one is ODUflex(GFP)). >>>>>>>>>> >>>>>>>>>> In addtion, ODUflex cannot be concatenated by [G.709-2012]. >>>>>>>>> >>>>>>>>> Thanks for confirming my understanding. This raises the >>>>>> question of >>>>>>>>> if the new traffic should just apply to ODUFlex? Correct >>>>>> me if I'm >>>>>>>>> wrong, but I believe the [RFC4328] is sufficient in all >>>>>> other cases. >>>>>>>>> This may also make it easier for early implementations of >>>>>> the draft >>>>>>>>> as then they can limit code changes from the (-03) rev to >>>>>> only ODUflex LSPs. >>>>>>>>> >>>>>>>>> Just to be clear, I'm really just *asking* about this. >>> As I said >>>>>>>>> before, I'm open on specifics... >>>>>>>>> >>>>>>>>> Any thoughts/comments? Authors? Implementors? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lou >>>>>>>>> >>>>>>>>> >>>>>>>>>> I will issue a new version tomorrow to capture all >>> your comments. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> Fatai >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM >>>>>>>>>> To: Fatai Zhang >>>>>>>>>> Cc: CCAMP; >>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>>> >>>>>>>>>> Fatai, >>>>>>>>>> >>>>>>>>>> On 1/20/2013 9:43 PM, Fatai Zhang wrote: >>>>>>>>>>> Hi Lou, >>>>>>>>>>> >>>>>>>>>>> You said: >>>>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? >Wat's the >>>>>>>>>>>> value of this vs just carrying N? >>>>>>>>>>> >>>>>>>>>>> [Fatai] The original way (in version 04&05) is putting >>>>>> (N* Nominal >>>>>>>>>>> Rate) in "Bit_Rate" field for ODUflex(GFP), the >value is that >>>>>>>>>>> we can generalize to just use one single "Bit_Rate" >field to >>>>>>>>>>> carry IEEE float number for both cases, it seems that you >>>>>> don't agree on >>>>>>>>>>> this value, :-) >>>>>>>>>> >>>>>>>>>> I've seen differences in calculated floating point >values from >>>>>>>>>> different implementations, so I just want to ensure that >>>>>> such cases >>>>>>>>>> are avoided. >>>>>>>>>> I'm open to specific solutions and certainly will >>> deffer on the >>>>>>>>>> specifics assuming there is no opportunity for >>>>>>>>>> misinterpretation/interop issues. I don't think the >>>>>> original passed >>>>>>>>>> this threshold, i.e.,: >>>>>>>>>> >>>>>>>>>> N = Ceiling of >>>>>>>>>> >>>>>>>>>> ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate >>>>>>>>>> tolerance) >>>>>>>>>> >>>>>>>>>> ----------------------------------------------------------- >>>>>> ---------- >>>>>>>>>> ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate >>>>>> tolerance) >>>>>>>>>> >>>>>>>>>>> . Therefore, I (was) am saying that I am going to >accept your >>>>>>>>>>> suggestion to carry N for ODUflex(GFP). We are >>>>>> discussing where to >>>>>>>>>>> put N for ODUflex(GFP). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> You said: >>>>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>>>> better to >>>>>>>>>>>> have simpler encoding than to optimize every bit (or >>> 8 in this >>>>>>>>>>>> case). >>>>>>>>>>> >>>>>>>>>>> [Fatai] OK, I will add a new field (to occupy the reserved >>>>>>>>>>> bits) to carry N. >>>>>>>>>> >>>>>>>>>> As you see fit. >>>>>>>>>> >>>>>>>>>> Just to clarify my understanding, ODUflex and Virtual >>>>>> concatenation >>>>>>>>>> can never be combined for the same signal type/level, right? >>>>>>>>>> (Although an ODUflex client signal could be carried over >>>>>> a virtual >>>>>>>>>> concatenated ODUk). Is this correct or did I miss >>> something in >>>>>>>>>> G709? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best Regards >>>>>>>>>>> >>>>>>>>>>> Fatai >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>>>>>>> Sent: Friday, January 18, 2013 1:42 AM >>>>>>>>>>> To: Fatai Zhang >>>>>>>>>>> Cc: CCAMP; >>>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>>>>>>>>>> Subject: Re: [CCAMP] WG Last Call comments on >>>>>>>>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 1/15/2013 10:16 PM, Fatai Zhang wrote: >>>>>>>>>>>> Hi Lou, >>>>>>>>>>>> >>>>>>>>>>>> To avoid misunderstanding, I would like to clarify >>> more on the >>>>>>>>>>>> following point. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> It is better to have consistent format and the same >>>>>>>>>>>>>>>> meaning of one >>>>>>>>>>> field for both ODUflex(CBR) and GFP. This is why we have >>>>>>>>>>> section >>>>>>>>>>> 5.1 >>>>>>>>>>> &5.2 to describe the complex stuff. >>>>>>>>>>>>>>> I actually wasn't suggesting that N be carried in >>>>>> the bit rate >>>>>>>>>>>>>>> field. >>>>>>>>>>>>>>> The bit rate field can either be set as described or to >>>>>>>>>>>>>>> zero (i.e., ignored). At the time, I was >thinking about >>>>>> carrying N >>>>>>>>>>>>>>> in the reserved field. But perhaps the right place >>>>>> is MT, if >>>>>>>>>>>>>>> my understanding is right (would always be 1 >>>>>> otherwise). I'm >>>>>>>>>>>>>>> open to either... >>>>>>>>>>>>>>> >>>>>>>>>>>>>> [Fatai] Why not just use "bit rate"field to carry >>>>>> "N"because "N" >>>>>>>>>>>>>> implies bit rate? I am OK if you like to use a new >>>>>> filed (like >>>>>>>>>>>>>> "TS >>>>>>>>>>>>>> Number") to occupy the reserved field even though >>>>>> that I prefer >>>>>>>>>>>>>> the original approach (ie., use "bit rate"field >>> to carry "N"). >>>>>>>>>>>>> >>>>>>>>>>>>> Are you proposing dropping carrying bit rates >>>>>> represented as an >>>>>>>>>>>>> IEEE floating point and just carrying N for ODUflex? >>>>>> This seems >>>>>>>>>>>>> workable to me, but we should ensure that there are no >>>>>>>>>>>>> significant objections. >>>>>>>>>>>> >>>>>>>>>>>> [Fatai] There are two usages for " Bit_Rate " field as >>>>>> described >>>>>>>>>>>> in the lines 287-310. >>>>>>>>>>>> >>>>>>>>>>>> (1) For ODUflex(CBR), the Bit_Rate field indicates >>>>>> the nominal >>>>>>>>>>>> bit >>>>>>>>>>>> rate of ODUflex(CBR) expressed in bytes per second, >>>>>> encoded as a >>>>>>>>>>>> 32-bit IEEE single precision floating-point number. >>> For this >>>>>>>>>>>> case, we MUST use 32-bit IEEE floating point instead of >>>>>>>>>>>> "N"(Please see more in section 5.1). >>>>>>>>>>> >>>>>>>>>>> I guess you really still need (to be based on) the client >>>>>>>>>>> signal rate at the edges. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (2) For ODUflex(GFP), we can change the text (the >>>>>> lines from 305 >>>>>>>>>>>> to >>>>>>>>>>>> 310) based on your suggestion, ie., the Bit_Rate field >>>>>> is used to >>>>>>>>>>>> carry "N"to indicate the nominal bit rate of the >>> ODUflex(GFP). >>>>>>>>>>> >>>>>>>>>>> but you're says encoded as (N*Nominal Rate) right? >Wat's the >>>>>>>>>>> value of this vs just carrying N? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Therefore, I am proposing using one single filed >>> ("Bit_Rate ") >>>>>>>>>>>> for these two cases, in this way, we can leave the >"Reserved" >>>>>>>>>>>> bits for future. >>>>>>>>>>> >>>>>>>>>>> bits in the control plane are generally cheap, IMO it's >>>>>> better to >>>>>>>>>>> have simpler encoding than to optimize every bit (or >>> 8 in this >>>>>>>>>>> case). >>>>>>>>>>> >>>>>>>>>>> Lou >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hope we are now at the same page. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best Regards >>>>>>>>>>>> >>>>>>>>>>>> Fatai >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
- [CCAMP] WG Last Call: g709-framework, g709-info-m… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] WG Last Call comments on draft-ietf-ccamp… Lou Berger
- [CCAMP] 答复: WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call: g709-framework, g709-in… Lou Berger
- [CCAMP] 答复: WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] 答复: WG Last Call comments on draft-ie… Lou Berger
- [CCAMP] 答复: 答复: WG Last Call comments on draft-ie… Fatai Zhang
- Re: [CCAMP] 答复: 答复: WG Last Call comments on draf… Lou Berger
- Re: [CCAMP] 答复: 答复: WG Last Call comments on draf… BRUNGARD, DEBORAH A
- [CCAMP] Fwd: Re: 答复: 答复: WG Last Call comments on… Huub van Helvoort
- [CCAMP] 答复: 答复: 答复: WG Last Call comments on draf… Fatai Zhang
- [CCAMP] 答复: 答复: 答复: WG Last Call comments on draf… Fatai Zhang
- Re: [CCAMP] 答复: 答复: 答复: WG Last Call comments on … Lou Berger
- [CCAMP] 答复: 答复: 答复: 答复: WG Last Call comments on … Fatai Zhang
- Re: [CCAMP] 答复: 答复: 答复: 答复: WG Last Call comments… Lou Berger
- [CCAMP] 答复: 答复: 答复: 答复: 答复: WG Last Call comments… Fatai Zhang
- [CCAMP] 答复: WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] 答复: WG Last Call comments on draft-ie… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Gruman, Fred
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… John E Drake
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Zafar Ali (zali)
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Zafar Ali (zali)
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Daniele Ceccarelli
- [CCAMP] Poll on ODUFlex-related encoding (was: WG… Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Zafar Ali (zali)
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Gruman, Fred
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Daniele Ceccarelli
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Gruman, Fred
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Gruman, Fred
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Lou Berger
- [CCAMP] Fwd: RE: Poll on ODUFlex-related encoding… Lou Berger
- Re: [CCAMP] WG Last Call comments on draft-ietf-c… Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Khuzema Pithewan
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Daniele Ceccarelli
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Fatai Zhang
- [CCAMP] R: Poll on ODUFlex-related encoding (was:… BELOTTI, SERGIO (SERGIO)
- [CCAMP] R: Poll on ODUFlex-related encoding (was:… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Rajan Rao
- Re: [CCAMP] Poll on ODUFlex-related encoding (was… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Daniele Ceccarelli
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- [CCAMP] R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: Poll on ODUFlex-related encoding Lou Berger
- [CCAMP] R: R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: R: Poll on ODUFlex-related encoding Lou Berger
- [CCAMP] R: R: R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Poll on ODUFlex-related encoding Zafar Ali (zali)
- Re: [CCAMP] Poll on ODUFlex-related encoding John E Drake
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Fred Gruman
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- [CCAMP] R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Poll on ODUFlex-related encoding Daniele Ceccarelli
- [CCAMP] R: Poll on ODUFlex-related encoding BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: Poll on ODUFlex-related encoding Lou Berger
- Re: [CCAMP] Poll on ODUFlex-related encoding Fatai Zhang
- Re: [CCAMP] Poll on ODUFlex-related encoding Gruman, Fred