[CCAMP] I: Re: R: Poll on ODUFlex-related encoding

["BELOTTI, SERGIO (SERGIO)" <[e-mail]>]

Hi all,



As for Lou's suggestion please consider the answer below to Lou question (marked SB)



Thanks

BR



Sergio



Belotti Sergio-  System Architect

ALCATE-LUCENT  Optics Division

via Trento 30 Vimercate (MB) - Italy

phone [phone]



-----Messaggio originale-----
Da: BELOTTI, SERGIO (SERGIO)
Inviato: venerdì 8 febbraio 2013 18.50
A: Lou Berger
Cc: Daniele Ceccarelli; Fatai Zhang; BELOTTI, SERGIO (SERGIO)
Oggetto: R: Re: R: [CCAMP] Poll on ODUFlex-related encoding



Hi Lou,



While I'm not sure to have well understood what you really ask,



please see in line for my reply.

I do not know whether Daniele or Fatai can have more to add.



Hope this can help.



Cheers

Sergio



Belotti Sergio - System Architect

ALCATEL-LUCENT  Optics Division









-------- Original Message --------

Subject:    Re: R: [CCAMP] Poll on ODUFlex-related encoding

Date:       Wed, 06 Feb 2013 07:53:17 -0500

From:       Lou Berger <[e-mail]>

To:   BELOTTI, SERGIO (SERGIO) <[e-mail]>,

Daniele Ceccarelli <[e-mail]>, Fatai Zhang

<[e-mail]>

CC:   CCAMP <[e-mail]>







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.)



SB> What it is really need is to have an adaptation between ODUflex (CBR) and the line (OTUk) on which map the flex container, able to manage a signal container with +-100 ppm tolerance. This is absolutely independent of the client.

Source and Sink have to be coordinated (I mean Tx and Rx) to manage this type of adaptation , while the client is with different tolerance this is not influence the TS allocation and so what we need to signal to permit the right TS allocation.



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

tolerance values?



SB> as above , the adaptation is the same independently of the client.



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

signaling?



SB> The tolerance is the tolerance of ODUflex (CBR) , that now we know is +-100ppm , but , for suggestion from Zafar, we say are now hard-coded to 100 but we leave the field to permit future flexibility.



On 2/6/2013 4:59 AM, BELOTTI, SERGIO (SERGIO) wrote:

> 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.

>



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

good idea.



Thanks,

Lou



> BR

>

> Sergio

>

> Belotti Sergio - System Architect

> ALCATEL-LUCENT  Optics Division

>

> -----Messaggio originale-----

> Da: Daniele Ceccarelli [mailto:[e-mail]]

> Inviato: mercoledì 6 febbraio 2013 10.43

> A: Fatai Zhang; Lou Berger

> Cc: CCAMP; [e-mail]; [e-mail]

> Oggetto: RE: [CCAMP] Poll on ODUFlex-related encoding

>

> 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

>

>> -----Original Message-----

>> From: [e-mail] [mailto:[e-mail]]

>> On Behalf Of Fatai Zhang

>> Sent: mercoledì 6 febbraio 2013 3.07

>> To: Lou Berger

>> Cc: CCAMP; [e-mail];

>> [e-mail]

>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>>

>> Hi Lou,

>>

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

>>

>>

>>

>>

>>

>> Best Regards

>>

>> Fatai

>>

>>

>> -----Original Message-----

>> From: Lou Berger [mailto:[e-mail]]

>> Sent: Wednesday, February 06, 2013 10:05 AM

>> To: Fatai Zhang

>> Cc: John E Drake; Zafar Ali (zali); CCAMP;

>> [e-mail];

>> [e-mail]

>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>>

>> 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).

>>>

>>>

>>>

>>> 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:[e-mail]]

>>> Sent: Wednesday, February 06, 2013 6:39 AM

>>> To: John E Drake

>>> Cc: Zafar Ali (zali); Fatai Zhang; CCAMP;

>>> [e-mail];

>>> [e-mail]

>>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>>>

>>>

>>>

>>>

>>>

>>> John,

>>>

>>>

>>>

>>> See question in-line below.

>>>

>>>

>>>

>>> On 2/5/2013 2:19 PM, John E Drake wrote:

>>>

>>>> Snipped, comment inline

>>>

>>>>

>>>

>>>> Irrespectively Yours,

>>>

>>>>

>>>

>>>> John

>>>

>>>>

>>>

>>>>>>    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                       |

>>>

>>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>

>>>>>

>>>

>>>>> 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.

>>>

>>>>

>>>

>>>>

>>>

>>>> 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

>>>

>>>

>>>

>>>>

>>>

>>>>>

>>>

>>>>>

>>>

>>>>> Thanks

>>>

>>>>>

>>>

>>>>> Regards...Zafar

>>>

>>>>>

>>>

>>>>>> <snip>

>>>

>>>>>

>>>

>>>>> _______________________________________________

>>>

>>>>> CCAMP mailing list

>>>

>>>>> [e-mail]

>>>

>>>>> https://www.ietf.org/mailman/listinfo/ccamp

>>>

>>>>

>>>

>>>>

>>>

>>>>

>>>

>>>>

>>>

>>>>

>>>

>>>>

>>>

>> _______________________________________________

>> CCAMP mailing list

>> [e-mail]

>> https://www.ietf.org/mailman/listinfo/ccamp

>>

>

>

>

>