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

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 28 Mar 2019 11:05:40 +0000

Hi Fengwei
We have a working implementation of PFCP with extensions for some of the common encapsulations on BNG. Based on implementation experience and also detailed analysis of other relevant encapsulations, let me say what you perceive and show below is rather naïve and misleading. PFCP uses well defined set of flexible match rules and actions to define forwarding state and processing on the UP, rather than dumping fixed format tables. These rules for BNG related applications either use existing IEs for specifying encaps/decaps or have trivial extension to existing IEs or define new IEs. The whole protocol machinery, messaging and containers that convey the state is used as is. Not to mention the overload handling, liveness detection, usage tracking, actions for mirroring, steering etc that is part of the base protocol. It takes a while to get all this right in a new protocol that is designed from scratch.
The state info that you need to pass to the UP does not depend on the protocol used but rather access and core facing interface encapsulations. So, this is same for any protocol that you will implement.
Just as a parallel, on a BNG we easily have over hundred RADIUS VSAs and DIAMETER AVPs (for applications such as NASREQ, Gx, Gy), which are added or extended incrementally as you add features. It is flawed thinking if you believe this is where the complexity lies. It is the underlying protocol that is the key. Adding support to specify new encapsulations in PFCP or new data-path actions (e.g. NAT) is incremental and rather straightforward. PFCP IEs allow vendor specific extensions where vendor can be an SDO. Capabilities aside, PFCP is very conscious about minimizing chattiness and round trips needed to create subscriber sessions, which is critical. Unfortunately, unlike PFCP , the alternatives (including one you endorse) are not optimized.

On inter-op, all I can say is that the base PFCP protocol is deployed in production in some of the largest packet core networks out there. Multiple vendors support it. Hardening is based on full scale deployments rather than limited trials/POCs. Given your scale requirement, you will likely be better off with a base protocol that has its design vetted by large deployments.
I am happy to discuss details with you to clear obvious misperceptions on PFCP. Please feel free to reach out per your convenience.

Thanks
-Sanjay

From: qinfengwei <[email-masked]>
Sent: Thursday, March 28, 2019 2:01 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; 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]>
Cc: bcause <[email-masked]>
Subject: Re: Re: [bcause] to wait or not to wait

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]<mailto:[email-masked]>> On Behalf Of Chase, Chris
Sent: Wednesday, March 27, 2019 6:48 AM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>>;
> Mach Chen <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>;
> Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bcause

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 28 Mar 2019 07:29:44 -0400

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
 [email-masked]

---

From: Gregory Dalle <[email-masked]>
Date: Thu, 28 Mar 2019 14:47:14 +0000

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 <[email-masked]<mailto:[email-masked]>> 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
 [email-masked]<mailto:[email-masked]>

--
bcause mailing list
[email-masked]<mailto:[email-masked]>
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=

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Thu, 28 Mar 2019 16:03:03 +0000

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

-          Miao

发件人: bcause [mailto:[email-masked]] 代表 Gregory Dalle
发送时间: 2019年3月28日 22:47
收件人: Donald Eastlake <[email-masked]>
抄送: [email-masked]
主题: Re: [bcause] to wait or not to wait

Hi Donald,

Greg

Thanks,
Donald

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 28 Mar 2019 16:06:00 +0000

There are many more who did and voiced their opinion.

From: bcause <[email-masked]> on behalf of "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Thursday, 28 March 2019 at 17:03
To: Gregory Dalle <gdalle=[email-masked]>, Donald Eastlake <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [bcause] 答复: to wait or not to wait

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Thu, 28 Mar 2019 16:24:14 +0000

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

发件人: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]]
发送时间: 2019年3月29日 0:06
收件人: Miaofuyou (Miao Fuyou) <[email-masked]>; Gregory Dalle <gdalle=[email-masked]>; Donald Eastlake <[email-masked]>
抄送: [email-masked]
主题: Re: [bcause] 答复: to wait or not to wait

From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of "Miaofuyou (Miao Fuyou)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 28 March 2019 at 17:03
To: Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=[email-masked]>>, Donald Eastlake <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bcause] 答复: to wait or not to wait

-          Miao

