Re: [bcause] interest and scope?

[Greg Mirsky <[e-mail]>]

Hi Sanjay,
I think that you assume that the routing component is on the CP part of
CUPS. In the contribution from your colleague last week at BBF meeting, the
routing component was placed at UP. Hence, we have two scenarios, and each
poses different requirements. I think that it is too early to state that
PFCP can handle both.

Regards,
Greg

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

> Tim
>
>  Of course, extending PFCP involves work. Your perception is a bit
> misplaced on existing PCFP capabilities though. PFCP supports steering. It
> allows CP to specify steering policy if UP signals support for steering in
> its capabilities. The steering can actually be controlled not only on
> per-session basis, but also per-flow or application basis.
>
> PFCP has reliability mechanism built in that guarantees reliable delivery
> to the PFCP application on the peer (not just to the peer).
>
>
>
> It seems pre-mature to discuss protocol details before scope and
> requirements.
>
>
>
> -Sanjay
>
>
>
> *From:* Yu Tianpeng <[e-mail]>
> *Sent:* Friday, March 22, 2019 10:16 AM
> *To:* Wadhwa, Sanjay (Nokia - US/Mountain View) <[e-mail]>
> *Cc:* Miaofuyou (Miao Fuyou) <[e-mail]>; [e-mail]
> *Subject:* Re: [bcause] interest and scope?
>
>
>
> 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
>
> --
> bcause mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bcause
>