Re: [bcause] interest and scope?

[Yu Tianpeng <[e-mail]>]

Hi Sanjay,
I had a read on PFCP, I am glad that I find there are some points inside
matching with my thoughts (e.g. the concept of PDR, PDI, FAR).
I wrote sth before reading PFCP
(draft-cups-rtgwg-cu-separation-requirement), with some similar ideas
inside (GSF).
But I also realize that there is pretty much work to do even we re-use the
current PFCP. There are a couple of points:
1. Current PFCP lacks considerations of many scenarios: e.g. 3-play,
service chaining (e.g. NAT, DPI, both intra-chassis and inter-chassis
chaining), network programming (e.g. segment routing)
2. Current PFCP design philosophy is “OpenFlow” like which makes co-working
with existing technologies listed above difficult
The challenge of CUPS protocol I believe is the service model between CP
and UP. But what PFCP has done so far is a very basic model (basic IP
forwarding with QoS parameters and some monitoring, there is no concept of
service inside even), but many functions not needed in BNG CUPS.
I have concerns on if PFCP is the right way if we consider co-working with
the technologies going on in IETF.
I also have a concern that PFCP chooses UDP as the transport protocol,
which lacks of congestion control and different from control protocols we
see usually. And in order to guarantee reliability, extra complexity has to
be introduced to PFCP protocol itself and its application.
Glad to hear your options on these.
Thanks in advance.
Regards,
Tim

On Fri, 22 Mar 2019, 15:40 Wadhwa, Sanjay (Nokia - US/Mountain View), <
[e-mail]> wrote:

> Miao
>  We have gone well beyond Wikipedia and analyzed  PFCP in detail. It has
> the right constructs to convey forwarding, traffic-management, and usage
> related state between CP and UP as required by a fully featured BNG for
> both fixed and fixed-wireless access. It is very extensible with the
> encodings defined for IEs and grouped IEs conveyed in PFCP objects. The
> natural order of addressing a problem space is to start with requirements
> and architecture, which is what we did with our drafts. That said, we have
> scoped the PFCP extensions for multiple functions in BNG, including
> dual-stack IPoE, PPPoE, L2TP LAC, H-QOS, LI, NAT. Lot of this is
> incremental.
> We have a draft on applicability of PFCP to BNG that can terminate
> multiple access and transport encapsulations. It details relevant PFCP
> extensions and is waiting to be submitted. We are just following the right
> order. Requirements and architecture framework first, before bringing in
> protocol work that maps to the architecture and requirements.
>
> -Sanjay
>
>
> -----Original Message-----
> From: bcause <[e-mail]> On Behalf Of Miaofuyou (Miao Fuyou)
> Sent: Friday, March 22, 2019 2:34 AM
> To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[e-mail]>;
> [e-mail]
> Subject: [bcause] 答复: interest and scope?
>
> Hi Sanjay,
>
> Wikipedia says: "PFCP's scope is similar to that of OpenFlow, however it
> was engineered to serve the particular use-case of Mobile Core Networks.
> PFCP lacks the same general-purpose targets, describing well the
> 3GPP-specific functional basic blocks of packet forwarding used in 2G, 3G,
> 4G/LTE, Non-3GPP WiFi and 5G networks."
>
> https://en.wikipedia.org/wiki/PFCP
>
> Even so, it doesn't mean PFCP could not to be extended or changed to do
> more. However, there have to be an thorough analysis to PFCP to figure out
> what extension or change is needed. Otherwise, it's only intention
> expression rather than facts statement, which is not helpful to progress
> the work.
>
> - Miao
>
> -----邮件原件-----
> 发件人: bcause [mailto:[e-mail]] 代表 Wadhwa, Sanjay (Nokia -
> US/Mountain View)
> 发送时间: 2019年3月21日 23:39
> 收件人: [e-mail]
> 主题: Re: [bcause] interest and scope?
>
> Hi
> >From most of the posts, it is quite clear convergence is an important
> consideration.
> To be specific, with the right interfaces and functions on BNG, one can
> use current BNG deployed base to offer existing residential services over
> any of fixed-access, fixed-wireless (e.g. with LTE, LTE/CBRS, 5G NSA) or
> hybrid-access. Additionally, as mentioned in another post there is ongoing
> work for integrating fixed-access with 5GC via an adaptation function (AGF)
> to use a multi-access SMF/UPF.
> Using a particular option at a given time may be a decision based on ROI,
> state of the network or other constraints. However, going from one access
> to another on BNGs or 5GC SMF/UPF should not require a new baseline CUPS
> protocol, but rather extensions to a common protocol. The extensions mainly
> confine to the state information carried by the protocol based on
> access-facing and network-facing interface encapsulations on the
> network-element. Network elements can include BNG, AGF, SGW/PGW, TDF, 5GC
> SMF/UPF. Some of the functions provided by these network elements may be
> combined or instantiated on the same platform.
> Therefore, an access or use-case specific CUPS protocol is a dead-end. A
> common CUPS protocol that enables convergence will provide flexibility to
> evolve the network without worrying about yet another variable. Extending
> an existing standard protocol that is already purpose built for large scale
> state exchange is a sound way forward for BNG CUPS. With above in mind, we
> have considered PFCP applicability for BNG CUPS (irrespective of access)
> for some time now, including required PFCP IEs. Existing IETF drafts have
> covered BNG CUPS architecture and requirements that are addressed by PFCP.
>
> Thanks
> -Sanjay
>
> --
> bcause mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bcause
> --
> bcause mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bcause
> --
> bcause mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bcause
>