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

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 1 Feb 2013 12:36:31 +0100

Hi all, 

I prefer option 2) for the same reason of Zafar and Daniele.

Best regards / Mit freundlichen Grüßen
Cyril Margaria

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Zafar Ali (zali)
> Sent: Tuesday, January 29, 2013 5:41 PM
> 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: "[email-masked]" <[email-masked]>
> Date: Monday, January 28, 2013 3:25 PM
> To: "[email-masked]" <[email-masked]>
> 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:[email-masked]]
> >>> Sent: lunedì 28 gennaio 2013 4.47
> >>> To: Lou Berger
> >>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP;
> >>> [email-masked]
> >>> 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" <[email-masked]> 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"
> >>> <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On
> >>>>>> Behalf Of  Lou Berger
> >>>>>> Sent: Wednesday, January 23, 2013 9:08 AM
> >>>>>> To: Fatai Zhang
> >>>>>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-
> [email-masked]
> >>>>>> 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:[email-masked]]
> >>>>>>> Sent: Wednesday, January 23, 2013 2:11 AM
> >>>>>>> To: Fatai Zhang
> >>>>>>> Cc: CCAMP;
> >>>>>>> [email-masked]
> >>>>>>> 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:[email-masked]]
> >>>>>>>> Sent: Friday, January 18, 2013 1:42 AM
> >>>>>>>> To: Fatai Zhang
> >>>>>>>> Cc: CCAMP;
> >>>>>>>> [email-masked]
> >>>>>>>> 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
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>> _______________________________________________
> >>>>>> CCAMP mailing list
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >_______________________________________________
> >CCAMP mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Fri, 01 Feb 2013 11:06:58 -0500

All,

I like to close this poll. It looks like there is solid consensus behind
option 2. i.e., (a) use a new c-type for OTN-TDM SENDER_TSPEC and
OTN-TDM FLOWSPEC, and (b) encode ODUflex consistently as an IEEE
single-precision floating-point number.

I also understand that there has been some discussion this week among
ITU-T participants regarding tolerance as specified in the current
version of G.874.1.  I'd like to ask that the authors of the G.709
documents to discuss this and propose any desired document changes to
the WG via the list -- hopefully next week.

Much thanks,
Lou

On 1/28/2013 3:25 PM, Lou Berger wrote:
> 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.
> 
> former, options 3 and 4 match the latter.  It is worth noting that only
> Option 1 and 2 do not imply any changes to routing, while options 3 and
>> 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
>>
>>
>>> Both, including consistency between signaling and routing attributes.
>>>
>>>>
>>>> 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.
>>>
>>>>
>>>> definitions (section 4.1.2 of ospf-g709v3-05, in particular).  Note 
>>>>> This impacts existing implementations based on draft versions (and 
>>>>>> of  the bandwidth rate in bps.  I believe that this simplifies the 
>>>>>> signaling  and interoperability so I'm in agreement with 
>>> this change.
>>>>>>
>>>>>> advertises  the bandwidth using a floating point representation of 
>>>>>> bandwidth, while  signaling is using the number of tributary slots. 
>>>>>> Cc: CCAMP; [email-masked]
>>>>>> Just to be clear, I'm really just *asking* about this.  As I said 
>>>>>>> I will issue a new version tomorrow to capture all your comments.
>>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>> Fatai
>>>>>>>
>>>>>>>
>>>>>>> Cc: CCAMP; [email-masked]
>>>>>>>> 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, :-)
>>>>>>>
>>>>>>>>> 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.
>>>>>>>
>>>>>>> concatenated  ODUk).  Is this correct or did I miss something in 
>>>>>>> G709?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Lou
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>> Fatai
>>>>>>>>
>>>>>>>> Cc: CCAMP; [email-masked]
>>>>>>>>> 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
>>>>>>>>>>>> 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 
>>>>>>>>>>> the  original approach (ie., use "bit rate"field to carry "N").
>>>>>>>>>>
>>>>>>>> I guess you really still need (to be based on) the client signal 
>>>>>>>> rate at the edges.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> carry  "N"to indicate the nominal bit rate of the  ODUflex(GFP).
>>>>>>>>
>>>>>>>>> Therefore, I am proposing using one single filed ("Bit_Rate ") 
>>>>>>>> have  simpler encoding than to optimize every bit (or 8 in this 
>>>>>>>> case).
>>>>>>>>
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>>

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 2 Feb 2013 01:31:46 +0000

