Re: [bcause] [Bcause] interest and scope?

[Greg Mirsky <[e-mail]>]

Hi Greg D.,
thank you for consideration. The situation for the FN-only operators, as I
understand it, is complicated by the insistence that only PFCP-based
solution to CUPS will likely be standardized. As I have explained,  for
operator that has it's fixed and mobile networks operated separately
introduction of the new protocol, PFCP in this case, will result in the
increased OPEX. I would consider that as no-starer offer from any vendor.

Regards,
Greg M

On Mon, Mar 25, 2019, 20:23 Gregory Dalle <[e-mail]> wrote:

> Hi Greg M,
>
>
>
> Commenting back on: “we have heard from several operators that they are
> interested only in FN (fixed network) DBNG CUPS (….) I don't think that
> requests by these operators should be ignored”.
>
>
>
> From what I can track on this mailing list:
>
>    1. 2 operators said they are interested only in fixed access BNG
>    2. 5 operators said they don’t want to restrict the protocol
>    discussion to fixed access only
>
>
>
> The good news is that these 2 operators are not ignored, as the goal is
>  provide a superset that includes support for basic TR178 BNG as they want.
>
>
>
> Thanks,
>
> Greg D
>
>
>
> *From:* bcause <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* Monday, March 25, 2019 9:20 AM
> *To:* Vigoureux, Martin (Nokia - FR/Paris-Saclay) <
> [e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [bcause] [Bcause] interest and scope?
>
>
>
> Hi Martin, et al.,
>
> I'd not discuss whether PFCP can be extended to suit yet undocumented DBNG
> CUPS requirements without changes to its architecture. Many stated that
> they believe that that is achievable and I'm not to argue with what people
> believe or don't believe in. I just want to point out that we have heard
> from several operators that they are interested only in FN (fixed network)
> DBNG CUPS. I interpret that these operators have and want to keep their
> fixed and mobile networks operated separately. And even though PFCP may be
> already is familiar to the operations team that manages their mobile
> network, introducing the new protocol into the operation of the fixed
> network will increase their operational cost. More so, operators that are
> not looking to introduce hybrid access or 5G FMC at any time soon may have
> a preference on which protocol selection as that is the reflection of their
> operational model. I don't think that requests by these operators should be
> ignored and the answer given by SDOs include only PFCP-based DBNG CUPS.
>
> I've participated in the discussion and contributed to the charter. The
> charter intended to work on FN-only DBNG CUPS first and deliver results
> quickly. Adding hybrid access and 5G FMC could be discussed later,
> including, based on findings by experts at BBF.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Mar 4, 2019 at 2:22 PM Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[e-mail]> wrote:
>
> Hello,
>
> as you might know, the RTGWG has hosted, for some time now, a set of
> documents that relate to the separation of the user plane and control
> plane of Broadband Network Gateways.
> These documents can be found at
> https://datatracker.ietf.org/group/rtgwg/documents/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_group_rtgwg_documents_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=S-4EDvyPmus0NS5LXfp-Ms9zGC_m8iVOllO5lcwmVo0&s=96SauSW0hDod15fcQ8L7ylDy5HchcDuklDH6996dPic&e=>
> and start with
> draft-cuspdt-* or draft-wadhwa-*
>
> Please read them if you haven't already.
>
> Recently, a group of persons has worked together and produced few
> paragraphs in support of their willingness to see a working group on
> this topic formed.
>
> Considering this, I am sharing this text with the IETF community in
> order to evaluate
> * the wider interest in, and willingness to work on, this topic,
> * the appropriateness of creating a focussed and short-lived working
> group (as opposed to continuing in rtgwg).
> To that effect, please read and comment on the text further down, it is
> here for being debated.
> As a matter of clarification: me sharing it, instead of the authors
> doing it, does not carry any special meaning.
>
> Important note: this topic has its roots in BroadBand Forum (BBF) with
> which IETF has exchanged few liaisons on the topic recently. These are
> important reads:
> https://datatracker.ietf.org/liaison/1619/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_liaison_1619_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=S-4EDvyPmus0NS5LXfp-Ms9zGC_m8iVOllO5lcwmVo0&s=WR5EeaTa7vVKvnvgUSwSif_tFMJATrrdUp85D9Wauww&e=>
> https://datatracker.ietf.org/liaison/1615/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_liaison_1615_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=S-4EDvyPmus0NS5LXfp-Ms9zGC_m8iVOllO5lcwmVo0&s=0siKbwwdh2W6FBBMHKJid3k-SaVYNP1bfqYkVAZMWWU&e=>
> https://datatracker.ietf.org/liaison/1600/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_liaison_1600_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=S-4EDvyPmus0NS5LXfp-Ms9zGC_m8iVOllO5lcwmVo0&s=ntY5jLiyuv6zQcLI7sHo0U-_oSajcmPcqdSQViQ7FAY&e=>
> https://datatracker.ietf.org/liaison/1566/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_liaison_1566_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=S-4EDvyPmus0NS5LXfp-Ms9zGC_m8iVOllO5lcwmVo0&s=8AnBB1mLQepiil0dgmBKNL1NDtxWktzl2IOEZ9XXNyI&e=>
>
>
> ---
> Current Broadband Network Gateways (BNGs) that terminate residential
> broadband subscribers at the edge of service provider networks run as an
> integrated system where both the subscriber management control plane and
> traffic forwarding user plane are combined in a single system. In a
> large network, where the subscriber density is high, it is better to
> distribute and locate BNG systems closer to the subscribers, especially
> when the content caches are distributed to reduce backhaul costs and
> latency. In this scenario, as the BNG footprint grows, the subscriber
> management control points also proliferate, increasing operational
> complexity. This trend motivates the broadband network access industry
> to adopt new architectures that take advantage of the increasing ability
> to disaggregate and virtualize appropriate network access functions.
> Additional benefits can be realized by separating subscriber management
> control plane (CP) and traffic forwarding user plane (UP) for BNGs
> (referred to as Control and User Plane Separation (CUPS)). That
> simplifies operations, provides independent location, and scaling for CP
> and UP functions. A single CP function, running as a centralized VNF,
> can control and manage multiple UP instances, which may be distributed
> and separated from the CP via a multi-hop L2 or L3 network.  CUPS
> requires protocols for communication between CP and UP instances: from
> the CP to the UP to create and manage subscriber state instances and
> from the UP to the CP to handle relevant solicited or unsolicited events.
>
> The proposed Working Group is a narrowly scoped WG tasked to specify
> communication protocol(s) between the CP and UP of a BNG, a network
> element whose functions are defined by BBF. A BNG can deliver broadband
> services to subscriber over wireline access or over multiple access
> types to accommodate different deployments. The goal of the WG is to
> define protocol(s) for CUPS that may support multiple deployment
> scenarios for the BNG.
>
> The scope of the work covers protocol requirements, specification of the
> communications protocol, the information elements to be transferred with
> that protocol, and YANG data model(s) for Operations and Management as
> well as security, operational, and transport considerations.
> ---
>
>
> Thank you
> Martin
> --
> Bcause mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bcause
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=S-4EDvyPmus0NS5LXfp-Ms9zGC_m8iVOllO5lcwmVo0&s=H-G297qDrFOH-JKFv25D8NyN-fqntWahhcvLjzO-LWM&e=>
>
>