Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Fatai Zhang <zhangfatai@huawei.com> Thu, 23 May 2013 02:06 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 5849911E812A for <ccamp@ietfa.amsl.com>; Wed, 22 May 2013 19:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 DR7yc99dvuGS for <ccamp@ietfa.amsl.com>; Wed, 22 May 2013 19:06:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E88F811E812C for <ccamp@ietf.org>; Wed, 22 May 2013 19:06:01 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATB30190; Thu, 23 May 2013 02:06:00 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:05:48 +0100
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 03:05:59 +0100
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.235]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Thu, 23 May 2013 10:05:55 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)
Thread-Index: AQHOV1amLRBxUXHtPkyBWPTV+jF4r5kSBU4g
Date: Thu, 23 May 2013 02:05:54 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF84319B7F7@SZXEML552-MBX.china.huawei.com>
References: <518A82D9.7080508@labn.net> <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> <F82A4B6D50F9464B8EBA55651F541CF84319B76E@SZXEML552-MBX.china.huawei .com> <519D73C0.6020901@labn.net>
In-Reply-To: <519D73C0.6020901@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
Cc: 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 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 02:06:07 -0000

Hi Lou,

I really missed this mail.

I will respond there.





Best Regards

Fatai


-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Thursday, May 23, 2013 9:41 AM
To: Fatai Zhang
Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Subject: Re: Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

Fatai,
	I think you missed the following:

http://www.ietf.org/mail-archive/web/ccamp/current/msg14861.html

As stated in that message:

> 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.

(probably best to respond to that message if you have a comment on it.)

Lou

On 5/22/2013 9:13 PM, Fatai Zhang wrote:
> Hi Lou and all,
> 
>  
> 
> I would like to double check again on the original point 2.
> 
>  
> 
> I would assume the WG is happy with the proposed approach and then
> conclude the discussion on point 2 if there is no more comment until
> this Friday.
> 
>  
> 
> Note that I think more people have shown their support on the proposed
> approach.
> 
>  
> 
>  
> 
> Best Regards
> 
>  
> 
> Fatai
> 
>  
> 
> *From:*Fatai Zhang [mailto:zhangfatai@huawei.com]
> *Sent:* Monday, May 20, 2013 5:09 PM
> *To:* Lou Berger
> *Cc:* BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;
> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
> *Subject:* RE: R: Closing G.709 open issues
> 
>  
> 
> Hi Lou,
> 
>  
> 
> I think my mail on May13rd 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 proposedapproach (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 time on discussing this
> point (because there is no issue to stick to the data plane by using the
> proposedapproach).
> 
>  
> 
> ======================================================================================================================
> 
> (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
> 
>  
> 
>  
>