Hi Lou and all,

As we discussed with ITU-T experts (You can also see more about "Question on G.709 ODUflex (CBR)" in Q11), tolerance is not needed in the signaling as it is now fixed for all ODUk, including ODUflex(CBR), ie., network elements will always use 100 ppm tolerance.

I will remove Tolerance field and modify the text accordingly. 

Best Regards

Fatai

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Saturday, February 02, 2013 12:07 AM
To: CCAMP
Cc: [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

All,

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Feb 2013 08:30:47 -0500

Fatai, Authors,

On 2/1/2013 8:31 PM, Fatai Zhang wrote:
> Hi Lou and all,
> 
> As we discussed with ITU-T experts (You can also see more about
> "Question on G.709 ODUflex (CBR)" in Q11), tolerance is not needed in
> the signaling as it is now fixed for all ODUk, including
> ODUflex(CBR), ie., network elements will always use 100 ppm
> tolerance.
> 

Can someone summarize the new information, and appropriate references,
for the WG? (ITU-T lists and prepublication versions of specifications
are not available to all IETF participants.)

It also sounds like a couple of corresponding (minor) updates are needed
in g709-framework and g709-info-model.

> I will remove Tolerance field and modify the text accordingly.

Can you send the proposed changes to the list, prior to rev'ing the
draft, to ensure all are in agreement on the changes?

Much thanks,
Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 4 Feb 2013 15:40:24 +0000

Hi Lou, all,

The only reference we need to add is to G.874.1 (April 2011 amendment 2) when saying that NEs will use 100ppm tolerance for every signal type and that there is no need to signal tolerance any longer.
This needs to be reflected in framework and info model and will be done asap. 

On the ODUFlex:
-ODUFlex (GFP) uses the same number of TSs when transported along different HO ODUk links
-ODUFlex (CBR) uses a bandwidth that is 239/238 times the client bit rate so can occupy different TSs on different HO ODUk link.

PROPOSED CHANGES FOR SIGNALING
- Remove the tolerance from the traffic parameters and any reference to the configurability of 20 or 100 PPM
- Both ODUFlex will be signaled using the Bit Rate. 

PROPOSED CHANGES FOR ROUTING (2 options to be evaluated)
- Option 1: keep on advertising bit rate for both ODUFlex GFP and CBR
- Option 2: since Max LSP BW and Unreserved BW are computed for both ODU Flex types as:
	Max LSP BW = (# available TS) * (ODTUk.ts nominal bit rate) * (1-HO OPUk bit rate tolerance)
And given that (ODTUk.ts nominal bit rate) and (1-HO OPUk bit rate tolerance) are now understood to be implicit in all cases, it could be possible to advertise variable containers unreserved badwidth and MAX LSP bandwidth in number of #TS instead of IEEE format bytes/sec.

Hope i'm not forgetting about anything. Please feel free to add/modify.

BR
Daniele

>Sent: lunedì 4 febbraio 2013 14.31
>To: Fatai Zhang
>Cc: CCAMP; [email-masked]; 
>ODUflex(CBR), 
>> ie., network elements will always use 100 ppm tolerance.
>> 
>
>Can someone summarize the new information, and appropriate 
>references, for the WG? (ITU-T lists and prepublication 
>versions of specifications are not available to all IETF participants.)
>
>It also sounds like a couple of corresponding (minor) updates 
>are needed in g709-framework and g709-info-model.
>
>Can you send the proposed changes to the list, prior to 
>rev'ing the draft, to ensure all are in agreement on the changes?
>
>Much thanks,
>Lou
>
>> 
>> 
>> Best Regards
>> 
>> Fatai
>> 
>> 
>> Of Lou Berger
>> Cc: [email-masked]; 
>> I like to close this poll. It looks like there is solid consensus 
>> behind option 2. i.e., (a) use a new c-type for OTN-TDM SENDER_TSPEC 
>> and OTN-TDM FLOWSPEC, and (b) encode ODUflex consistently as an IEEE 
>>> 	We would like to try to close the discussion on the 
>G.709 drafts so 
>>> raised that realigning routing with signaling should be discussed.
>>>
>>> only options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be 
>>> 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.
>>>
>>>> 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
>>>>
>>>>
>>>>>> Note that section 4.1.1 already carries N (number of ODUs) not
>>>>> IEEE floating
>>>>>>> (and hence interop with these implementations moving forward).
>>>>> IMO this is
>>>>>>>> of bandwidth, while  signaling is using the number of 
>tributary slots.
>>>>>>>> said before, I'm open on specifics...
>>>>>>>>
>>>>>>>>>>> this case).
>>>>>>>>> in G709?
>>>>>>>>>>> the following point.
>>>>>>>>>>> ") for these two cases, in this way, we can leave 
>the "Reserved"
>>>>>>>>>>> bits for future.
>>>>>>>>>>
>>>>>>>>>> this case).

