Re: [CCAMP] Closing G.709 open issues
Lou Berger <lberger@labn.net> Thu, 09 May 2013 17:21 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 DEAF521F8BC0 for <ccamp@ietfa.amsl.com>; Thu, 9 May 2013 10:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.097
X-Spam-Level:
X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.168, 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 VYPPY5F2St6A for <ccamp@ietfa.amsl.com>; Thu, 9 May 2013 10:21:38 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id EDE8121F8BBC for <ccamp@ietf.org>; Thu, 9 May 2013 10:21:37 -0700 (PDT)
Received: (qmail 7344 invoked by uid 0); 9 May 2013 17:21:10 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 9 May 2013 17:21:10 -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=0Cxu0b4Qey3qg/kVFYERead3r3Hl8xUNqDhL8TjDCeU=; b=gpxbYm22AwL78rmxPs4Lal9J9mF/5a3Lkb6WddHdtatAuPKh2dY1xarGrV80udmFaqQa/9ux6RV4JRpAR8oRZI1NWlP/6j8OPghBJ5cvd4rC97Ny3s9S3Q+fDjE4c5fD;
Received: from box313.bluehost.com ([69.89.31.113]:42608 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UaUWj-00041g-US; Thu, 09 May 2013 11:21:10 -0600
Message-ID: <518BDAFF.40706@labn.net>
Date: Thu, 09 May 2013 13:21:03 -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: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
References: <518A82D9.7080508@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B000@SZXEML552-MBX.china.huawei.com> <518BAB17.9090807@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480C67D9@ESESSMB301.ericsson.se>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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>, CCAMP <ccamp@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 17:21:43 -0000
Daniele, Please see below: On 5/9/2013 12:57 PM, Daniele Ceccarelli wrote: > 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. > Sigh, I keep thinking we're "almost done" on 709 and another discussion pops up... So this is at least the third time we're discussing options 1 and 2. In the prior times, we've always agreed to follow 1. So I'll quote myself, from the last time around: Revising past decisions is fine if there's good cause, such as new information or issues identified/discovered... So let me ask, is there good cause to revisit this decision? > 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". Continuing in the case of 1, but how about: Please note that the TS granularity of a HO ODUk can be inferred from the length of the label. The values of 1, 4 and 16 indicate a TS granularity of 2.5Gps, while the values 2, 7, 32 and 80 indicate a TS granularity of 1.25Gps. Note that I added the length value of 1 based on the table on page 7 of the framework draft, but 1 isn't listed as a valid length value. One of these is wrong. (I didn't spend the time to figure out if the 1 needs to be added to valid list or should be dropped from the suggested text. Figured one of the authors would know this.) Thanks, Lou > > 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 >>> >>> >>> >>> >>> >> > > >
- Re: [CCAMP] Closing G.709 open issues Lou Berger
- [CCAMP] Closing G.709 open issues Lou Berger
- Re: [CCAMP] Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] Closing G.709 open issues Lou Berger
- Re: [CCAMP] Closing G.709 open issues Daniele Ceccarelli
- Re: [CCAMP] Closing G.709 open issues Lou Berger
- Re: [CCAMP] Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] Closing G.709 open issues Daniele Ceccarelli
- Re: [CCAMP] Closing G.709 open issues Lou Berger
- Re: [CCAMP] Closing G.709 open issues John E Drake
- Re: [CCAMP] Closing G.709 open issues Fatai Zhang
- [CCAMP] R: Closing G.709 open issues BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] Closing G.709 open issues Lou Berger
- Re: [CCAMP] Closing G.709 open issues Daniele Ceccarelli
- Re: [CCAMP] Closing G.709 open issues Lou Berger
- [CCAMP] R: Closing G.709 open issues BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: Closing G.709 open issues Lou Berger
- Re: [CCAMP] R: Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] R: Closing G.709 open issues Lou Berger
- [CCAMP] Confirming plan for Issue #48: (Was: Clos… Lou Berger
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- Re: [CCAMP] R: Closing G.709 open issues Khuzema Pithewan
- Re: [CCAMP] R: Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] R: Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] R: Closing G.709 open issues Khuzema Pithewan
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.… Lou Berger
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Fatai Zhang
- Re: [CCAMP] R: Closing G.709 open issues Fatai Zhang
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Lou Berger
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Lou Berger
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Fatai Zhang
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … John E Drake
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Fatai Zhang
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Fatai Zhang
- Re: [CCAMP] Confirming plan for Issue #48: (Was: … Fatai Zhang
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Lou Berger
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Khuzema Pithewan
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Lou Berger
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Fatai Zhang
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Khuzema Pithewan
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Lou Berger
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Lou Berger
- [CCAMP] R: Closing Issue #49 (Was: Re: R: Closing… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closin… Khuzema Pithewan
- Re: [CCAMP] R: Closing Issue #49 (Was: Re: R: Clo… Lou Berger
- [CCAMP] R: R: Closing Issue #49 (Was: Re: R: Clos… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: R: Closing Issue #49 (Was: Re: R: … Lou Berger
- [CCAMP] R: R: R: Closing Issue #49 (Was: Re: R: C… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] R: R: R: Closing Issue #49 (Was: Re: … Lou Berger