Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
Khuzema Pithewan <kpithewan@infinera.com> Thu, 23 May 2013 19:54 UTC
Return-Path: <kpithewan@infinera.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 A5E9821F9180 for <ccamp@ietfa.amsl.com>; Thu, 23 May 2013 12:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599]
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 d89MD7Ohx-JL for <ccamp@ietfa.amsl.com>; Thu, 23 May 2013 12:54:00 -0700 (PDT)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8198021F97EF for <ccamp@ietf.org>; Thu, 23 May 2013 12:15:53 -0700 (PDT)
Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Thu, 23 May 2013 12:15:52 -0700
From: Khuzema Pithewan <kpithewan@infinera.com>
To: Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>
Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
Thread-Index: AQHOViWNlSQKnFOnHEGp0kX3EXiVcJkTJgxw
Date: Thu, 23 May 2013 19:15:51 +0000
Message-ID: <D8D01B39D6B38C45AA37C06ECC1D65D53FD7445C@SV-EXDB-PROD2.infinera.com>
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> <518CED28.30303@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317B943@SZXEML552-MBX.china.huawei.com> <B9FEE68CE3A78C41A2B3C67549A96F4802BCBD@FR711WXCHMBA05.zeu.alcatel-lucent.com> <F82A4B6D50F9464B8EBA55651F541CF84317BEA2@SZXEML552-MBX.china.huawei.com> <51924382.2010904@labn.net> <4A1562797D64E44993C5CBF38CF1BE480C90D5@ESESSMB301.ericsson.se> <13ea7ed3bdd.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <B9FEE68CE3A78C41A2B3C67549A96F4802C534@FR711WXCHMBA05.zeu.alcatel-lucent.com> <5193A26A.1090005@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84317D2BA@SZXEML552-MBX.china.huawei.com> <519649B4.5060408@labn.net> <F82A4B6D50F9464B8EBA55651F541CF84319607D@SZXEML552-MBX.china.huawei.com> <519B73C9.2030308@labn.net>
In-Reply-To: <519B73C9.2030308@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.156.108]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Subject: Re: [CCAMP] Closing Issue #49 (Was: Re: R: 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, 23 May 2013 19:54:32 -0000
Hi Lou, -> C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Let say some vendor uses reserved (80-8F, which will never be standardized by ITU, as per Note4 in Table 15-8) payload code point and uses some GPid 'x' in Control plane for that code point. Now if in future, Control plane defines x for some other client. There will be backward compatibility issues. Since it is clearly mentioned that these 16 code points in dataplane, will not standardized, is a standardization in way, which must be followed up in control plane by reserving 16 GPids for the purpose. Regds Khuzema -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, May 21, 2013 6:47 PM To: CCAMP Cc: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Subject: Closing Issue #49 (Was: Re: R: Closing G.709 open issues) All, In the interest of moving this discussion quickly to closure, I spent some time trying to come up with the full list of G.709 PT to G-PID mappings. In coming up with this list I tried to be consistent with the last consensus point that I can identify on this topic (the previously referenced July 2012 thread & presentation), which included: A) Defining new G-PIDs for client types not identified by an assigned G-PID (per http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml) B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a G.709 payload type, and define new G-PIDs when reuse not possible. C) No G-PID value for unused, reserved, or proprietary 709 Payload Type. Here's what I've come up with: G.709 Payload Type G-PID Type/Comment LSP Encoding ==== ===== ============== =================== 0x01 No standard value 0x02 49 CBRa G.709 ODUk 0x03 50 CBRb G.709 ODUk 0x04 32 ATM G.709 ODUk 0x05 TBA1 Framed GFP G.709 ODUk 0x06 ??? Is any valued needed? 0x07 55 Ethernet PHY G.709 ODUk (k=0) (transparent G.709 ODUk (k=3) GFP) G.709 ODUk (k=4) 0x08 58 Fiber Channel G.709 ODUk (k=2e) 0x09 TBA1 Framed GFP G.709 ODUk (k=2e) 0x0A TBA2 STM-1 G.709 ODUk (k=0) 0x0B TBA3 STM-4 G.709 ODUk (k=0) 0x0C 58 Fiber Channel G.709 ODUk (k=0) 0x0D 58 Fiber Channel G.709 ODUk (k=1) 0x0E 58 Fiber Channel G.709 ODUflex 0x0F 58 Fiber Channel G.709 ODUflex 0x10 51 BSOT G.709 ODUk 0x11 52 BSNT G.709 ODUk 0x12 TBA4 InfiniBand G.709 ODUflex 0x13 TBA4 InfiniBand G.709 ODUflex 0x14 TBA4 InfiniBand G.709 ODUflex 0x15 TBA5 Serial Digital G.709 ODUk (k=0) Interface 0x16 TBA6 Serial Digital G.709 ODUk (k=1) Interface/1.001 0x17 TBA5 Serial Digital G.709 ODUk (k=1) Interface 0x18 TBA6 Serial Digital G.709 ODUflex Interface/1.001 0x19 TBA5 Serial Digital G.709 ODUflex Interface 0x1A 56 SBCON/ESCON G.709 ODUk (k=0) (IANA to update Type field) 0x1B TBA7 DVB_ASI G.709 ODUk (k=0) 0x1C 58 Fiber Channel G.709 ODUk 0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3) (IANA to update Type field) TBA8 G.709 ODU-1.25G G.709 ODUk (k=1,2,3) 0x21 TBA8 G.709 ODU-1.25G G.709 ODUk (k=2,3,4) TBA9 G.709 ODU-Any G.709 ODUk (k=2,3) 0x55 No standard value 0x66 No standard value 0x80-0x8F No standard value 0xFD TBA10 Null Test G.709 ODUk 0xFE TBA11 Random Test G.709 ODUk 0xFF No standard value Note that there are a few differences with Fatai's list, which doesn't format well in e-mail, but is available in the archive http://www.ietf.org/mail-archive/web/ccamp/current/msg14845.html Please speak up if you think the above is not aligned with prior consensus or if you have an issue with any of the above. Much thanks, Lou On 5/20/2013 5:09 AM, Fatai Zhang wrote: > Hi Lou, > > > > I think my mail on March 13rd may have answered your following comments. > My response quoted as follows. > > > > In addition, if people look at the full list that I provided, I think > people can realize that RFC4328 (section 3.1.3) used the same approach > as the current approach of this draft (ie., 1:1 mapping between GPIDs > and payload types defined by G.709), ie., we are following what RFC4328 > did. > > > > BTW, I am not sure if we need spend so much on discussing this point > (because there is no issue to stick to the data plane by using the > current approach of this draft). > > > > ====================================================================================================================== > > (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs > defined in this draft) > > > > We realize that it is safe to use 1:1 mapping approach to avoid some > potential issues after investigation. We know this payload types have > been defined by G.709 (data plane), so physically it is better to use > 1:1 mapping approach. > > For the potential issues I mentioned above, for example, we cannot use > the existing 34 to represent 'STM-1' and 'STM-4 ', because it is > impossible to differentiate which one is 'STM-1' or 'STM-4'. In > addition, from the concept of payload type, we know that e.g, FC-100 is > different from FC-800, right? So, it is better to assign different GPIDs > to these different payload types defined by the data plane. > > > > Furthermore, I think it is much cheaper to create new GPIDs in the > control plane than in the data plane (these payload types will be > carried in the OH). > > > > > > > > > > Best Regards > > > > Fatai > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, May 17, 2013 11:16 PM > To: Fatai Zhang > Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; > draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org > Subject: Re: R: Closing G.709 open issues > > > > Fatai, > > > > That's a great start for the WG. Thank you. > > > > To answer your implied question as to why my request for the full list. > > My feeling is that there have been too many "surprises" on the 709 > > documents in areas that I thought were either obvious (but from the IETF > > & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past > > discussions. At this point, as co-chair and Document shepherd, I want > > to ensure that any open point on the documents are unambiguously closed > > and that past discussions (i.e., points of consensus) are 100% captured, > > so that we can smoothly move through the planned second LC and > > publication request. > > > > To that end, in my previous message I asked two questions about points > > where it seems you are proposing moving away from what has been > > previously been discussed & agreed to by the WG. Can you answer the > > following: > > > >>> My questions on the new G-PIDs come down to: > >>> - Why are rate specific G-PIDs being proposed (rather than > >>> continuing to use the previous approach documented in the draft > >>> and in Section 3.1.3 of rfc4328)? > > > >>> - Why are new values being defined rather than using existing > >>> values, e.g., G-PID 56? > >>> > > > > 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