---

From: Lou Berger <[email-masked]>
Date: Mon, 04 Feb 2013 15:28:44 -0500

On 2/4/2013 10:40 AM, Daniele Ceccarelli wrote:
> Hi Lou, all,
> 
> The only reference we need to add is to G.874.1 (April 2011 amendment
> 2) when saying that NEs will use 100ppm tolerance for every signal
> type and that there is no need to signal tolerance any longer.
> 

100ppm tolerance for every signal type, is this right?  Do you mean for
all ODUFlex signal types? (And that now tolerance, i.e., either 20ppm or
100ppm, is implicit in signal type?)

> This needs to be reflected in framework and info model and will be done asap. 

Excellent.

> - Remove the tolerance from the traffic parameters and any reference to the configurability of 20 or 100 PPM

Sounds like you're in sync with Fatai.

> - Both ODUFlex will be signaled using the Bit Rate. 

And this is per the poll closed last week; glad we don't have to revisit.

> And given that (ODTUk.ts nominal bit rate) and (1-HO OPUk bit rate
> tolerance) are now understood to be implicit in all cases, it could
> be possible to advertise variable containers unreserved badwidth and
> MAX LSP bandwidth in number of #TS instead of IEEE format bytes/sec.
> 

Do you and your coauthors of (the routing draft) have any
recommendations/preferences?

Does anyone else in the WG have any views they wish to share?

Much thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 5 Feb 2013 07:59:22 +0000

Hi Lou,

Nothing new information is needed because Table 7-2 in [G709-2012] already captures the tolerance stuff (we just failed to track the progress of G709 on tolerance issue). 

I would propose the following changes based on version 6:

(1) To replace "Tolerance" with "Reseved" in the Traffic Parameters and remove the text for "Tolerance". 

(2) To add a sentence to explain *tolerance* in the formula in Section 5.1. 

The bit rate tolerance is implicit in Signal Type and the ODUflex(CBR) bit rate tolerance is always 100ppm as described in Table 7-2 of [G709-2012].

    0             1             2             3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Signal Type  |       N       |        Reserved       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              NVC           |      Multiplier (MT)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Bit_Rate                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that if it needs IEEE float number for ODUflex(GFP), I will remove "N" field (ie., to crank back to version 05).

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, February 04, 2013 9:31 PM
To: Fatai Zhang
Cc: CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

Fatai, Authors,

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Feb 2013 09:05:48 -0500

Fatai,

see below.

On 2/5/2013 2:59 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> Nothing new information is needed because Table 7-2 in [G709-2012]
> already captures the tolerance stuff (we just failed to track the
> progress of G709 on tolerance issue).
> 
okay.

> The bit rate tolerance is implicit in Signal Type and the
> ODUflex(CBR) bit rate tolerance is always 100ppm as described in
> Table 7-2 of [G709-2012].

