Re: [CCAMP] Poll on ODUFlex-related encoding

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:lberger@labn.net]
Sent: Wednesday, February 06, 2013 6:39 AM
To: John E Drake
Cc: Zafar Ali (zali); Fatai Zhang; CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
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

>> CCAMP@ietf.org

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

>

>

>

>

>

>