Re: [CCAMP] Closing G.709 open issues

Fatai Zhang <zhangfatai@huawei.com> Thu, 09 May 2013 07:12 UTC

Return-Path: <zhangfatai@huawei.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 8A36021F8E2C for <ccamp@ietfa.amsl.com>; Thu, 9 May 2013 00:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pUlYTqUbZsjI for <ccamp@ietfa.amsl.com>; Thu, 9 May 2013 00:12:28 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6369D21F8F3C for <ccamp@ietf.org>; Thu, 9 May 2013 00:12:27 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASQ19126; Thu, 09 May 2013 07:12:24 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 9 May 2013 08:12:08 +0100
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 9 May 2013 08:12:21 +0100
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Thu, 9 May 2013 15:12:18 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>, 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>
Thread-Topic: Closing G.709 open issues
Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw
Date: Thu, 09 May 2013 07:12:18 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF84317B000@SZXEML552-MBX.china.huawei.com>
References: <518A82D9.7080508@labn.net>
In-Reply-To: <518A82D9.7080508@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 07:12:32 -0000

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? 
If what you meant is the latter, could you provide some proposed text to refine it.

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. We will check and list all the ungrouped GPIDs. 




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