Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
Khuzema Pithewan <kpithewan@infinera.com> Wed, 30 January 2013 06:46 UTC
Return-Path: <kpithewan@infinera.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 4009621F8A98 for <ccamp@ietfa.amsl.com>; Tue, 29 Jan 2013 22:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6]
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 6amiToNZltwa for <ccamp@ietfa.amsl.com>; Tue, 29 Jan 2013 22:46:37 -0800 (PST)
Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id C931921F8A89 for <ccamp@ietf.org>; Tue, 29 Jan 2013 22:46:37 -0800 (PST)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 22:46:36 -0800
From: Khuzema Pithewan <kpithewan@infinera.com>
To: Lou Berger <lberger@labn.net>, "Gruman, Fred" <fred.gruman@us.fujitsu.com>
Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
Thread-Index: AQHN/ZW/sDJ1cyws+0yoEFNCa9OlrphhCa6AgAAUpoCAAA6YgIAAFdKAgAAbJACAABHfQA==
Date: Wed, 30 Jan 2013 06:46:35 +0000
Message-ID: <D8D01B39D6B38C45AA37C06ECC1D65D53FC7885C@SV-EXDB-PROD1.infinera.com>
References: <5106DED0.3090008@labn.net> <B6585D85A128FD47857D0FD58D8120D3B372E9@xmb-rcd-x14.cisco.com> <5DF87403A81B0C43AF3EB1626511B2923C33126F@RCHEXMBP1.fnc.net.local> <51081917.3080601@labn.net> <5DF87403A81B0C43AF3EB1626511B2923C33153D@RCHEXMBP1.fnc.net.local> <5108422A.3090704@labn.net>
In-Reply-To: <5108422A.3090704@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.96.93]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] 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 06:46:39 -0000
I would prefer option#1/2. Thanks Khuzema -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, January 30, 2013 3:12 AM To: Gruman, Fred Cc: CCAMP Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) Fred, Confirmed. Option 2 had a shortened form of the text of option 1 that fully spelled it out. Sorry for the confusion. Lou On 1/29/2013 3:04 PM, Gruman, Fred wrote: > Hi Lou, > > Just to confirm, your option 2 where you state "use a new C-type for OTN-TDM labels", it was not the intent to have a new c-type for the label itself, but a new c-type for the sender-tspec/flowspec (traffic parameters). If so, I misunderstood the option and now understand the proposals. > > Thanks, > Fred > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, January 29, 2013 12:47 PM > To: Gruman, Fred > Cc: Zafar Ali (zali); CCAMP > Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last > Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04) > > Fred, > Thanks for the input. > > On 1/29/2013 12:54 PM, Gruman, Fred wrote: >> Hi Lou, >> >> I am not clear on option 2 as when I look into draft-ietf-ccamp-gmpls-signaling-g709v3-05, the IANA section shows the c-type for the GENERALIZE_LABEL defined in RFC 3473, not a new c-type. >> >> OTN-TDM Generalized Label Object: >> >> o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see >> Section 5.1) >> > > I didn't notice that inconsistency. Per > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-05#section-5: > The traffic parameters for OTN-TDM capable Switching Type are carried > in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have > the following class and type: > > - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) > - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) > > Lou > >> I'm open to either carrying ODUflex(GFP) bandwidth as floating-point or integer N, but would like to see consistency between routing and signaling documents. >> >> >> Regards, >> Fred >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf Of Zafar Ali (zali) >> Sent: Tuesday, January 29, 2013 10:41 AM >> 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] 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