Re: [bcause] to wait or not to wait

["Miaofuyou (Miao Fuyou)" <[e-mail]>]

Hi Sanjay,

How long time do you predict to get PFCP for BNG protocol released, and by which SDO? Are you aware how long time it takes for a liaison (again, between/among which SDOes?), just to get a consistent understanding for a paragraph of text between two SDOes?

It's not only about how to design CU separation feature in product, it's also about interoperability as required by operators. You have to take account of the standardization process into consideration, in the same time, to think how to meet the immediate requirement of operators, as CUSP is trying to address.

Miao
发件人：Wadhwa, Sanjay (Nokia - US/Mountain View) <[e-mail]>
收件人：Chase, Chris <[e-mail]>;STARK, BARBARA H <[e-mail]>;Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>;Mach Chen <[e-mail]>;Loa Andersson <[e-mail]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>
抄 送：[e-mail] <[e-mail]>
时间：2019-03-28 08:27:31
主 题：Re: [bcause] to wait or not to wait

Agreed. It will be to the benefit of both vendors and operators if a single protocol is defined for BNG CUPS irrespective of access. PFCP is the de-facto standard protocol between SMF/UPF today. It is hard to see why PFCP should not be used for BNG CUPS irrespective of the access over which the residential services are delivered (fixed, fixed-wireless, or hybrid). BBF has a stated goal of considering PFCP for AGF CUPS, which together with SMF/UPF functionally mimics a BNG.

-Sanjay

-----Original Message-----
From: bcause <[e-mail]> On Behalf Of Chase, Chris
Sent: Wednesday, March 27, 2019 6:48 AM
To: STARK, BARBARA H <[e-mail]>; Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>; Mach Chen <[e-mail]>; Loa Andersson <[e-mail]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]>
Cc: [e-mail]
Subject: Re: [bcause] to wait or not to wait

 AT&T has fixed wireless today on sub 6 providing residential broadband service in rural areas.  We are looking at deploying fixed wireless with 5G mmwave option 3x next year.  For this later effort we are considering a BNG that speaks S11/S1u solution.  Because we will have both our existing wireline IPoE BNG solution and this fixed wireless service there is a strong desire that we evolve to a converged BNG CU+UP solution that is common for instantiation, policy, and charging.

To me it seems an inefficient use of resources and confusion in architecting solutions in the market place to have two solutions - one being pushed by BBF that covers BNG for both wireline and wireless use cases and another using a different protocol that only covers a subcase of that.  Vendors will be compelled to support both, probably inadequately or more expensively.

Chris Chase


> -----Original Message-----
> From: bcause [mailto:[e-mail]] On Behalf Of STARK,
> BARBARA H
> Sent: Wednesday, March 27, 2019 7:02 AM
> To: 'Henderickx, Wim (Nokia - BE/Antwerp)' <[e-mail]>;
> Mach Chen <[e-mail]>; Loa Andersson <[e-mail]>;
> Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [bcause] to wait or not to wait
>
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>
> > From: Henderickx, Wim (Nokia - BE/Antwerp)
> -- snip --
> > 2. Your work is missing use cases which many operators have
> > expressed to be required on the mailing list. So you have an
> > incomplete scope and BBF incorporated them.
> -- snip --
>
> and
>
> > From: David Fan <[e-mail]>
> -- snip --
> > I think China Mobile Requirements is quite clear, Do you agree? I
> > cover the BNG requirements.
> > The problem is do we(IETF) need to wait for more requirement beyond BNG.
> -- snip --
>
> I agree with David here. The fact that other use cases (beyond the one
> presented by China Mobile -- but which is not unique to China Mobile)
> exist is certainly important information for individuals forming
> opinions in IETF. But, from what I can see, there is not agreement on
> a constraint of "if IETF does something it must do something that
> handles all use cases". And trying to push that as the primary question is muddying the waters, IMO.
>
> The CUSP proposal does not handle all use cases. I think no-one
> disagrees with that.
> It's goal is to handle the use case presented by China Mobile.
>
> So to me, the question is: Is there consensus in IETF to quickly
> develop a new protocol intended to satisfy the use case presented by
> China Mobile (but shared by numerous other operators), with no
> expectation of use case support or extensibility beyond that?
>
> If the answer is yes, then go ahead and do it and get started.
> If the answer is no, then the proponents of CUSP can start now to
> figure out where they go from here.
>
> It really shouldn't take that long to get an answer to this question.
> I'm pretty sure everyone on this list feels like they have the
> information needed to provide an educated hummed opinion on it.
>
> Other operators (with different use cases) are not asking for IETF to
> produce a new, extensible protocol to meet all use cases. These
> operators aren't asking for IETF to participate in extending PFCP. The
> lack of different-use-case operators speaking up during/after the BoF
> (and their lack of willingness to provide details on their use cases
> on the list) may be a good indicator of just how interested other operators' BNG experts would be in such an effort.
>
> And in case anyone is confused... the BoF is over and I am not a chair
> of anything in Routing Area. Nor am I in the IESG or a holder of any
> other official position potentially influential to such a decision.
> Barbara
>
> --
> bcause mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=FW70RKF5w5SM1Lm0CwnNEw&m=uJSLopx6mvTSt59z
> xAgEMmuaNaL8MIdRQ3ihRA8kuOY&s=GQ9S3twMIX7ctY1W4SOhcjWGeBKIkM
> ddYBm4bdek4GU&e=

--
bcause mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bcause

--
bcause mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bcause