Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Tue, 29 January 2013 18:31 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 3A68421F8AB7 for <ccamp@ietfa.amsl.com>; Tue, 29 Jan 2013 10:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.049
X-Spam-Level:
X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=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 lTrOOcMBWFlf for <ccamp@ietfa.amsl.com>; Tue, 29 Jan 2013 10:31:50 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BEE1C21F8AA0 for <ccamp@ietf.org>; Tue, 29 Jan 2013 10:31:49 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-a7-510815945f0b
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B2.1D.32353.49518015; Tue, 29 Jan 2013 19:31:48 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 19:31:48 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>
Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
Thread-Index: AQHN/ZXHtjks61frnEil2tqgrQxB9Zhgcs6AgAAo+jA=
Date: Tue, 29 Jan 2013 18:31:47 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48074CE1@ESESSMB301.ericsson.se>
References: <5106DED0.3090008@labn.net> <B6585D85A128FD47857D0FD58D8120D3B372E9@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D3B372E9@xmb-rcd-x14.cisco.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre4UUY5Ag9ZLOhZP5txgsehofsti 8XrHV3YHZo8pvzeyeixZ8pPJ48OmZrYA5igum5TUnMyy1CJ9uwSujOXfTzMXLNnAWHF8+1rW BsYHqxm7GDk5JARMJFrv/WWGsMUkLtxbz9bFyMUhJHCIUaJ32hkoZzGjxPxVj1m7GDk42ASs JJ4c8gFpEBFIkLi0/C0LSI2wQBOjxIKPV5lAHBGBZkaJXRt/MUJUWUkcm76GDcRmEVCVmLTn PjuIzSvgLfFty0Sw1UICGRK37zUxgdicIPH3l8B6GQVkJSbsXgRmMwuIS9x6Mp8J4lQBiSV7 zkOdLSrx8vE/sOMkBBQllvfLgZjMApoS63fpQ3QqSkzpfgi1VVDi5MwnLBMYRWchGToLoWMW ko5ZSDoWMLKsYmTPTczMSS8338QIjJCDW34b7GDcdF/sEKM0B4uSOG+464UAIYH0xJLU7NTU gtSi+KLSnNTiQ4xMHJxSDYx6bsv7vL1FN6/nfOfRFTBZqXH92tcrnRQ2f2855Ogz6XQhzyYx tj8bnhWK9L7hVc0Ot1IW9zzT94TvW2WsZFjYacX7G13kn9kJphinGf+UPKKscnbyUcbsZ/eL tDeavZh/4reBUs6719ZNqcItf9cpJ+xesYJVoY47Oubc0tuTI1QYIzUaqpVYijMSDbWYi4oT AaQ+Fi1eAgAA
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: Tue, 29 Jan 2013 18:31:52 -0000

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
>