Re: [bcause] Barbara's view (was Re: to wait or not to wait)

"Miaofuyou (Miao Fuyou)" <fuyou.miao@huawei.com> Fri, 29 March 2019 09:10 UTC

Return-Path: <fuyou.miao@huawei.com>
X-Original-To: bcause@ietfa.amsl.com
Delivered-To: bcause@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B20120266 for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 02:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.631
X-Spam-Level:
X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI6yLF0llr_7 for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 02:10:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D1A120467 for <bcause@ietf.org>; Fri, 29 Mar 2019 02:10:06 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D3D8477C5EBA65682DC9 for <bcause@ietf.org>; Fri, 29 Mar 2019 09:10:01 +0000 (GMT)
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 29 Mar 2019 09:10:00 +0000
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.207]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Fri, 29 Mar 2019 17:09:57 +0800
From: "Miaofuyou (Miao Fuyou)" <fuyou.miao@huawei.com>
To: "STARK, BARBARA H" <bs7652@att.com>, "'Henderickx, Wim (Nokia - BE/Antwerp)'" <wim.henderickx@nokia.com>, Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org>, Donald Eastlake <d3e3e3@gmail.com>
CC: "bcause@ietf.org" <bcause@ietf.org>
Thread-Topic: Barbara's view (was Re: to wait or not to wait)
Thread-Index: AdTlh4dhZxZ42+N8TMKJlsLe0gQfPwAh6Zv4
Date: Fri, 29 Mar 2019 09:09:57 +0000
Message-ID: 0484FBCE-34ED-432A-90F9-A054D9412F85
References: <2D09D61DDFA73D4C884805CC7865E6114E11FA36@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E11FA36@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_0484FBCE34ED432A90F9A054D9412F85_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/JLluGE8pOP6h7g3lDrbKLm9ot1g>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)
X-BeenThere: bcause@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <bcause.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bcause>, <mailto:bcause-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bcause/>
List-Post: <mailto:bcause@ietf.org>
List-Help: <mailto:bcause-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bcause>, <mailto:bcause-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2019 09:10:11 -0000

Thanks, Barbara, a good summary!

One thing I am confused is "divert resource from BBF to IETF".  I think it's a statement rather than fact. There are very limited overlapping of participants base between BBF and IETF(less than 15 on many areas besides BNG, my estimation). In the same time, if you care both, why not participate both? If not, it's your problem, not problem of IETF or others who are working hard to meet the immediate deployment requirement.
发件人:STARK, BARBARA H <bs7652@att.com>
收件人:'Henderickx, Wim (Nokia - BE/Antwerp)' <wim.henderickx@nokia.com>;Miaofuyou (Miao Fuyou) <fuyou.miao@huawei.com>;Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org>;Donald Eastlake <d3e3e3@gmail.com>
抄 送:bcause@ietf.org <bcause@ietf.org>
时间:2019-03-28 18:41:31
主 题:Barbara's view (was Re: to wait or not to wait)

Well, since we’re talking Barbara’s view...

My view is that there needs to be a decision in IETF to work on CUSP or not. One way or the other. From the comments on the list, it appears everyone else is interpreting “wait for BBF” the same way I am: it’s an implicit decision not to work on CUSP (because the probability of IETF working on CUSP decreases as more time passes).

Just to be clear: I have not expressed on this list whether I’m in favor of IETF working on CUSP (or against). But I think it’s clear that *I* have no personal interest in being involved in such work. It’s also true that I have been forming an opinion.

To form my opinion, I’ve been collecting the pros and cons (aka criteria for evaluation) I’ve read on this list. I’m sharing these on the list with the very selfish hope that maybe by acknowledging these, people won’t feel the need to express the same pros and cons over (and over and over) again.

For IETF working CUSP :
China Mobile very much wants CUSP. It satisfies their use case. They have 150+ million customers and a whole lot of BNGs using CUSP. Extensive experience with CUSP. [And I agree that the presentation from China Mobile was excellent and very informative.]
There are other operators with the same basic use case (but who may have specific needs that are different due to different networks and governments)
CUSP is highly complete (for the China Mobile deployment) and there is significant experience (2 years) with it in a live, deployed environment.

Against IETF working CUSP:
CUSP is not extensible for other (converged, multi/hybrid-access) use cases.
If CUSP is being worked in IETF, it may divert some resources from BBF effort to IETF. Not sure how much.
Other vendors (other than the 2 who created CUSP) may feel the need to also implement CUSP, which would divert resources from their implementing a “one protocol to solve all use cases” protocol. Put another way, there becomes a need for “fixed network, disaggregated BNG” vendors to implement and support 2 protocols instead of just one – which increases complexity of BNG implementations.