Didn't the whole notion of passing tolerance originate with G.709 which
allows it to be variable for ODUflex(CBR)?  (See section 12.2.3 "The
client signal may have a bit-rate tolerance up to ±100 ppm".)

I think Daniele gave the needed reference in his mail the other day,
where he said:
   The only reference we need to add is to G.874.1 (April 2011
   amendment 2) ....

> Note that if it needs IEEE float number for ODUflex(GFP), I will
> remove "N" field (ie., to crank back to version 05).
> 

Given that the topic of N is closed (consensus is not to use it) I take
it your proposal is:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NVC              |        Multiplier (MT)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Bit_Rate                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is this correct?

Thanks,
Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 5 Feb 2013 14:50:02 +0000

Hi Lou,

About what reported below

where he said:

   amendment 2) ....

Fatai is right: reference is Note 2 in table 2.

Table 2/G.709:

Note 2 – The bit rate tolerance for ODUflex(CBR) signals is specified as ±100 ppm. This value may be

larger than the tolerance for the client signal itself (e.g. ±20 ppm). For such case, the tolerance is

determined by the ODUflex(CBR) maintenance signals, which have a tolerance of ±100 ppm

The G.874.1 was considered about attribute "rateTolerance" that is used to carry ODUflex (CBR) tolerance, potentially useful for CP, but at the end (taking care the Table 2 note) not-useful, since maintenance signal management compels to use +-100 ppm anyway.

Hope this clarify

Sergio

Belotti Sergio - System Architect

ALCATEL-LUCENT  Optics Division

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: martedì 5 febbraio 2013 15.06
A: Fatai Zhang
Cc: CCAMP; [email-masked]; [email-masked]
Oggetto: Re: [CCAMP] Poll on ODUFlex-related encoding

Fatai,

see below.

> (1) To replace "Tolerance" with "Reseved" in the Traffic Parameters

> and remove the text for "Tolerance".

okay.

where he said:

   amendment 2) ....

it your proposal is:

      0                   1                   2                   3

     |                            Bit_Rate                           |

Is this correct?

Thanks,

Lou

CCAMP mailing list

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Feb 2013 10:17:03 -0500

Sergio,

I'm at a bit of a disadvantage as I haven't seen the text of G.874.1
(10/12).  My understanding of Daniele's mail is that the change in that
document is that the ODUflex(CBR) *client signal* is fixed at a
tolerance of ±100 ppm, and it was this change that permitts the removal
of the tolerance field.

If this is the case, this clarification of the data plane behavior
should be referenced.  Assuming my understanding of Daniele is correct,
Faitai's text could be modified as follows:

  Note that per [G8741-2012] the bit rate tolerance is implicit in
  Signal Type.  See Table 7-2 of [G709-2012] for a listing of per
  Signal Type tolerance values.

Does this make sense?

Any of you that also follow 709 in the ITU-T, can you confirm?

Thanks,
Lou

On 2/5/2013 9:50 AM, BELOTTI, SERGIO (SERGIO) wrote:
> The G.874.1 was considered about attribute "rateTolerance" that is used
> to carry ODUflex (CBR) tolerance, potentially useful for CP, but at the
> end (taking care the Table 2 note) not-useful, since maintenance signal
> management compels to use +-100 ppm anyway.
> 
>  
> 
> Hope this clarify
> 
>  
> 
> Sergio
> 
>  
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 5 Feb 2013 15:23:08 +0000

Lou,

It is exactly the contrary: it is for note in G.709 that G874.1 has to be updated in order to consider the fixed value (due to maintenance signal) of ODUflex(CBR) tolerance.

Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: martedì 5 febbraio 2013 16.17
A: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [email-masked]; [email-masked]; Fatai Zhang
Oggetto: Re: R: [CCAMP] Poll on ODUFlex-related encoding

Sergio,

Does this make sense?

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Feb 2013 10:38:20 -0500

Sergio,
	Interesting.  So what about the 709 text that allows the client