发件人: bcause [mailto:[email-masked]] 代表 Gregory Dalle
发送时间: 2019年3月28日 22:47
收件人: Donald Eastlake <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [bcause] to wait or not to wait

Hi Donald,

Greg

Thanks,
Donald

---

From: Mach Chen <[email-masked]>
Date: Thu, 28 Mar 2019 16:59:27 +0000

Hi Greg and all,

To fully support BNG CUPS, no matter to define a new protocol or define extensions to existing protocol, it will not be a trivial work.  It’s true that PCPF has been implemented by several venders and deployed in production networks, but they are only limited to EPC. As one of the major mobile vendors, Huawei also has FPCP implementations, again they are only limited to mobile network. That means we understand the FPCP, it’s pros, cons.

And actually, I also analyzed PFCP protocol (TS 29.244). It’s a protocol with 200+ pages, this is just the basic protocol, there are other relevant application protocols (e.g., TS 23.214) . It is one of most complex protocols that I have read.

Suppose that if we continue to add more stuff to the protocol, it will become more and more complex. Do you really think such a super protocol is your need?  Normally, people think single protocol will be simple and thus more preferred. But if you have protocol design and implement experience, you will find that when a protocol is complex to a degrade, two simpler protocols may be a better choice.

An example is routing protocol, there are BGP, ISIS, OSPF, RFIT…. Why not we just use a single routing protocol to implement all routing functions. From an overall perspective, the major function of all the routing protocols is to learn routes and install the routes to forwarding table. Somehow, routing forwarding behavior should be more consistent among routing protocols than BNG and EPC/5GC.

In addition, looking though the PFCP specification website, during the past two year, the PFCP protocol has been iterated/updated more 20 versions.

I can list more…, but my point is that, sometime, single protocol is good, some is not. It depends on may factors. AFAIK, there is such an verification yet. BNG services and mobile services may look similar from some single aspect, but they have very big difference.

Best regards,
Mach

From: bcause [mailto:[email-masked]] On Behalf Of Gregory Dalle
Sent: Thursday, March 28, 2019 10:47 PM
To: Donald Eastlake <[email-masked]>
Cc: [email-masked]
Subject: Re: [bcause] to wait or not to wait

Hi Donald,

Greg

Thanks,
Donald

---

From: "De Smedt, Killian (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 Mar 2019 12:51:57 +0000

Hi Mach,

I have intensively worked with PFCP for almost two years now and do not agree with this statement. PFCP is no more complex than for example radius, diameter, BGP, or even the currently proposed CUSP protocol. Most arguments you mention such as page count, updates, and multiple documents are inherent to the 3GPP SDO process, and do not say anything about the protocol itself. Almost any 3GPP solution (whether it’s architectural, requirement or protocol) specification has a higher page count, is more frequently updated and is spread over multiple documents. If you would specify the CUSP proposal in 3GPP it would have very similar characteristics and it would not make it more or less complex than it is now.

In our experience, adding BNG capabilities comes down to adding new IEs, which is straightforward to do, without altering basic protocol behavior. Compare it to RADIUS, IETF has added over 250 AVPs since the original RFCs, but that has not made the protocol itself more complex, you only use the AVPs that are applicable to your usecase, the same applies to PFCP. The big advantage is that PFCP has solved many of the basic protocol requirements like forward compatibility, failure handling, scale, parallelization, session management, keepalives, ..., which can be re-used for BNG as-is.

Kind regards,

Killian

