Re: [bcause] to wait or not to wait

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) <
killian.de_smedt@nokia.com> 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:bcause-bounces@ietf.org] *On Behalf Of *Mach Chen
> *Sent:* Thursday, March 28, 2019 5:59 PM
> *To:* Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org>; Donald
> Eastlake <d3e3e3@gmail.com>
> *Cc:* bcause@ietf.org
> *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:bcause-bounces@ietf.org <bcause-bounces@ietf.org>] *On
> Behalf Of *Gregory Dalle
> *Sent:* Thursday, March 28, 2019 10:47 PM
> *To:* Donald Eastlake <d3e3e3@gmail.com>
> *Cc:* bcause@ietf.org
> *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.
>
> 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> 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
>
>
>
> --
> bcause mailing list
> 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=
>
> --
> bcause mailing list
> bcause@ietf.org
> https://www.ietf.org/mailman/listinfo/bcause
>