tolerance to be lower than 100ppm, is this still permitted?  It was
explained to me that the signaled tolerance value was intended to be
used between adaptation endpoints as well.

Thanks,
Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 5 Feb 2013 15:54:16 +0000

Lou,

You're right about the misalignment, it  was a change  introduced in the April 2011 amendment 2 afaik.

We need to reference that, I suppose. 

Sergio

-----Messaggio originale-----
Da: Lou Berger [mailto:[email-masked]] 
Inviato: martedì 5 febbraio 2013 16.38
A: BELOTTI, SERGIO (SERGIO)
Cc: [email-masked]; [email-masked]; Fatai Zhang; Daniele Ceccarelli; CCAMP
Oggetto: Re: R: R: [CCAMP] Poll on ODUFlex-related encoding

Sergio,

Thanks,
Lou

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 5 Feb 2013 19:00:53 +0000

Hi- 

As my last (forwarded) email would have come out out-of-context and may
not be clear 
... Trying to do the right thing so the comment are clear.

Authors, C-campers:

Please see in-line.

-----Original Message-----
From: Fatai Zhang <[email-masked]>
Date: Tuesday, February 5, 2013 2:59 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>The bit rate tolerance is implicit in Signal Type and the ODUflex(CBR)
>bit rate tolerance is always 100ppm as described in Table 7-2 of
>[G709-2012].
>
>    0             1             2             3

I just wonder are we not better off keeping Tolerance field in signaling
and adding a statement in v7 that this field is hardcoded to 100ppm.

This has advantage of interworking with earlier draft implementations and
is also flexible for various (future/ unknown) client signal types. I.e.,
we use the same encoding as defined thus far in the document (copying from
v6): 

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |       N       |           Tolerance           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NVC              |        Multiplier (MT)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Bit_Rate                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And state that Tolerance MUST be set to 100 ppm.

Thanks

Regards...Zafar 

><snip>

---

From: John E Drake <[email-masked]>
Date: Tue, 5 Feb 2013 19:19:25 +0000

Snipped, comment inline

Irrespectively Yours,

John

> I just wonder are we not better off keeping Tolerance field in
> signaling and adding a statement in v7 that this field is hardcoded to
> 100ppm.
> 
> This has advantage of interworking with earlier draft implementations
> and is also flexible for various (future/ unknown) client signal types.
> I.e., we use the same encoding as defined thus far in the document
> (copying from
> v6):
> 
>       0                   1                   2                   3

JD: This is a very good idea.  'Per [G.874.1/2011] (or whatever is the correct reference) Tolerance MUST be set to 100 ppm.'

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Feb 2013 17:38:40 -0500

John,

See question in-line below.

On 2/5/2013 2:19 PM, John E Drake wrote:
> JD: This is a very good idea.  

Great.  Thanks for being clear on which option you support.

> 'Per [G.874.1/2011] (or whatever is
> the correct reference) Tolerance MUST be set to 100 ppm.'
> 

Is this correct (always 100ppm)?  Fatai/Sergio referred to table 7-2 in
G709 which has 20ppm for most signal types and 100ppm for others.  And
it seems there is some text that got dropped in the latest rev of
G.874.1 (from and earlier amendment).

In your role as ITU-T SG15 liaison manager, can you either figure out
what the right text & reference should be or propose a liaison that we
can send asking the ITU-T for whatever information we need to close this
issue/document?

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Feb 2013 01:04:50 +0000

Hi all,

Interesting. I support this good idea.

Best Regards

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2013 3:19 AM
To: Zafar Ali (zali); Fatai Zhang; Lou Berger
Cc: CCAMP; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Poll on ODUFlex-related encoding

Snipped, comment inline

Irrespectively Yours,

John

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Feb 2013 01:24:19 +0000

Hi Lou and all,

I think Serge and I have pointed out very clearly that Table 7-2 in G.709 is sufficient (No need to reference to G.874.1, in which it is wrong to say that “Allowable values of this attribute are 20 and 100.there is an error that should be corrected”, this error will & MUST be corrected in the next version of G.874.1).