From: bcause [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, March 28, 2019 5:59 PM
To: Gregory Dalle <gdalle=[email-masked]>; Donald Eastlake <[email-masked]>
Cc: [email-masked]
Subject: Re: [bcause] to wait or not to wait

Hi Greg and all,

Best regards,
Mach

To: Donald Eastlake <[email-masked]<mailto:[email-masked]>>

Hi Donald,

Greg

Thanks,
Donald

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 Mar 2019 15:19:52 +0100

Hi Killian,
thank you for sharing your insights on PFCP. You've mentioned that PFCP
solved keepalives problem. That aspect of PFCP is of interest to me. What
is expected to be the rate of these keepalives? At IETF we've learned that
processing sub-second keepalives in the control plane is counterproductive
and it is better to use a BFD session because most of HW supports BFD
Asynchronous mode. And based on my experience I do have a concern regarding
this part of PFCP. Much appreciate if you can share your experience.

Regards,
Greg

On Fri, Mar 29, 2019 at 1:52 PM De Smedt, Killian (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> Hi Mach,
>
>
>
> I have intensively worked with PFCP for almost two years now and do not
> agree with this statement. PFCP is no more complex than for example radius,
> diameter, BGP, or even the currently proposed CUSP protocol. Most arguments
> you mention such as page count, updates, and multiple documents are
> inherent to the 3GPP SDO process, and do not say anything about the
> protocol itself. Almost any 3GPP solution (whether it’s architectural,
> requirement or protocol) specification has a higher page count, is more
> frequently updated and is spread over multiple documents. If you would
> specify the CUSP proposal in 3GPP it would have very similar
> characteristics and it would not make it more or less complex than it is
> now.
>
>
> In our experience, adding BNG capabilities comes down to adding new IEs,
> which is straightforward to do, without altering basic protocol behavior.
> Compare it to RADIUS, IETF has added over 250 AVPs since the original RFCs,
> but that has not made the protocol itself more complex, you only use the
> AVPs that are applicable to your usecase, the same applies to PFCP. The big
> advantage is that PFCP has solved many of the basic protocol requirements
> like forward compatibility, failure handling, scale, parallelization,
> session management, keepalives, ..., which can be re-used for BNG as-is.
>
>
>
> Kind regards,
>
>
>
> Killian
>
>
>
> *From:* bcause [mailto:[email-masked]] *On Behalf Of *Mach Chen
> *Sent:* Thursday, March 28, 2019 5:59 PM
> *To:* Gregory Dalle <gdalle=[email-masked]>; Donald
> Eastlake <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [bcause] to wait or not to wait
>
>
>
> Hi Greg and all,
>
>
>
> To fully support BNG CUPS, no matter to define a new protocol or define
> extensions to existing protocol, it will not be a trivial work.  It’s true
> that PCPF has been implemented by several venders and deployed in
> production networks, but they are only limited to EPC. As one of the major
> mobile vendors, Huawei also has FPCP implementations, again they are only
> limited to mobile network. That means we understand the FPCP, it’s pros,
> cons.
>
>
>
> And actually, I also analyzed PFCP protocol (TS 29.244). It’s a protocol
> with 200+ pages, this is just the basic protocol, there are other relevant
> application protocols (e.g., TS 23.214) . It is one of most complex
> protocols that I have read.
>
>
>
> Suppose that if we continue to add more stuff to the protocol, it will
> become more and more complex. Do you really think such a super protocol is
> your need?  Normally, people think single protocol will be simple and thus
> more preferred. But if you have protocol design and implement experience,
> you will find that when a protocol is complex to a degrade, two simpler
> protocols may be a better choice.
>
>
>
> An example is routing protocol, there are BGP, ISIS, OSPF, RFIT…. Why not
> we just use a single routing protocol to implement all routing functions.
> From an overall perspective, the major function of all the routing
> protocols is to learn routes and install the routes to forwarding table.
> Somehow, routing forwarding behavior should be more consistent among
> routing protocols than BNG and EPC/5GC.
>
>
>
> In addition, looking though the PFCP specification website, during the
> past two year, the PFCP protocol has been iterated/updated more 20
> versions.
>
>
>
> I can list more…, but my point is that, sometime, single protocol is good,
> some is not. It depends on may factors. AFAIK, there is such an
> verification yet. BNG services and mobile services may look similar from
> some single aspect, but they have very big difference.
>
>
>
>
>
>
>
> Best regards,
>
> Mach
>
>
>
>
>
> *From:* bcause [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Gregory Dalle
> *Sent:* Thursday, March 28, 2019 10:47 PM
> *To:* Donald Eastlake <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* 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.
>
> 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:
>
> On Mar 28, 2019, at 7:31 AM, Donald Eastlake <[email-masked]> wrote:
>
> [email-masked]
> [email-masked]