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

"Aijun Wang@China Telecom" <wangaj.bri@chinatelecom.cn> Mon, 25 March 2019 19:56 UTC

Return-Path: <wangaj.bri@chinatelecom.cn>
X-Original-To: bcause@ietfa.amsl.com
Delivered-To: bcause@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC047120077 for <bcause@ietfa.amsl.com>; Mon, 25 Mar 2019 12:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goZhRz0W0M_1 for <bcause@ietfa.amsl.com>; Mon, 25 Mar 2019 12:56:00 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DB120044 for <bcause@ietf.org>; Mon, 25 Mar 2019 12:56:00 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.80:32999.895666692
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-79.98.72.220 (unknown [172.18.0.80]) by chinatelecom.cn (HERMES) with SMTP id 93CF628008C; Tue, 26 Mar 2019 03:55:46 +0800 (CST)
X-189-SAVE-TO-SEND: wangaj.bri@chinatelecom.cn
Received: from EHLO ip<79.98.72.220> ([172.18.0.80]) by App0022 with ESMTP id b2b099d6-a381-4ef0-a595-98cdcaca7b85 for gdalle=40juniper.net@dmarc.ietf.org; Tue Mar 26 03:55:53 2019
X-filter-score: filter<0>
X-Real-From: wangaj.bri@chinatelecom.cn
X-Receive-IP: 172.18.0.80
X-MEDUSA-Status: 0
Content-Type: multipart/alternative; boundary="Apple-Mail-0127B6F0-D2B0-496C-B623-B96D87758789"
Mime-Version: 1.0 (1.0)
From: "Aijun Wang@China Telecom" <wangaj.bri@chinatelecom.cn>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <MWHPR05MB3360D79E90DD1E04E4EB418AD35E0@MWHPR05MB3360.namprd05.prod.outlook.com>
Date: Mon, 25 Mar 2019 20:55:35 +0100
Cc: Greg Mirsky <gregimirsky@gmail.com>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, "bcause@ietf.org" <bcause@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <09BCFDCE-6A61-4897-935D-309CC507094C@chinatelecom.cn>
References: <4c42b485-0798-50c4-b62e-501dff12c914@nokia.com> <CA+RyBmWp8HuDt31o_gtBELaE5=D06Yqe1zxpdigjORJDfwa8=Q@mail.gmail.com> <MWHPR05MB3360D79E90DD1E04E4EB418AD35E0@MWHPR05MB3360.namprd05.prod.outlook.com>
To: Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/adNgjP-WHJzF6OJ8insPy9MMbPo>
Subject: Re: [bcause] [Bcause] interest and scope?
X-BeenThere: bcause@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <bcause.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bcause>, <mailto:bcause-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bcause/>
List-Post: <mailto:bcause@ietf.org>
List-Help: <mailto:bcause-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bcause>, <mailto:bcause-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 19:56:03 -0000

Hi, Gregory:

Can the FMC vision described now in BBF accomplish the following aims:
1. Converge in the control plan for mobile and broadband subscribers for sessions negotiations/management etc. functions?
2. Can the BNG existing in the network be upgraded to support the UPF function with minimum costs(for example, control software upgrades)?

Control Plane in Mobile Network is more complex than the counterpart of broadband network, but BNG has more powerful forwarding capabilities than UPF.  If the converge consider more how to utilize the advantages of each side, not just defining additional function entities(AGF etc.), I think the solutions will be easily rolled out in real network.

Aijun Wang
China Telecom

> On Mar 25, 2019, at 20:23, Gregory Dalle <gdalle=40juniper.net@dmarc.ietf.org> 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:
> 2 operators said they are interested only in fixed access BNG
> 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 <bcause-bounces@ietf.org> On Behalf Of Greg Mirsky
> Sent: Monday, March 25, 2019 9:20 AM
> To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <martin.vigoureux@nokia.com>
> Cc: bcause@ietf.org
> 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) <martin.vigoureux@nokia.com> 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/ 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://datatracker.ietf.org/liaison/1615/
> https://datatracker.ietf.org/liaison/1600/
> https://datatracker.ietf.org/liaison/1566/
> 
> 
> ---
> 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
> Bcause@ietf.org
> https://www.ietf.org/mailman/listinfo/bcause
> -- 
> bcause mailing list
> bcause@ietf.org
> https://www.ietf.org/mailman/listinfo/bcause