Please have a look at Table 2 in G.709 (02/2012) and the Note 2. It says:

Note 2 – The bit rate tolerance for ODUflex(CBR) signals is specified as 100 ppm. This value may be larger than the tolerance for the client signal itself (e.g. 20 ppm). For such case, the tolerance is determined by the ODUflex(CBR) maintenance signals, which have a tolerance of 100 ppm.

I hope my mail can clarify your concern.

Note that I checked with the editor of G.709 before I said that G.709 is sufficent in the CCAMP list.

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, February 06, 2013 6:39 AM
To: John E Drake
Cc: Zafar Ali (zali); Fatai Zhang; CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

John,

issue/document?

Thanks,

Lou

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Feb 2013 01:27:41 +0000

Hi Lou,

Your format is correct.

Best Regards

Fatai

      0                   1                   2                   3

Is this correct?

Thanks,
Lou

---

From: Fred Gruman <[email-masked]>
Date: Tue, 5 Feb 2013 19:28:11 -0600

Hi Lou,

I'm not sure if you are looking at the latest version of G.709 (2/2012),
but ODUflex(GFP) now states +/- 100 ppm in Tables 7-2 and 7-8.

Although the client tolerance may be less than 100 ppm, under failure
conditions, the local clock tolerance for ODUflex(GFP) maintenance signal
generation is 100 ppm.  Thus the ODUflex(GFP) services would needs to
support the worse case, which is the maintenance signal (and thus would
always be 100 ppm).

Fred

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Feb 2013 01:30:24 +0000

Hi Fred,

You are correct.

Best Regards

Fatai

From: Fred Gruman [mailto:[email-masked]]
Sent: Wednesday, February 06, 2013 9:28 AM
To: Lou Berger
Cc: John E Drake; CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

Hi Lou,
I'm not sure if you are looking at the latest version of G.709 (2/2012), but ODUflex(GFP) now states +/- 100 ppm in Tables 7-2 and 7-8.
Although the client tolerance may be less than 100 ppm, under failure conditions, the local clock tolerance for ODUflex(GFP) maintenance signal generation is 100 ppm.  Thus the ODUflex(GFP) services would needs to support the worse case, which is the maintenance signal (and thus would always be 100 ppm).

Fred

On Tue, Feb 5, 2013 at 4:38 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

John,

Thanks,
Lou

>> [email-masked]<mailto:[email-masked]>
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Feb 2013 20:51:00 -0500

Thanks fred.  I'm looking at the 2/2012.

Lou

On 2/5/2013 8:28 PM, Fred Gruman wrote:
> conditions, the local clock tolerance for ODUflex(GFP) maintenance
> signal generation is 100 ppm.  Thus the ODUflex(GFP) services would
> needs to support the worse case, which is the maintenance signal (and
> thus would always be 100 ppm).
> 
> Fred
>

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Feb 2013 01:52:02 +0000

Hi Lou,

You said:

>Is this correct (always 100ppm)?  Fatai/Sergio referred to table 7-2 in G709 which has 20ppm for most signal types and 100ppm for others.  And it seems there is some text that 
>got dropped in the latest rev of G.874.1 (from an earlier amendment).

[Fatai] I think you mixed ODUflex and ODUj(j=0,1,2,3,4) together, so I would like to clarify a little more. 

For ODUj, the tolerance is fixed and it is 20ppm as in table 7-2 (In the draft, for the text to explain "Tolerance" field, it says "For other signal types (ie., non-ODUflex(CBR)), this field is not necessary and MUST be set to 0"). However, we are talking about ODUflex(CBR), whoes tolerance is also fixed and it is always 100ppm as in table 7-2. (Note that for ODU2e, its tolerance is fixed and is 100ppm as well).

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2013 6:39 AM
To: John E Drake
Cc: Zafar Ali (zali); Fatai Zhang; CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

John,

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Feb 2013 21:05:01 -0500

Fatai/Sergio,

G.709 has been stable for quite some time now.  I guess the discussion
on tolerance should have occurred once it was stable (1-2 years ago) or
whenever the change occurred the obviated your original motivation for
including tolerance in the first place.

