Subject: Re: [bcause] to wait or not to wait

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Thu, 28 Mar 2019 10:23:36 +0000

In IETF we always try to reuse existing protocols, why – because that results much faster in a robust, high quality solution. There is very little value in reinventing the wheel so avoiding that is always a good thing.  Adding information elements to protocols is an easy part, making protocol robust/scalable/extendable is where the work and the complexities are. As such, extending existing protocol used across industry already is often more preferable.

Kind regards,
Andrew

On 2019-03-28, 5:01 PM, "bcause on behalf of qinfengwei" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Sanjay and all,
we have analysed the feasibility used PFCP in DBNG for almost half a year with 3GPP team, of course, your colleage Miao has been involved in the discussion.
PFCP is designed specifically for the wireless, there are lots of gaps between wireless and fixed-network, for example PPPoE, L2TP, Route information, detect result , Nat management and so on. Please get analysis result as the following figure, most BNG attributes need be newly defined in PFCP, and as we all know, there is not communication between different manufactures in wireless network, that means there needs a huge amount of work if PFCP is used to support BNG's function. But we have done lots of work on CUSP, and perform lab interoperation test in July 2019. For the massive deployment in 2020, we need the more professional team (such as IETF) to formulate and perfect the standard.

发件人: Wadhwa, Sanjay (Nokia - US/Mountain View)<mailto:[email-masked]>
时间: 2019/03/28(星期四)15:26
收件人: Chase, Chris<mailto:[email-masked]>;STARK, BARBARA H<mailto:[email-masked]>;Henderickx, Wim (Nokia - BE/Antwerp)<mailto:[email-masked]>;Mach Chen<mailto:[email-masked]>;Loa Andersson<mailto:[email-masked]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay)<mailto:[email-masked]>;
抄送人: bcause<mailto:[email-masked]>;
主题: 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 <[email-masked]> On Behalf Of Chase, Chris
Sent: Wednesday, March 27, 2019 6:48 AM
To: STARK, BARBARA H <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
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:[email-masked]] On Behalf Of STARK,
> BARBARA H
> Sent: Wednesday, March 27, 2019 7:02 AM
> To: 'Henderickx, Wim (Nokia - BE/Antwerp)' <[email-masked]>;
> Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>;
> Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[email-masked]>
> Cc: [email-masked]
> 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 <[email-masked]>
> -- 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
> [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/bcause

--
bcause mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bcause

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 Mar 2019 12:07:05 +0100

Hi Andrew,
I agree that at IETF we prefer to re-use IETF-designed protocols. For the
protocols designed and owned by other SDOs my experience is different.

Regards,
Greg

On Thu, Mar 28, 2019 at 11:24 AM Dolganow, Andrew (Nokia - SG/Singapore) <
[email-masked]> wrote:

>
>
> In IETF we always try to reuse existing protocols, why – because that
> results much faster in a robust, high quality solution. There is very
> little value in reinventing the wheel so avoiding that is always a good
> thing.  Adding information elements to protocols is an easy part, making
> protocol robust/scalable/extendable is where the work and the complexities
> are. As such, extending existing protocol used across industry already is
> often more preferable.
>
>
>
> Kind regards,
>
> Andrew
>
>
>
>
>
> On 2019-03-28, 5:01 PM, "bcause on behalf of qinfengwei" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
>
>
> Hi Sanjay and all,
>
> we have analysed the feasibility used PFCP in DBNG for almost half a year
> with 3GPP team, of course, your colleage Miao has been involved in the
> discussion.
>
> PFCP is designed specifically for the wireless, there are lots of gaps
> between wireless and fixed-network, for example PPPoE, L2TP, Route
> information, detect result , Nat management and so on. Please get analysis
> result as the following figure, most BNG attributes need be newly defined
> in PFCP, and as we all know, there is not communication between different
> manufactures in wireless network, that means there needs a huge amount of
> work if PFCP is used to support BNG's function. But we have done lots of
> work on CUSP, and perform lab interoperation test in July 2019. For the
> massive deployment in 2020, we need the more professional team (such as
> IETF) to formulate and perfect the standard.
>
>
>
>
>
>
>
>
>
>
>
>
> 发件人: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>
>
> 时间: 2019/03/28(星期四)15:26
>
> 收件人: Chase, Chris <[email-masked]>;STARK, BARBARA H <[email-masked]>;Henderickx,
> Wim (Nokia - BE/Antwerp) <[email-masked]>;Mach Chen
> <[email-masked]>;Loa Andersson <[email-masked]>;Vigoureux, Martin (Nokia
> - FR/Paris-Saclay) <[email-masked]>;
>
> 抄送人: bcause <[email-masked]>;
>
> 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
>
> To: STARK, BARBARA H <[email-masked]>; Henderickx, Wim (Nokia -
> BE/Antwerp) <[email-masked]>; Mach Chen <[email-masked]>;
> Loa Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <
> [email-masked]>
> Cc: [email-masked]
> 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
>
>
> > on the list) may be a good indicator of just how interested other
> operators' BNG experts would be in such an effort.
> >