Re: [CCAMP] Poll on ODUFlex-related encoding

Fred Gruman <fgruman@gmail.com> Wed, 06 February 2013 01:28 UTC

Return-Path: <fgruman@gmail.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 829D821F8915 for <ccamp@ietfa.amsl.com>; Tue, 5 Feb 2013 17:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 TQojqXVPP+Vn for <ccamp@ietfa.amsl.com>; Tue, 5 Feb 2013 17:28:21 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87BD521F8477 for <ccamp@ietf.org>; Tue, 5 Feb 2013 17:28:12 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so669959wgb.23 for <ccamp@ietf.org>; Tue, 05 Feb 2013 17:28:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DQpc9rkKcQLV4FGSvlQnKvTSSr5+F+orla7bI9H7X2Y=; b=Y7dLu8xaw8oixJlkStsE6T94wNwK8jH3CNgi/5yFiwCT5rYrg6S3EzieEkCaj9kjRd jNzcrC9+UeWIZedAP+3yOYSI3FLYh4SGiUC2R4tU7RG1xbZS1ypdHZzdrvw2yRsxYkDz 0sx+7w0fgxtQsqPve6UTWBrvKIuCC5xoHD/y2WoFg3MxjsFze0LI7NUtglodr9x47FFR 7ajl9WgSSbOfkJa4vBWGvDtEdVKcUkP7beKGWLrCcEXc8Ao03PdE5jUWxGhQqFn4Xloh z03IexHGISQBf+SnU6JOc5/YooSheZ/8JD8uZwOI2B5I7Ky50EazYBQgG8pEXYKnnXrn 472A==
MIME-Version: 1.0
X-Received: by 10.180.92.100 with SMTP id cl4mr1723293wib.24.1360114091658; Tue, 05 Feb 2013 17:28:11 -0800 (PST)
Received: by 10.194.248.197 with HTTP; Tue, 5 Feb 2013 17:28:11 -0800 (PST)
In-Reply-To: <511189F0.8030709@labn.net>
References: <F82A4B6D50F9464B8EBA55651F541CF83585B3CE@SZXEML552-MBX.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D3B3CCD0@xmb-rcd-x14.cisco.com> <0182DEA5604B3A44A2EE61F3EE3ED69E145055F2@BL2PRD0510MB349.namprd05.prod.outlook.com> <511189F0.8030709@labn.net>
Date: Tue, 5 Feb 2013 19:28:11 -0600
Message-ID: <CA+CjX-pvimLXM_q46VKh8JAsxLfP32NvCVo2Mr4nUqmYZoY6fQ@mail.gmail.com>
From: Fred Gruman <fgruman@gmail.com>
To: Lou Berger <lberger@labn.net>
Content-Type: multipart/alternative; boundary=f46d04388e53498f5904d5043d8f
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Subject: Re: [CCAMP] Poll on ODUFlex-related encoding
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, 06 Feb 2013 01:28:22 -0000

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 <lberger@labn.net> wrote:

>
> 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
> >
> >
> >
> >
> >
> >
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>