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

["Joel M. Halpern" <[e-mail]>]

Even if one asumes we need a new protocol, I do not see how that can 
take less time in terms of having clear requirements, much less a fair 
and thorough analysis with public review.

Personally, even if PFCP were not suitable, I would want to see a strong 
analysis why all the other existing protocols for this problem were not 
suitable.
Given the overlap and existing work, as far as I can tell using PFCP is 
most time-effective path.  And given that the BBF is doing this, I do 
not see why the IETF should stick our oar in.  We are not magically 
faster than other SDOs.  We are not better informed about BNGs than the 
BBF.  We try not to create protocols for narrow use cases.

Yours,
Joel

On 3/26/19 10:46 AM, Miaofuyou (Miao Fuyou) wrote:
> Hi Wim,
> 
> WH> PFCP will need to be extended anyhow for AGF, etc use case in BBF 
> and also 3GPP decided to have L2 PDU,
> 
> My understanding is there is no such decision made yet in BBF, although 
> someone expressed preference. Dave could correct me if I am wrong. Not 
> sure about 3GPP, I guess liaison (slow in nature again) is the only way 
> to verify it.
> 
> WH> We already checked with our 3GPP people and the protocol can be 
> extendable easily based on codepoint assignment
> 
> I mean liaison process takes time. Besides that, without a thorough 
> analysis with public review I don't  believe simple extension and code 
> point assignment will meet BNG requirement .
> *发件人：*Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>
> *收件人：*Miaofuyou (Miao Fuyou) 
> <[e-mail]>;eduard.metz=[e-mail] 
> <eduard.metz=[e-mail]>;[e-mail] 
> <[e-mail]>;[e-mail] <[e-mail]>
> *抄 送：*[e-mail] <[e-mail]>;Vigoureux, Martin (Nokia - 
> FR/Paris-Saclay) <[e-mail]>
> *时间：*2019-03-26 10:23:21
> *主 题：*Re: [bcause] [Bcause] interest and scope?
> 
> To shime in here
> 
> *From: *bcause <[e-mail]> on behalf of "Miaofuyou (Miao 
> Fuyou)" <[e-mail]>
> *Date: *Tuesday, 26 March 2019 at 10:14
> *To: *"eduard.metz=[e-mail]" 
> <eduard.metz=[e-mail]>, "[e-mail]" 
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "Vigoureux, Martin (Nokia - 
> FR/Paris-Saclay)" <[e-mail]>
> *Subject: *Re: [bcause] [Bcause] interest and scope?
> 
> It really dpends on how much of PFCP could be reused. There are 
> fundemental differences between mobile use case and BNG. For example, 
> layer 2 (pppoe) vs. layer 3 (GTP) access, reliability model, accounting 
> model. There should be thorough analysis, which is not available yet.
> 
> WH> PFCP will need to be extended anyhow for AGF, etc use case in BBF 
> and also 3GPP decided to have L2 PDU, so these extension are already on 
> the table. All the packet rules/qos rules and charging can be reused. On 
> top the protocol is hardened in 3GPP networks today and scale well 
> beyond what is needed in the fixed world. We benefit from all this work 
> and serve the industry a service rather than trying to reinventing 
> something new and only serve 1 use case.
> 
> My prediction is, even it can be done with PFCP, it will take long time 
> to get the spec out. Besides technical problems to solve, spec 
> definition with PFCP has to depend on liaison (slow in nature) between 
> IETF and 3GPP, to get work really done finally in 3GPP. 3GPP is 
> currently focusing on 5G spec, I suspect it be willing/able to do it 
> with extra bandwidth.
> 
> WH> We already checked with our 3GPP people and the protocol can be 
> extendable easily based on codepoint assignment.
> 
> *发**件人：*eduard.metz=[e-mail] 
> <eduard.metz=[e-mail]>
> 
> *收件人：*[e-mail] 
> <[e-mail]>;[e-mail] <[e-mail]>
> 
> *抄** **送：*[e-mail] 
> <[e-mail]>;[e-mail] <[e-mail]>
> 
> *时间**：*2019-03-26 09:47:34
> 
> *主** **题**：*Re: [bcause] [Bcause] interest and scope?
> 
> Not sure I understand this, would in this case introducing PCFP for CUPS 
> (FN only) be more expensive than introducing a new protocol for CUPS (FN 
> only)?
> 
> cheers,
> 
>                 Eduard
> 
> *From:* bcause <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* maandag 25 maart 2019 20:43
> *To:* Gregory Dalle ([e-mail]) <[e-mail]>
> *Cc:* [e-mail]; Martin Vigoureux <[e-mail]>
> *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] 
> <mailto:[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]
>     <mailto:[e-mail]>> *On Behalf Of *Greg Mirsky
>     *Sent:* Monday, March 25, 2019 9:20 AM
>     *To:* Vigoureux, Martin (Nokia - FR/Paris-Saclay)
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[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]
>     <mailto:[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] <mailto:[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=>
> 
>