I’m sure I missed some. I’m in a hurry to go drink beer. Feel free to unicast me with the ones I missed (if you find this summary useful), and I’ll send an updated list of pros and cons tomorrow.

Barbara

From: Henderickx, Wim (Nokia - BE/Antwerp)

Look at the people who expressed why they wanted PFCP. Barbara’s view is one element but not the only one.

From: "Miaofuyou (Miao Fuyou)" <fuyou.miao@huawei.com<mailto:fuyou.miao@huawei.com>>

Please read Barbara’s message dated 3/27! There are insightful observations to your “many more”.

发件人: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderickx@nokia.com]
发送时间: 2019年3月29日 0:06
收件人: Miaofuyou (Miao Fuyou) <fuyou.miao@huawei.com<mailto:fuyou.miao@huawei.com>>; Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org<mailto:gdalle=40juniper.net@dmarc.ietf.org>>; Donald Eastlake <d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>>
抄送: bcause@ietf.org<mailto:bcause@ietf.org>
主题: Re: [bcause] 答复: to wait or not to wait

There are many more who did and voiced their opinion.

From: bcause <bcause-bounces@ietf.org<mailto:bcause-bounces@ietf.org>> on behalf of "Miaofuyou (Miao Fuyou)" <fuyou.miao@huawei.com<mailto:fuyou.miao@huawei.com>>
Date: Thursday, 28 March 2019 at 17:03
To: Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org<mailto:gdalle=40juniper.net@dmarc.ietf.org>>, Donald Eastlake <d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>>
Cc: "bcause@ietf.org<mailto:bcause@ietf.org>" <bcause@ietf.org<mailto:bcause@ietf.org>>
Subject: [bcause] 答复: to wait or not to wait


Which operator has analyzed details of BNG CU against PFCP protocols? AFAIK, it’s only CMCC.  Informed decision counts, not number!


-          Miao

发件人: bcause [mailto:bcause-bounces@ietf.org] 代表 Gregory Dalle
发送时间: 2019年3月28日 22:47
收件人: Donald Eastlake <d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>>
抄送: bcause@ietf.org<mailto:bcause@ietf.org>
主题: Re: [bcause] to wait or not to wait

Hi Donald,

There is no paradox here. CUSP is existing to 1 operator (China Mobile) and 2 vendors (Huawei/ZTE). We have yet to hear anybody else who says CUSP covers their requirements.
So yes, you are asking to rubber stamp a new protocol, that is known only to satisfy one operator.
If you want to compare protocol to protocol, PFCP has reached standard status 2 years ago, having been implemented by a number of vendors and in production in a number of operators network. That makes it worth confirming we can use it for BNG based on additional IEs.

I hear the argument, that it is one operator but a very large one, as Greg emphasized it. But it makes no sense to say that this is representative of the market because of size. When it is about capturing requirements, I trust 30 operators with 5M subscribers each, more than 1 operator with 150M subscribers. Wim sent a couple of shortcomings with CUSP yesterday, that in my opinion would not have been missed if more diversity of operators had been involved (lawful intercept is a good example; there was significant work done at 3GPP, where operators were concerned on how to reconcile control plane and user plane information for the lawful authorities).

At this stage, I am not sure we are learning much from the mailing list. I can only hope that we eventually come together and channel all the passion and energy into what is at the end of the BoF meeting notes:

“Tendency to prefer BBF complete this work on requirements.”

Greg

PS: just to avoid any misunderstanding, I like China Mobile! I thought the content prepared for the BoF was excellent and that’s great that China Mobile is taking the initiative to solve their problems by evolving the architecture. So nothing personal, just my opinion on what I think is the best way forward.
On Mar 28, 2019, at 7:31 AM, Donald Eastlake <d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>> wrote:
You know it is interesting: When convenient to their argument, some say that starting with S-CUSP means inventing a new protocol starting from scratch. Others, when convenient to their argument, say that starting with S-CUSP means rubber stamping a complete existing protocol. It really can't be that both of these are true.

It is understood that when a protocol is turned over to the IETF, the IETF has change control.

As far as I know, PFCP is under 3GPP change control. And, while there are limited vendor extension mechanisms in PFCP, I'm not aware of any proposal to put PFCP under BBF (or IETF) change control.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>

--
bcause mailing list
bcause@ietf.org<mailto:bcause@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=b7uOOH94vS8SLizH9edYuSighMIVDbp5v3QRWGeBygQ&s=wO6Qromk0vPZLFVWDYCkudGetM3GoDv_KbhJ9wv3Ddk&e=