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

[Greg Mirsky <[e-mail]>]

Hi Andrew,
I'm talking about an abstract new CUPS protocol for FN-DBNG. The CUSP is
designed with consideration of input from several operators and their
operational processes. I've reviewed all drafts, draft-cusp-* and
draft-wadhwa-*, and believe that these are a very good foundation for the
WG. And I would be available to review, comment and work with authors to
progress this work at IETF.

Regards,
Greg

On Tue, Mar 26, 2019 at 1:36 AM Dolganow, Andrew (Nokia - SG/Singapore) <
[e-mail]> wrote:

> Greg,
>
> Can you please help me understand your point? It seems you arguing against
> introduction of one protocol (existing with extensions for new
> functionality) by suggesting we should adopt brand new protocol yet to be
> invented? Seems to me contradictory?
>
> Regards,
> Andrew
> Sent from my iPhone Outlook <https://aka.ms/qtex0l>
>
> ------------------------------
> *From:* bcause <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Sent:* Tuesday, March 26, 2019 3:43 AM
> *To:* Gregory Dalle ([e-mail])
> *Cc:* [e-mail]; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> *Subject:* Re: [bcause] [Bcause] interest and scope?
>
> 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=>
>>
>>