Re: [CCAMP] Closing G.709 open issues

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 09 May 2013 16:57 UTC

Return-Path: <daniele.ceccarelli@ericsson.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 1B52B21F8AF4 for <ccamp@ietfa.amsl.com>; Thu, 9 May 2013 09:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 1bW44asS4ctV for <ccamp@ietfa.amsl.com>; Thu, 9 May 2013 09:57:33 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5628421F9223 for <ccamp@ietf.org>; Thu, 9 May 2013 09:57:32 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f536d000006e05-44-518bd57ae004
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7E.34.28165.A75DB815; Thu, 9 May 2013 18:57:31 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 9 May 2013 18:57:30 +0200
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Lou Berger <lberger@labn.net>, Fatai Zhang <zhangfatai@huawei.com>
Thread-Topic: Closing G.709 open issues
Thread-Index: AQHOTAyAugJRODS18Eas2l6+kjNWaZj8T3QAgABw+YCAAExsIA==
Date: Thu, 09 May 2013 16:57:30 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se>
References: <518A82D9.7080508@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B000@SZXEML552-MBX.china.huawei.com> <518BAB17.9090807@labn.net>
In-Reply-To: <518BAB17.9090807@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW711e5Ag74aiydzbrBYbJ19n9li yuzvLBYdzW9ZLPqaz7M6sHq0HHnL6rFkyU8mjw+bmtk8vlz+zBbAEsVlk5Kak1mWWqRvl8CV cXLnXOaC304VM9YvZG9gXGHcxcjJISFgIjFlx1Z2CFtM4sK99WxdjFwcQgKHGSVWtM9ngXAW MUp8+HULyOHgYBOwknhyyAekQUTATWL+4tfsIDXMAk1MEoteXmMDSQgLqEnsffuAEaJIXaJ3 6yIo20li4s0OdpA5LAIqEl1dNiBhXgFvicl3P7GC2EICExklbpw1B7E5BTQk/j1bxwRiMwrI SkzYDTGGWUBc4taT+UwQRwtILNlznhnCFpV4+fgfK8h4CQFFieX9chDlehI3pk5hg7C1JZYt fM0MsVZQ4uTMJywTGMVmIZk6C0nLLCQts5C0LGBkWcXInpuYmZNebriJERhRB7f81t3BeOqc yCFGaQ4WJXHeJK7GQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M0xnkLV/eOnLVZDrPgn15 x4w2dQefPmbkO8Huq0pOe9Cj+BOPV/WF8O66EP7uxmeOCU5uv1ZoT1p2pJ3fhtHP+NCqN1Pj bm3XNqkxnvVqtvnywO50E7ffNy6vmHKJNXj5DZcsq7PNk5j0yjmdhdtXf6m/0Pl41r/5x68E /HqXGpq6+E9m8OeUi0osxRmJhlrMRcWJAEU4pg52AgAA
Cc: CCAMP <ccamp@ietf.org>, "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>
Subject: Re: [CCAMP] 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: Thu, 09 May 2013 16:57:38 -0000

Hi Lou,

Wrt point 1) (TSG) we have 2 options.

1. leave the TSG being inferred by the label length and propose new text (see below).
2. add the TSG to the label.

Either solutions work for me, i just want to share some thoughts raised during discussions with Sergio and Fred.
A. From an implementation point of view, in case of multi-stage muxing multiple label lookups are needed to infer the TSG
B. Future proofness: we all know that TSG=10Gbps will be defined shorthly. This might make the TSG infer from label length not feasible.

Again, for me both solutions 1. and 2. work, A. And B. might not be major issues.

In case we go for 1. my proposed text is (feel free to amend):

"Please note that the TSG of the HO ODUk can be inferred from the length of the label.
In those cases where there is no LMP imposing the TSG to be used between two ends of a link,
Such information can be inferred from the signaling. E.g. In a HO ODU link a label lenght value
Of 4 would indicate TSG equal to 2,5Gbps while a value of 8 would correspond to a 1.25Gbps TSG".

BR
Daniele




