Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues)

Lou Berger <lberger@labn.net> Mon, 20 May 2013 20:42 UTC

Return-Path: <lberger@labn.net>
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 DC96B21F9680 for <ccamp@ietfa.amsl.com>; Mon, 20 May 2013 13:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.457
X-Spam-Level:
X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQlK+FixJqAE for <ccamp@ietfa.amsl.com>; Mon, 20 May 2013 13:41:57 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 570E821F9676 for <ccamp@ietf.org>; Mon, 20 May 2013 13:41:57 -0700 (PDT)
Received: (qmail 21159 invoked by uid 0); 20 May 2013 20:41:34 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 20 May 2013 20:41:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xslIOGgELaQR6kFEN1qk0DfTVAE1Y/r2KZT90pQqSYE=; b=ckIrMu8HotfsQXZt0UR44JCmIKWXbOKUqbccza4zyp+TrZ1U+V8BHMKq0hD+N47J9Pole5/n3C38lD1kp1blgDgpNYluRsM2E0OnI5MdjQUh8mNxol83kp4V0Om1atgk;
Received: from box313.bluehost.com ([69.89.31.113]:51190 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UeWti-0002iE-0L; Mon, 20 May 2013 14:41:34 -0600
Message-ID: <519A8A7D.5020002@labn.net>
Date: Mon, 20 May 2013 16:41:33 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: John E Drake <jdrake@juniper.net>
References: <518A82D9.7080508@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B000@SZXEML552-MBX.china.huawei.com> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se> <518BDAFF.40706@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B39A@SZXEML552-MBX.china.huawei.com> <519657FE.5030602@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D5009B0@BL2PRD0510MB349.namprd05.prod.outlook.com> <519693DF.6000003@labn.net> <0182DEA5604B3A44A2EE61F3EE3ED69E1D504EAD@BL2PRD0510MB349.namprd05.prod.outlook.com>, <519A6EC1.4080205@labn.net> <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>
In-Reply-To: <9574E62A-6A68-4290-A103-8A0A750E2004@juniper.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>, "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" <draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org>, CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709 open issues)
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: Mon, 20 May 2013 20:42:02 -0000

On 5/20/2013 3:18 PM, John E Drake wrote:
> I think that's a big mistake(tm).  If a new rate or TSG is introduced
> the RFC would need to be updated even though the encoding does not
> require it.
> 

Well that's easily addressed, via something like:

Length (12 bits): indicates the number of bits of the Bit Map field,
i.e., the number of TS in the HO ODUk link.  The TS granularity,
1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's rate
by the value of the Length field.  In the context of [G709-2012], the
values of 4 and 16 indicate a TS granularity of 2.5Gps, and the values
2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.

Lou

> Sent from my iPhone
> 
> On May 20, 2013, at 2:43 PM, "Lou Berger" <lberger@labn.net> wrote:
> 
>> John,
>> There's still some ambiguity here.  How about:
>> On 5/20/2013 9:15 AM, John E Drake wrote:
>>> Length (12 bits): indicates the number of bits of the Bit Map field,
>>> i.e., the number of TS in the HO ODUk link.  The TS granularity,
>>> 1.25Gbps or 2.5Gbps, may be derived by dividing the HO ODUk link's
>>> rate by the value of the Length field.  
>>
>>
>> Replace:
>>> For example, for an HO ODU2
>>> link, whose link rate is 10Gbps, the value of the Length field will
>>> be either 4 or 8 and the TS granularity will be either 2.5Gbps or
>>> 1.25Gbps, respectively.
>> With:
>>
>>   The values of 4 and 16 indicate a TS granularity of 2.5Gps, while
>>   the values 2, 8, 32 and 80 indicate a TS granularity of 1.25Gps.
>>
>> Lou
>>
>>
>>> Irrespectively Yours,
>>>
>>> John
>>>
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Friday, May 17, 2013 1:33 PM
>>>> To: John E Drake
>>>> Cc: Fatai Zhang; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org;
>>>> CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>>>> Subject: Re: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
>>>> open issues)
>>>>
>>>> John,
>>>>    I guess you haven't been paying attention!  The rewrite
>>>> originated from Daniele, was tweaked by me and then fixed by Fatai.
>>>>
>>>> Do you have an alternate proposal to address issue#48?
>>>> Issue #48="In signaling document section 6: Clarify related text [i.e.,
>>>> the OLD text] to unambiguously identify the relationship between label
>>>> length and TSG."
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>> On 5/17/2013 1:15 PM, John E Drake wrote:
>>>>> Lou,
>>>>>
>>>>> I think the original text is fine and your attempted re-write
>>>> completely mangled its meaning.  The label is a bit vector whose length
>>>> is equal to the ODUk rate / TSG.
>>>>>
>>>>> Irrespectively Yours,
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>>>> Behalf Of Lou Berger
>>>>>> Sent: Friday, May 17, 2013 9:17 AM
>>>>>> To: Fatai Zhang
>>>>>> Cc: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org; CCAMP;
>>>>>> draft- ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>>>>>> Subject: [CCAMP] Confirming plan for Issue #48: (Was: Closing G.709
>>>>>> open issues)
>>>>>>
>>>>>> Authors/WG,
>>>>>>    From the mail on the list it seems to me that we've reached
>>>> closure
>>>>>> on Issue #48: "Document no explicit indication of TSG in the label"
>>>>>> (http://trac.tools.ietf.org/wg/ccamp/trac/ticket/48).  I'd like to
>>>>>> confirm my reading.
>>>>>>
>>>>>> As I read the list, this issue will be resolved by making the
>>>>>> following change to draft-ietf-ccamp-gmpls-signaling-g709v3.
>>>>>>
>>>>>> OLD
>>>>>>  Note that the
>>>>>>  Length field in the label format MAY be used to indicate the TS
>>>>>>  type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps)
>>>>>>  since the HO ODUk type can be known from IF_ID RSVP_HOP Object. In
>>>>>>  some cases when there is no Link Management Protocol (LMP) or
>>>>>>  routing to make the two end points of the link to know the TSG,
>>>>>>  the TSG information used by another end can be deduced from the
>>>>>>  label format. For example, for HO ODU2 link, the value of the
>>>>>>  length filed will be 4 or 8, which indicates the TS granularity is
>>>>>>  2.5Gbps or 1.25Gbps, respectively.
>>>>>>
>>>>>> NEW
>>>>>>  Please note that the TS granularity of an HO ODUk can be inferred
>>>>>> from
>>>>>>  the length of the label. The values of 4 and 16 indicate a TS
>>>>>>  granularity of 2.5Gps, while the values 2, 8, 32 and 80 indicate a
>>>> TS
>>>>>>  granularity of 1.25Gps.
>>>>>>
>>>>>> Please speak up if you disagree with this resolution.
>>>>>>
>>>>>> Thanks,
>>>>>> Lou
>>>>>>
>>>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote:
>>>>>>> For point 1), "1" should be dropped and "7" should be corrected to
>>>>>> "8" in your proposed text.
>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> 
> 
> 
>