Re: [CCAMP] Closing G.709 open issues

Fatai Zhang <zhangfatai@huawei.com> Mon, 13 May 2013 03:33 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 C8AA621F8E3C for <ccamp@ietfa.amsl.com>; Sun, 12 May 2013 20:33:42 -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 yOImWnv0Vec7 for <ccamp@ietfa.amsl.com>; Sun, 12 May 2013 20:33:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8630621F8D41 for <ccamp@ietf.org>; Sun, 12 May 2013 20:33:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARH84046; Mon, 13 May 2013 03:33:36 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 04:33:08 +0100
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 04:33:32 +0100
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.222]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Mon, 13 May 2013 11:33:05 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: Closing G.709 open issues
Thread-Index: AQHOTAyDmhSnK0jr+ESubR/xu8VPgpj8bQiw///u0ICAADKIAIAABpSAgAEN6tCAADjpAIAEmsGw
Date: Mon, 13 May 2013 03:33:04 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF84317B943@SZXEML552-MBX.china.huawei.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>
In-Reply-To: <518CED28.30303@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: BP+q DC9W GQ3g Hk29 NaWy Vc3C VjKn aJEK eqCO flWY n+VK y0Ek zxr7 2IcG 4N+F 4Rzt; 5; YwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnADsAZABhAG4AaQBlAGwAZQAuAGMAZQBjAGMAYQByAGUAbABsAGkAQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AGQAcgBhAGYAdAAtAGkAZQB0AGYALQBjAGMAYQBtAHAALQBnAG0AcABsAHMALQBzAGkAZwBuAGEAbABpAG4AZwAtAGcANwAwADkAdgAzAEAAdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnADsAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAG8AdABuAC0AZwA3ADAAOQAtAGkAbgBmAG8ALQBtAG8AZABlAGwAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBsAGIAZQByAGcAZQByAEAAbABhAGIAbgAuAG4AZQB0AA==; Sosha1_v1; 7; {867613F5-D3F5-47B5-A965-26E91E9590E5}; egBoAGEAbgBnAGYAYQB0AGEAaQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 13 May 2013 03:32:53 GMT; UgBFADoAIABDAGwAbwBzAGkAbgBnACAARwAuADcAMAA5ACAAbwBwAGUAbgAgAGkAcwBzAHUAZQBzAA==
x-cr-puzzleid: {867613F5-D3F5-47B5-A965-26E91E9590E5}
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
Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" <draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@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: Mon, 13 May 2013 03:33:42 -0000

Hi Lou,

I think you have two major points here. 

(1) Do you really need 3 G-PID types for an ODU (I thought TSG was already covered)?

I think this has been discussed for quite long time before Vancouver meeting, which was famous as "penultimate" issue. Note that this TSG in GPID is different from the *implicit* TSG in label format.

I don't think we need discuss this anymore.

(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 10, 2013 8:51 PM
To: Fatai Zhang
Cc: Daniele Ceccarelli; 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



On 5/9/2013 9:41 PM, Fatai Zhang wrote:
> Hi Lou,
> 
> For point 1), "1" should be dropped and "7" should be corrected to "8" in your proposed text. 

Great.

> 
> I hesitate to make a decision on either approach, I would like to defer to the WG consensus.
> 

I believe we already have a consensus position.  The question in my mail
was do we need to revisit it.  I take your response as a no. (thank you!)

> For point 2), I compared [G.709-2003] and [G.709-2012], and checked
> the GPIDs defined in [RFC4328], I think the following new GPIDs
> (values could be 59-79) should be added (besides updating some GPIDs
> defined in RFC4328, like 32,47,49-52):
> 

I suggest going through the full PT list and identifying them in the
table (as I started in my last message) so that there is no confusion in
implementations.

In the list below it looks like you have moved away from the 'grouped
G-PID' approach.  Is there a reason for this change?

Refer to
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml
in subsequent comments.

>     Value       G-PID Type             LSP Encoding Type
>      -----       ----------             -----------------
>    59(TBA)     G.709 ODU-1.25G        G.709 ODUk 
>    60(TBA)     G.709 ODU-any          G.709 ODUk

Do you really need 3 G-PID types for an ODU (I thought TSG was already
covered)?

>    61(TBA)     PCS                    G.709 ODUk (k=0)
>    62(TBA)     FC-1200                G.709 ODUk (k=2e)
Why not us existing G-PID 58?

>    63(TBA)     eOPU2                 G.709 ODUk (k=2)

>    64(TBA)     STM-1                  G.709 ODUk (k=0)
>    65(TBA)     STM-4                  G.709 ODUk (k=0)
Why not us existing G-PID 34?

>    66(TBA)     FC-100                 G.709 ODUk (k=0)
>    67(TBA)     FC-200                 G.709 ODUk (k=1)
>    68(TBA)     FC-400                 G.709 ODUflex
>    69(TBA)     FC-800                 G.709 ODUflex
Why not us existing G-PID 58?

>    70(TBA)     IB SDR                 G.709 ODUflex
>    71(TBA)     IB DDR                 G.709 ODUflex
>    72(TBA)     IB QDR                 G.709 ODUflex
Can these be one value with rate implying SDR/DDR/QDR?

>    73(TBA)     SDIa                   G.709 ODUk (k=0)
>    74(TBA)     SDIb                   G.709 ODUk (k=1)
>    75(TBA)     SDIc                   G.709 ODUk (k=1)
>    76(TBA)     SDId                   G.709 ODUflex
>    77(TBA)     SDIe                   G.709 ODUflex

Can these be one value with rate implying a-e?

>    78(TBA)     SB/ESCON              G.709 ODUk (k=0)
Why not us existing G-PID 56?

>    79(TBA)     DVB_ASI                G.709 ODUk (k=0)
> 
> 
> 
> 

Thanks,
Lou