>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net] 
>Sent: giovedì 9 maggio 2013 15.57
>To: Fatai Zhang
>Cc: CCAMP; 
>draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; 
>draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
>Subject: Re: Closing G.709 open issues
>
>
>Just to be clear to all: My mail summarized the results of 
>discussions that occurred on the list whose results I believe 
>are not reflected in the current document set.  I identified 3 
>items, and hope I didn't miss anything from the ~200 related 
>messages on the list. I'm not trying to change any 
>conclusions, just ensure that they are documented.
>
>Fatai,
>
>See below for specific responses.
>
>On 5/9/2013 3:12 AM, Fatai Zhang wrote:
>> Hi Lou,
>> 
>> For point 1), do you mean that you would like to have "TSG" field 
>> (ie., explicit indication) in the label format? Or just change the 
>> target text that you quoted?
>> 
>
>This point was resolved in
>http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
>to quote:
>  On 3/21/2013 9:51 AM, Lou Berger wrote:
>  > Daniele,
>  ...
>  > On 3/21/2013 9:34 AM, Daniele Ceccarelli wrote:
>  >> Lou,
>  >>
>  >> OK. No changes to signaling re explicit indication of mapping
>  >> and/or TSG in the label.
>  >
>  > I think it would be a good idea to add a comment on this in the
>  > signaling document so that we don't have to revisit it yet again...
>  >
>
>> If what you meant is the latter, could you provide some 
>proposed text to refine it.
>> 
>
>I suggest that the authors propose some text on the list for 
>the WG to review.  Given that the explicit indication issue 
>was raised by one of the co-authors I suspect he can provide 
>text that ensures the issue is covered.  There's also some 
>related text already on page 7 of the framework draft.  If the 
>authors are unable to come up with a proposal, let me know and 
>I'll propose something to the list.
>
>> For point 2), the GPIDs have been grouped based on Table 15-8 in
>> G.709 (so it seems that some payload types in Table 15-8 are 
>missed), 
>> but I think you more like the 1:1 mapping between the GPID 
>defined in 
>> [SIGNALING] and Table 15-8.
>
>The only thing I'm asking for is to verify that it is possible 
>to unambiguously signal the G.709 defined payload types with 
>GMPLS. The authors are free to use any approach, e.g., 1:1 or 
>n:1+other signaled information.
>
>> We will check and list all the ungrouped GPIDs.
>> 
>
>If you think it's possible to indicate all G.709 defined 
>payload types using the current "grouped" approach, that works 
>for me.  You just need to state such on the list.
>
>Perhaps it makes sense to just list how each PT in G.709 table 
>15-8 is represented as a good sanity check. Such a list might 
>also be useful information to add to the draft.  Here's a 
>start at such a list.  I've flagged the results of a spot 
>check (i.e., I probably have missed
>something) of PTs for which I don't see an obvious mapping.
>
>    G.709
>   Payload
>    Type       G-PID
>   -------     -----
>    0x01        ???
>    0x02
>    0x03
>    0x04
>    0x05
>    0x06
>    0x07
>    0x08
>    0x09
>    0x0A
>    0x0B
>    0x0C
>    0x0D
>    0x0E
>    0x0F
>    0x10
>    0x11
>    0x12        ???
>    0x13        ???
>    0x14        ???
>    0x15        ???
>    0x16        ???
>    0x17        ???
>    0x18        ???
>    0x19        ???
>    0x1A
>    0x1B        ???
>    0x1C
>    0x20
>    0x21
>    0x55        Unused
>    0x66        Unused
>    0x80-0x8F   ???
>    0xFD        ?? (Is this needed?)
>    0xFE        ?? (Is this needed?)
>    0xFF        Unused
>
>
>Thanks,
>Lou
>
>> 
>> 
>> 
>> Best Regards
>> 
>> Fatai
>> 
>> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Thursday, May 09, 2013 12:53 AM
>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org; 
>> draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
>> Subject: Closing G.709 open issues
>> 
>> Authors/WG,
>> 	I think all would like to wrap up the 709 documents 
>before Berlin.  
>> To do this we need to:
>> 1) Ensure all discussed points have been resolved
>> 2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC
>> 3) Capture the resolution of any comments made during 2.
>> 
>> In reviewing the close to 200 mail messages on the documents 
>since the 
>> 1st LC was issued, I see only one a few points that are 
>still missing, 
>> and I'll cover these below.  On a side note, as an 
>experiment we'll be 
>> tracking these issue via the tools issues page:
>> http://tools.ietf.org/wg/ccamp/trac/report/1
>> 
>> PLEASE reply to this message if you think there are other 
>> points/discussions that haven't been addressed in the current set of 
>> documents. Once this thread is closed, the 2nd LC will be initiated.
>> 
>> The remaining items come from the tread with the final message 
>> http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
>> The message is from me in response to Daniele's summary of 
>next steps, 
>> and has the following unresolved actions:
>> 
>> 1)  No explicit indication of TSG in the label [SIGNALING]
>> 
>>   In signaling document section 6: Clarify related text to 
>unambiguous
>>   identify the relationship between label length and TSG. Possible
>>   target text to change:
>>    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.
>> 
>> 2) Verify that the complete list of G-PIDs are defined [SIGNALING]
>> 
>>   In signaling document section 4, verify that all payload types
>>   defined in G.709 (Summarized in Table 15-8) can be represented.
>>   This issue can be resolved via an update or message to the list
>>   stating that the verification took place.
>> 
>> 3) Identification of hexadecimal representation in G.709 vs
>>    decimal in GMPLS [INFO-MODEL]
>> 
>>   The authors had previously stated the intent to just make 
>this clear
>>   in the signaling document.  I'd like to make an alternate proposal:
>>   let's do the the obvious and have the documents simply use 
>the normal
>>   (IETF) convention of using a '0x' prefix anytime a 
>hexadecimal value
>>   is represented. I believe this means that only the info-model draft
>>   needs to be updated.
>> 
>> I believe that's the complete list. Again:
>> PLEASE reply to this message if you think there are other 
>> points/discussions that haven't been addressed in the current set of 
>> documents.
>> 
>> Much thanks,
>> Lou
>> 
>> 
>> 
>> 
>> 
>