[bcause] 答复: [Bcause] interest and scope?

["qinfengwei" <[e-mail]>]

Hi,
	We have updated the S-CUSP protocol draft and the architecture
draft.
 S-CUSP protocol draft:
                   Major revision of the draft to bring it closer to the
deployed implementations
 
https://tools.ietf.org/html/draft-cuspdt-rtgwg-cu-separation-bng-protocol-04
Architecture draft: 
				  Editorial improvements and the addition of
some Security Considerations material
 
https://tools.ietf.org/html/draft-cuspdt-rtgwg-cu-separation-bng-architectur
e-04

Any comments are welcomed.

Thanks
Fengwei Qin
[e-mail]



-----邮件原件-----
发件人: bcause [mailto:[e-mail]] 代表 Donald Eastlake
发送时间: 2019年3月14日 12:34
收件人: [e-mail]     
主题: Re: [bcause] [Bcause] interest and scope?

Hi,

On Mon, Mar 4, 2019 at 8:22 AM Vigoureux, Martin (Nokia -
FR/Paris-Saclay) <[e-mail]> wrote:
> ...
>
> * the wider interest in, and willingness to work on, this topic,

I am interested and willing to work on it.

> * the appropriateness of creating a focussed and short-lived working
> group (as opposed to continuing in rtgwg).

Work could be continued in the rtgwg but I'm inclined to think that a
narrowly focused WG would be faster.

> 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:
> ...
An additional liaison has been received from the BBF:
https://datatracker.ietf.org/liaison/1631/

I think the Charter below is simple and to the point but there seems
to be some confusion about what "protocol" means. It usually includes
messages and some way of communicating them.  "way of communicating
them" does not necessarily imply anything more than a few words (like
what port number to use or the equivalent plus a bit more) about how
to use some existing way of communicating the messages. People seem to
think that "new protocol" necessarily means the specification of some
large intricate method of communicating messages. But I think
something is just as much a "new protocol" if it specifies a set of
messages and a few parameters that say how to send those messages over
an existing communications method.

In normal IETF usage, "protocol" encompases all of these. BFD is an
IETF protocol even though RFC 5880 says very little about how to
envelope or transport BFD messages. UDP and TCP are protocols even
though they impose very few constraints on the messages that are
communicated with them. SNMP is a protocol whose specification
includes both the messages and how to communicate them. So, using the
broad IETF meaning of "protocol", I don't see any problem with its use
in the Charter...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]

> ---
> 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