Note that the framework still says:

      Therefore, bit rate and bit rate tolerance should
      also be carried in the Traffic Parameter in the signaling of
      connection setup request.

      For other ODU signal types, the bit rates and tolerances of them
      are fixed and can be deduced from the signal types.

and the info draft says:

   6. Bit rate and tolerance

   In the current traffic parameters signaling, bit rate and tolerance
   are implicitly defined by the signal type.  ODUflex CBR and Packet
   can have variable bit rates and tolerances (please refer to [OTN-FWK]
   table 2); it is thus needed to upgrade the signaling traffic
   parameters so to specify requested bit rates and tolerance values
   during LSP setup.

This text will be updated independent of the signaling format.

Lou

On 2/5/2013 8:24 PM, Fatai Zhang wrote:
> Hi Lou and all,
> 
>  
> 
> I think Serge and I have pointed out very clearly that Table 7-2 in
> G.709 is sufficient (No need to reference to G.874.1, in which it is
> wrong to say that “Allowable values of this attribute are 20 and
> 100.there is an error that should be corrected”, this error will & MUST
> be corrected in the next version of G.874.1).
> 
>  
> 
> Note 2 –The bit rate tolerance for ODUflex(CBR) signals is specified as
> 100 ppm. This value may be larger than the tolerance for the client
> signal itself (e.g. 20 ppm). For such case, the tolerance is determined
> by the ODUflex(CBR) maintenance signals, which have a tolerance of 100 ppm.
> 
>  
> 
> Cc: Zafar Ali (zali); Fatai Zhang; CCAMP;
> [email-masked];

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 6 Feb 2013 02:07:27 +0000

Hi Lou,

Yes, we all agree that FWK and Info should be updated accordingly. 

Best Regards

Fatai

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2013 10:05 AM
To: Fatai Zhang
Cc: John E Drake; Zafar Ali (zali); CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

Fatai/Sergio,

and the info draft says:

Lou

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 6 Feb 2013 08:37:16 +0000

Hi Lou,

Yes, I checked framework and info , and both have to be updated.

Sergio

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: mercoledì 6 febbraio 2013 3.05
A: Fatai Zhang
Cc: CCAMP; [email-masked]; [email-masked]
Oggetto: Re: [CCAMP] Poll on ODUFlex-related encoding

Fatai/Sergio,

and the info draft says:

Lou

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 6 Feb 2013 09:43:27 +0000

Just to summarize since different editors will update the FWK, info model and encoding docs.

We are going to reference only G.709 2012 (which has the updated text allowing only +/-100 ppm for ODUFlex) and not G.874.1 which needs to be updated accordingly.

Should this be formalized via a Liaison?

BR
Daniele  

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Fatai Zhang
>Sent: mercoledì 6 febbraio 2013 3.07
>To: Lou Berger
>Cc: John E Drake; Zafar Ali (zali); CCAMP; 
>G.709 has been stable for quite some time now.  I guess the 
>discussion on tolerance should have occurred once it was 
>stable (1-2 years ago) or whenever the change occurred the 
>obviated your original motivation for including tolerance in 
>the first place.
>
>> wrong to say that "Allowable values of this attribute are 20 and 
>> 100.there is an error that should be corrected", this error will & 
>> MUST be corrected in the next version of G.874.1).
>> 
>>  
>> 
>> Note 2 -The bit rate tolerance for ODUflex(CBR) signals is specified 
>> as 100 ppm. This value may be larger than the tolerance for 
>the client 
>> signal itself (e.g. ±20 ppm). For such case, the tolerance is 
>> determined by the ODUflex(CBR) maintenance signals, which 
>have a tolerance of 100 ppm.
>> 
>>  
>> 
>> Note that I checked with the editor of G.709 before I said 
>that G.709 
>> is sufficent in the CCAMP list.
>> 
>>  
>> 
>>  
>> 
>> Best Regards
>> 
>>  
>> 
>> Fatai
>> 
>>  
>> 
>>  
>> 
>>>> signaling and adding a statement in v7 that this field is 
>hardcoded 
>>>> to
>> 
>>>> 100ppm.
>> 
>>>> 
>> 
>>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
>6 7 8 9 0 
>>>> 1
>> 
>>>>      
>>>>      |              NVC              |        Multiplier 
>(MT)        |
>>>>      |                            Bit_Rate                 
>          |

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 6 Feb 2013 09:59:40 +0000

