IETF Logo Mail Archive

[CCAMP] Closing G.709 open issues

Lou Berger <lberger@labn.net> Wed, 08 May 2013 16:52 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 0642B21F9512 for <ccamp@ietfa.amsl.com>; Wed, 8 May 2013 09:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.707
X-Spam-Level:
X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=0.558, 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 vGuXKAd8NaSN for <ccamp@ietfa.amsl.com>; Wed, 8 May 2013 09:52:49 -0700 (PDT)
Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id A73A921F94A4 for <ccamp@ietf.org>; Wed, 8 May 2013 09:52:48 -0700 (PDT)
Received: (qmail 15382 invoked by uid 0); 8 May 2013 16:52:43 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 8 May 2013 16:52:43 -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:Subject:To:MIME-Version:From:Date:Message-ID; bh=F+F+ChP2l6Xoj6duBcgqEGY9cB3hzMGIkYMAw7cLFWY=; b=sXOKGQ8IFdVGD8cudn/o9Pe+knVCOdCB5sYhCJh77jfM9V8S78+e2UMn/UBjovKnmzsr2SqYRmtpxRMlvvi6WbNCLpHEKV7tBt3o/wjhVm9ocbxAT0IlylTZH+7IBNXA;
Received: from box313.bluehost.com ([69.89.31.113]:57036 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1Ua7bf-00028a-7s; Wed, 08 May 2013 10:52:43 -0600
Message-ID: <518A82D9.7080508@labn.net>
Date: Wed, 08 May 2013 12:52:41 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: 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>
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}
Subject: [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: Wed, 08 May 2013 16:52:55 -0000

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

v2.23.0 | Report a Bug | By Email