Ciao Daniele,

Your understanding is correct : the only reference is G.709 2012 that reports fixed value of tolerance for ODUflex (CBR) dependent of the management of maintenance signal.
The update of G.874.1 is a consequence of that. We can decide to write a "confirmation" to ITU along these lines.

BR

Sergio

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[email-masked]] 
Inviato: mercoledì 6 febbraio 2013 10.43
A: Fatai Zhang; Lou Berger
Cc: CCAMP; [email-masked]; [email-masked]
Oggetto: RE: [CCAMP] Poll on ODUFlex-related encoding

BR
Daniele

---

From: Lou Berger <[email-masked]>
Date: Wed, 06 Feb 2013 07:53:17 -0500

Sergio/Daniele/Fatai,

I think we all now clearly understand that the line/network/ODUk side of
ODUflex (CBR) needs to be allocated at 100ppm for AIS and other
maintenance signals to operate properly.  (Per note note 2 of table
7-2.) And that this means that nodes must allocate TSes based on the
tolerance implied by the signal type, per table 7-2.

But what about the client signal?  G.709 allows for lower/different
tolerance values per the same note and multiple other statements (search
for 'up to ±').

- Is the client signal still selectable by the equipment, or is it now
fixed?  If the latter, where is this change/restriction to G.709
documented? (Remember we/ccamp/ietf can't modify or limit the G.709 data
plane.)

- Is it okay for two nodes to run their client adaptation at different
tolerance values?

- Is it the client or line/ODUk signal tolerance that you are proposing
signaling?

> The update of G.874.1 is a consequence of that. We can decide to write a "confirmation" to ITU along these lines.

If you mean, ask for confirmation of our understanding, this may be a
good idea.

Thanks,
Lou

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 7 Feb 2013 01:22:57 +0000

Hi all,

Let me confirm the proposed changes in the signaling draft before updates are done.

(1) Keep "Tolerance" field as proposed by Zafar (Supported by John and me). Any objections from the WG?
(2) Remove "N" field for ODUflex(GFP) as we all agreed.

Anything missed?

Best Regards

Fatai

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2013 3:19 AM
To: Zafar Ali (zali); Fatai Zhang; Lou Berger
Cc: CCAMP; [email-masked]; [email-masked]
Subject: RE: [CCAMP] Poll on ODUFlex-related encoding

Snipped, comment inline

Irrespectively Yours,

John

---

From: "Gruman, Fred" <[email-masked]>
Date: Thu, 7 Feb 2013 14:35:14 +0000

Hi Daniele,

Although not directly related to the options you present, I did want to comment on the following statement:

>> since Max LSP BW and Unreserved BW are computed for both ODU Flex types as:

I believe Max LSP BW should be calculated differently for ODUflex(CBR) vs ODUflex(GFP).

ODUflex(CBR)
 Max LSP BW = (# available TS) * (ODTUk.ts nominal bit rate) * (1-HO OPUk bit rate tolerance)   <same as stated above>
  ** Max LSP BW encodes the adjustment of transcoding factor and ODUflex(CBR) bit rate tolerance

ODUflex(GFP)
 Max LSP BW = (# available TS) * (ODUk.ts nominal bit rate)
   k=1 if # available TS between 1-8
   k=2 if # available TS between 9-32
   k=3 if # available TS between 33-80

Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Monday, February 04, 2013 9:40 AM
To: Lou Berger; Fatai Zhang
Cc: CCAMP; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

Hi Lou, all,

On the ODUFlex:

BR
Daniele

>On Behalf Of Lou Berger
>On Behalf