Subject: [Bcause] interest and scope?

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 4 Mar 2019 13:22:01 +0000

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

---

From: "qinfengwei" <[email-masked]>
Date: Mon, 4 Mar 2019 22:06:24 +0800

Hi Martin and all,

I'm Fengwei Qin from China Mobile and hope to setup working group on CUPS. 
BNG with control and user plane separation is about to enter the commercial
stage in China Mobile, 
it is urgent and significant to research on protocols for CUPS in
fixed-network.

Thanks & BR
Fengwei Qin 
[email-masked]

-----邮件原件-----
发件人: Bcause [mailto:[email-masked]] 代表 Vigoureux, Martin
(Nokia - FR/Paris-Saclay)
发送时间: 2019年3月4日 21:22
收件人: [email-masked]
主题: [Bcause] interest and scope?

Hello,

---

Thank you
Martin
-- 
Bcause mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bcause

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Mar 2019 10:01:33 -0500

Two aspects of the text you circulated below cause me concern.

First, the text assumes that there needs to be a new protocol for 
separating the control and user plane of a BNG.  Given the large number 
of existing protocols (some of the even IETF Proposed Standard RFCs) it 
would seem that the first issue is to demonstrate that we need a new 
protocol.  Such a demonstration would seem to need the requirements, 
which are under development in other places.

Second, if there are clear requirements, and assuming that there is a 
conclusion that a new protocol is needed, I would think we would want to 
be careful and design any such new protocol for a broader case than just 
a BNG.  By assumption, BNGs have specific requirements that need to be 
met.   But a protocol designed just for a BNG seems rather limiting.

Yours,
Joel M. Halpern

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Mon, 4 Mar 2019 16:07:11 +0000

Joel,

You raise valid concerns and we need to make sure that work we complete at the IETF is widely deployable, solid technically, extensible, and does not reinvent the wheel. Jumping to protocol detailed discussions before we even have a WG with a clear charter, clear use cases, clear requirements is premature in my opinion.

I am looking forward to great discussion on this. The work/topic is definitely worth taking upon but we need to ensure proper technical design/quality. I assume the desire here is a standard(s) for widely-deployable solution meeting robust set of requirements /use cases and not something else that could be handled as an informational draft on how someone implemented something for an operator.

Kind regards,
Andrew

On 2019-03-04, 11:01 PM, "bcause on behalf of Joel M. Halpern" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel M. Halpern

--
bcause mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bcause

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 4 Mar 2019 08:30:05 -0800

Hi Martin,
thank you for your help to organize the discussion right after the first
presentation of BNG CUPS in Bangkok. I'm interested in and committed to
working on the requirements, the architecture for CUPS protocol(s) (it does
appear that we'll need not one but several protocols to address all the
CUPS requirements). As Joel pointed out, once we iron the list of
requirements, the known protocols should be examined, possible gaps
identified and evaluated. And we'll develop a protocol stacks to deliver
deployable solutions that address the operator's use cases.
Looking forward to the discussion in Prague.

Regards,
Greg

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 4 Mar 2019 14:45:57 -0500

Hi Joel,

> which are under development in other places.

One question is what is meant by "new protocol"? It could range from
specifying some new data elements and messages to re-inventing
Ethernet. Clearly some additional specification work is needed or the
problem would already be solved.

> met.   But a protocol designed just for a BNG seems rather limiting.

I think the IETF believes in rough consensus and running code. What
you are talking about sounds like the waterfall model where you spend
a long time polishing requirements and then a long time polishing
design and maybe then you start to write some code...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

> [email-masked]

---

From: Mach Chen <[email-masked]>
Date: Tue, 5 Mar 2019 03:00:43 +0000

Hi Martin,

Thanks for kicking off this discussion! 

Yes, I am interested in and will work on this topic. I'd like to see a focused and short-lived working group for this work, which is better for concentrating efforts to accelerate related work.

Best regards,
Mach

> -----Original Message-----
> From: Bcause [mailto:[email-masked]] On Behalf Of Vigoureux,
> Martin (Nokia - FR/Paris-Saclay)
> Sent: Monday, March 04, 2019 9:22 PM
> To: [email-masked]
> Subject: [Bcause] interest and scope?
> 
> Hello,
> 
> documents that relate to the separation of the user plane and control plane
> of Broadband Network Gateways.
> 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 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:
> 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.
> 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.
> 
> 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.
>

---

From: "Miziewicz, Krystof (Nokia - AU/Sydney)" <[email-masked]>
Date: Tue, 5 Mar 2019 03:42:14 +0000

Hi Martin,

Thanks for kicking it off.
Yes, I'm interested in the disaggregated BNG architecture and would like to participate in activities of the new working group.
I will attend the BNG Control-plane and User-plane Separation session in Prague.

Regards
Krystof Miziewicz

-----Original Message-----
From: Bcause <[email-masked]> On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Tuesday, March 5, 2019 12:22 AM
To: [email-masked]
Subject: [Bcause] interest and scope?

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

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:

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

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 5 Mar 2019 06:42:20 +0000

Martin
  Thanks for kicking off this discussion. A dedicated WG is a good idea. From what you have included below, it is evident that IETF has had some coordination with BBF, which makes sense.
BNGs deployed in broadband networks today follow and comply with BBF specs (TRs/WTs) that have defined architectural and functional requirements related to BNG. This compliance is invariably mandated in RFPs from carriers.
It is worthwhile to coordinate with BBF and leverage their ongoing work on requirements for CP/UP separation of a disaggregated BNG. This will help avoid duplication and ultimately speed up actual protocol work in IETF.

-Sanjay

-----Original Message-----
From: Bcause <[email-masked]> On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Monday, March 4, 2019 5:22 AM
To: [email-masked]
Subject: [Bcause] interest and scope?

Hello,

---

Thank you
Martin
--
Bcause mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bcause

---

From: Georgios Karagiannis <[email-masked]>
Date: Tue, 5 Mar 2019 08:34:18 +0000

Hi Martin,

Thanks for starting this mailing list. 
I hope that we can start a narrowed scope WG asap in order to deliver the first specification outputs in 6 to 12 months after the WG is initiated.
This is because, from what I know, the demand side (operators/service providers) would like to deploy BNG CP - UP scenarios on a large scale as soon as possible.

Please note that I am supporting and I will participate in the standardization activities of this new WG to help the demand side to deploy their BNG CP-UP scenarios on a large scale.

Best regards,
Georgios

-----Original Message-----
From: Bcause [mailto:[email-masked]] On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Monday, March 04, 2019 2:22 PM
To: [email-masked]
Subject: [Bcause] interest and scope?

Hello,

---

Thank you
Martin

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 14 Mar 2019 00:34:29 -0400

Hi,

On Mon, Mar 4, 2019 at 8:22 AM Vigoureux, Martin (Nokia -
FR/Paris-Saclay) <[email-masked]> wrote:
> ...

I am interested and willing to work on it.

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

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

---

From: "qinfengwei" <[email-masked]>
Date: Thu, 14 Mar 2019 21:35:07 +0800

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

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

Hi,

Thanks,
Donald

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 18 Mar 2019 11:27:47 +0000

We have uploaded the latest versions of architecture and protocol requirements drafts to resolve some comments on previous versions.

draft-wadhwa-rtgwg-bng-cups-03.txt<https://datatracker.ietf.org/doc/draft-wadhwa-rtgwg-bng-cups/>. Included section on resiliency. Minor updates in sections 3.2.1 and 3.3.
draft-wadhwa-rtgwg-bng-cups-protocol-requirements-02.txt<https://datatracker.ietf.org/doc/draft-wadhwa-rtgwg-bng-cups-protocol-requirements/>. Updated section 5 (local management interface).

-Sanjay

-----Original Message-----
From: Bcause <[email-masked]> On Behalf Of Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Sent: Monday, March 4, 2019 5:22 AM
To: [email-masked]
Subject: [Bcause] interest and scope?

Hello,

---

Thank you
Martin

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 21 Mar 2019 15:39:24 +0000

Hi
>From most of the posts, it is quite clear convergence is an important consideration.
To be specific, with the right interfaces and functions on BNG, one can use current BNG deployed base to offer existing residential services over any of fixed-access, fixed-wireless (e.g. with LTE, LTE/CBRS, 5G NSA) or hybrid-access. Additionally, as mentioned in another post there is ongoing work for integrating fixed-access with 5GC via an adaptation function (AGF) to use a multi-access SMF/UPF. 
Using a particular option at a given time may be a decision based on ROI, state of the network or other constraints. However, going from one access to another on BNGs or 5GC SMF/UPF should not require a new baseline CUPS protocol, but rather extensions to a common protocol. The extensions mainly confine to the state information carried by the protocol based on access-facing and network-facing interface encapsulations on the network-element. Network elements can include BNG, AGF, SGW/PGW, TDF, 5GC SMF/UPF. Some of the functions provided by these network elements may be combined or instantiated on the same platform. 
Therefore, an access or use-case specific CUPS protocol is a dead-end. A common CUPS protocol that enables convergence will provide flexibility to evolve the network without worrying about yet another variable. Extending an existing standard protocol that is already purpose built for large scale state exchange is a sound way forward for BNG CUPS. With above in mind, we have considered PFCP applicability for BNG CUPS (irrespective of access) for some time now, including required PFCP IEs. Existing IETF drafts have covered BNG CUPS architecture and requirements that are addressed by PFCP. 

Thanks
-Sanjay

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Fri, 22 Mar 2019 09:33:42 +0000

Hi Sanjay,

Wikipedia says: "PFCP's scope is similar to that of OpenFlow, however it was engineered to serve the particular use-case of Mobile Core Networks. PFCP lacks the same general-purpose targets, describing well the 3GPP-specific functional basic blocks of packet forwarding used in 2G, 3G, 4G/LTE, Non-3GPP WiFi and 5G networks." 

https://en.wikipedia.org/wiki/PFCP

Even so, it doesn't mean PFCP could not to be extended or changed to do more. However, there have to be an thorough analysis to PFCP to figure out what extension or change is needed. Otherwise, it's only intention expression rather than facts statement, which is not helpful to progress the work.

- Miao

-----邮件原件-----
发件人: bcause [mailto:[email-masked]] 代表 Wadhwa, Sanjay (Nokia - US/Mountain View)
发送时间: 2019年3月21日 23:39
收件人: [email-masked]
主题: Re: [bcause] interest and scope?

Hi

Thanks
-Sanjay

---

From: Gregory Dalle <[email-masked]>
Date: Fri, 22 Mar 2019 15:28:22 +0000

Hi Miao,

You are right about the need to analyze gaps in PFCP to support wireline access. BNG experts have started this analysis at BBF and we hope to hear back soon.

Thanks for sharing the Wikipedia article. So PFCP supports 4G, 5G and non-3GPP (wifi)? That’s quite a broad range of broadband scenarios. Doesn’t it make you confident that wireline can be added to the list?

Greg

> On Mar 22, 2019, at 5:34 AM, Miaofuyou (Miao Fuyou) <[email-masked]> wrote:
> 
> Hi Sanjay,
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_PFCP&d=DwIGoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=gOeAY5qlTZQYncH2IgwljFZF9fv348WkEwyxOr9dtm4&s=v33MW1QfVNSlFntCd34LCmRjivIDxqexEzoS7I2lpNo&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwIGoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=gOeAY5qlTZQYncH2IgwljFZF9fv348WkEwyxOr9dtm4&s=4-NoEEHrIaJhrv1W6ZcntpGAspFt-yPgcVI53rwnsNM&e=
> -- 
> bcause mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwIGoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=gOeAY5qlTZQYncH2IgwljFZF9fv348WkEwyxOr9dtm4&s=4-NoEEHrIaJhrv1W6ZcntpGAspFt-yPgcVI53rwnsNM&e=

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 22 Mar 2019 15:39:56 +0000

Miao
 We have gone well beyond Wikipedia and analyzed  PFCP in detail. It has the right constructs to convey forwarding, traffic-management, and usage related state between CP and UP as required by a fully featured BNG for both fixed and fixed-wireless access. It is very extensible with the encodings defined for IEs and grouped IEs conveyed in PFCP objects. The natural order of addressing a problem space is to start with requirements and architecture, which is what we did with our drafts. That said, we have scoped the PFCP extensions for multiple functions in BNG, including dual-stack IPoE, PPPoE, L2TP LAC, H-QOS, LI, NAT. Lot of this is incremental. 
We have a draft on applicability of PFCP to BNG that can terminate multiple access and transport encapsulations. It details relevant PFCP extensions and is waiting to be submitted. We are just following the right order. Requirements and architecture framework first, before bringing in protocol work that maps to the architecture and requirements.

-Sanjay

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Friday, March 22, 2019 2:34 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; [email-masked]
Subject: [bcause] 答复: interest and scope?

Hi Sanjay,

- Miao

-----邮件原件-----
发件人: bcause [mailto:[email-masked]] 代表 Wadhwa, Sanjay (Nokia - US/Mountain View)
发送时间: 2019年3月21日 23:39
收件人: [email-masked]
主题: Re: [bcause] interest and scope?

Hi

Thanks
-Sanjay

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 22 Mar 2019 15:59:32 +0000

Indeed. BBF has relevant CUPS related WTs in progress that include  disaggregated BNG.

-Sanjay

-----Original Message-----
From: Gregory Dalle <[email-masked]> 
Sent: Friday, March 22, 2019 8:28 AM
To: Miaofuyou (Miao Fuyou) <[email-masked]>
Cc: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; [email-masked]
Subject: Re: [bcause] 答复: interest and scope?

Hi Miao,

Greg

---

From: Yu Tianpeng <[email-masked]>
Date: Fri, 22 Mar 2019 17:15:55 +0000

Hi Sanjay,
I had a read on PFCP, I am glad that I find there are some points inside
matching with my thoughts (e.g. the concept of PDR, PDI, FAR).
I wrote sth before reading PFCP
(draft-cups-rtgwg-cu-separation-requirement), with some similar ideas
inside (GSF).
But I also realize that there is pretty much work to do even we re-use the
current PFCP. There are a couple of points:
1. Current PFCP lacks considerations of many scenarios: e.g. 3-play,
service chaining (e.g. NAT, DPI, both intra-chassis and inter-chassis
chaining), network programming (e.g. segment routing)
2. Current PFCP design philosophy is “OpenFlow” like which makes co-working
with existing technologies listed above difficult
The challenge of CUPS protocol I believe is the service model between CP
and UP. But what PFCP has done so far is a very basic model (basic IP
forwarding with QoS parameters and some monitoring, there is no concept of
service inside even), but many functions not needed in BNG CUPS.
I have concerns on if PFCP is the right way if we consider co-working with
the technologies going on in IETF.
I also have a concern that PFCP chooses UDP as the transport protocol,
which lacks of congestion control and different from control protocols we
see usually. And in order to guarantee reliability, extra complexity has to
be introduced to PFCP protocol itself and its application.
Glad to hear your options on these.
Thanks in advance.
Regards,
Tim

On Fri, 22 Mar 2019, 15:40 Wadhwa, Sanjay (Nokia - US/Mountain View), <
[email-masked]> wrote:

> Miao
>  We have gone well beyond Wikipedia and analyzed  PFCP in detail. It has
> the right constructs to convey forwarding, traffic-management, and usage
> related state between CP and UP as required by a fully featured BNG for
> both fixed and fixed-wireless access. It is very extensible with the
> encodings defined for IEs and grouped IEs conveyed in PFCP objects. The
> natural order of addressing a problem space is to start with requirements
> and architecture, which is what we did with our drafts. That said, we have
> scoped the PFCP extensions for multiple functions in BNG, including
> dual-stack IPoE, PPPoE, L2TP LAC, H-QOS, LI, NAT. Lot of this is
> incremental.
> We have a draft on applicability of PFCP to BNG that can terminate
> multiple access and transport encapsulations. It details relevant PFCP
> extensions and is waiting to be submitted. We are just following the right
> order. Requirements and architecture framework first, before bringing in
> protocol work that maps to the architecture and requirements.
>
> -Sanjay
>
>
> Wikipedia says: "PFCP's scope is similar to that of OpenFlow, however it
> was engineered to serve the particular use-case of Mobile Core Networks.
> PFCP lacks the same general-purpose targets, describing well the
> 3GPP-specific functional basic blocks of packet forwarding used in 2G, 3G,
> 4G/LTE, Non-3GPP WiFi and 5G networks."
>
> Even so, it doesn't mean PFCP could not to be extended or changed to do
> more. However, there have to be an thorough analysis to PFCP to figure out
> what extension or change is needed. Otherwise, it's only intention
> expression rather than facts statement, which is not helpful to progress
> the work.
>
> - Miao
>
> -----邮件原件-----
> To be specific, with the right interfaces and functions on BNG, one can
> use current BNG deployed base to offer existing residential services over
> any of fixed-access, fixed-wireless (e.g. with LTE, LTE/CBRS, 5G NSA) or
> hybrid-access. Additionally, as mentioned in another post there is ongoing
> work for integrating fixed-access with 5GC via an adaptation function (AGF)
> to use a multi-access SMF/UPF.
> Using a particular option at a given time may be a decision based on ROI,
> state of the network or other constraints. However, going from one access
> to another on BNGs or 5GC SMF/UPF should not require a new baseline CUPS
> protocol, but rather extensions to a common protocol. The extensions mainly
> confine to the state information carried by the protocol based on
> access-facing and network-facing interface encapsulations on the
> network-element. Network elements can include BNG, AGF, SGW/PGW, TDF, 5GC
> SMF/UPF. Some of the functions provided by these network elements may be
> combined or instantiated on the same platform.
> Therefore, an access or use-case specific CUPS protocol is a dead-end. A
> common CUPS protocol that enables convergence will provide flexibility to
> evolve the network without worrying about yet another variable. Extending
> an existing standard protocol that is already purpose built for large scale
> state exchange is a sound way forward for BNG CUPS. With above in mind, we
> have considered PFCP applicability for BNG CUPS (irrespective of access)
> for some time now, including required PFCP IEs. Existing IETF drafts have
> covered BNG CUPS architecture and requirements that are addressed by PFCP.
>
> Thanks
> -Sanjay
>
> --
> bcause mailing list
> [email-masked]

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Fri, 22 Mar 2019 17:57:27 +0000

Hi,

Thanks for sharing the analysis is on-going!

My limited knowledge to 3GPP is WiFi is considered as a complement access technology for 3GPP technology, while BNG is not. I am not confident that BNG case could be supported by PFCP, that is why analysis is required and someone is working on it, as you said.

--------------------------------------------------
苗福友 Miao Fuyou
M: +86-18911316478<tel:+86-18911316478>(优先)
E: [email-masked]<mailto:[email-masked]>
产品与解决方案-网络标准专利部
Products & Solutions-Network Standard & Patent Dept
发件人：Gregory Dalle <[email-masked]>
收件人：Miaofuyou (Miao Fuyou) <[email-masked]>
抄 送：Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-03-22 16:28:33
主 题：Re: [bcause] 答复: interest and scope?

Hi Miao,

Greg

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 22 Mar 2019 19:00:03 +0000

Tim
 Of course, extending PFCP involves work. Your perception is a bit misplaced on existing PCFP capabilities though. PFCP supports steering. It allows CP to specify steering policy if UP signals support for steering in its capabilities. The steering can actually be controlled not only on per-session basis, but also per-flow or application basis.
PFCP has reliability mechanism built in that guarantees reliable delivery to the PFCP application on the peer (not just to the peer).

It seems pre-mature to discuss protocol details before scope and requirements.

-Sanjay

From: Yu Tianpeng <[email-masked]>
Sent: Friday, March 22, 2019 10:16 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>
Cc: Miaofuyou (Miao Fuyou) <[email-masked]>; [email-masked]
Subject: Re: [bcause] interest and scope?

Hi Sanjay,
I had a read on PFCP, I am glad that I find there are some points inside matching with my thoughts (e.g. the concept of PDR, PDI, FAR).
I wrote sth before reading PFCP (draft-cups-rtgwg-cu-separation-requirement), with some similar ideas inside (GSF).
But I also realize that there is pretty much work to do even we re-use the current PFCP. There are a couple of points:
1. Current PFCP lacks considerations of many scenarios: e.g. 3-play, service chaining (e.g. NAT, DPI, both intra-chassis and inter-chassis chaining), network programming (e.g. segment routing)
2. Current PFCP design philosophy is “OpenFlow” like which makes co-working with existing technologies listed above difficult
The challenge of CUPS protocol I believe is the service model between CP and UP. But what PFCP has done so far is a very basic model (basic IP forwarding with QoS parameters and some monitoring, there is no concept of service inside even), but many functions not needed in BNG CUPS.
I have concerns on if PFCP is the right way if we consider co-working with the technologies going on in IETF.
I also have a concern that PFCP chooses UDP as the transport protocol, which lacks of congestion control and different from control protocols we see usually. And in order to guarantee reliability, extra complexity has to be introduced to PFCP protocol itself and its application.
Glad to hear your options on these.
Thanks in advance.
Regards,
Tim

On Fri, 22 Mar 2019, 15:40 Wadhwa, Sanjay (Nokia - US/Mountain View), <[email-masked]<mailto:[email-masked]>> wrote:
Miao
 We have gone well beyond Wikipedia and analyzed  PFCP in detail. It has the right constructs to convey forwarding, traffic-management, and usage related state between CP and UP as required by a fully featured BNG for both fixed and fixed-wireless access. It is very extensible with the encodings defined for IEs and grouped IEs conveyed in PFCP objects. The natural order of addressing a problem space is to start with requirements and architecture, which is what we did with our drafts. That said, we have scoped the PFCP extensions for multiple functions in BNG, including dual-stack IPoE, PPPoE, L2TP LAC, H-QOS, LI, NAT. Lot of this is incremental.
We have a draft on applicability of PFCP to BNG that can terminate multiple access and transport encapsulations. It details relevant PFCP extensions and is waiting to be submitted. We are just following the right order. Requirements and architecture framework first, before bringing in protocol work that maps to the architecture and requirements.

-Sanjay

-----Original Message-----
From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Friday, March 22, 2019 2:34 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [bcause] 答复: interest and scope?

Hi Sanjay,

- Miao

-----邮件原件-----
发件人: bcause [mailto:[email-masked]<mailto:[email-masked]>] 代表 Wadhwa, Sanjay (Nokia - US/Mountain View)
发送时间: 2019年3月21日 23:39
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [bcause] interest and scope?

Hi

Thanks
-Sanjay

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Mar 2019 22:05:18 +0100

Hi Sanjay,
I think that you assume that the routing component is on the CP part of
CUPS. In the contribution from your colleague last week at BBF meeting, the
routing component was placed at UP. Hence, we have two scenarios, and each
poses different requirements. I think that it is too early to state that
PFCP can handle both.

Regards,
Greg

On Fri, Mar 22, 2019 at 8:03 PM Wadhwa, Sanjay (Nokia - US/Mountain View) <
[email-masked]> wrote:

> Tim
>
>  Of course, extending PFCP involves work. Your perception is a bit
> misplaced on existing PCFP capabilities though. PFCP supports steering. It
> allows CP to specify steering policy if UP signals support for steering in
> its capabilities. The steering can actually be controlled not only on
> per-session basis, but also per-flow or application basis.
>
> PFCP has reliability mechanism built in that guarantees reliable delivery
> to the PFCP application on the peer (not just to the peer).
>
>
>
> *From:* Yu Tianpeng <[email-masked]>
> *Sent:* Friday, March 22, 2019 10:16 AM
> *To:* Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>
> *Cc:* Miaofuyou (Miao Fuyou) <[email-masked]>; [email-masked]
> *Subject:* Re: [bcause] interest and scope?
>
>
>
> Hi Sanjay,
> 2. Current PFCP design philosophy is “OpenFlow” like which makes
> co-working with existing technologies listed above difficult

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 22 Mar 2019 23:46:46 +0000

Greg
No, we don’t assume or say routing is on CP in our drafts. Quite the contrary. What we presented in BBF is in sync with the drafts.
Although, there are active discussions in BBF on disaggregated BNG and one can always present options backed by use-case.

-Sanjay

From: Greg Mirsky <[email-masked]>
Sent: Friday, March 22, 2019 2:05 PM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>
Cc: Yu Tianpeng <[email-masked]>; [email-masked]; Miaofuyou (Miao Fuyou) <[email-masked]>
Subject: Re: [bcause] interest and scope?

Hi Sanjay,
I think that you assume that the routing component is on the CP part of CUPS. In the contribution from your colleague last week at BBF meeting, the routing component was placed at UP. Hence, we have two scenarios, and each poses different requirements. I think that it is too early to state that PFCP can handle both.

Regards,
Greg

On Fri, Mar 22, 2019 at 8:03 PM Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>> wrote:
Tim
 Of course, extending PFCP involves work. Your perception is a bit misplaced on existing PCFP capabilities though. PFCP supports steering. It allows CP to specify steering policy if UP signals support for steering in its capabilities. The steering can actually be controlled not only on per-session basis, but also per-flow or application basis.
PFCP has reliability mechanism built in that guarantees reliable delivery to the PFCP application on the peer (not just to the peer).

-Sanjay

From: Yu Tianpeng <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 22, 2019 10:16 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bcause] interest and scope?

Hi Sanjay,

-Sanjay

-----Original Message-----
From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Friday, March 22, 2019 2:34 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [bcause] 答复: interest and scope?

Hi Sanjay,

- Miao

-----邮件原件-----
发件人: bcause [mailto:[email-masked]<mailto:[email-masked]>] 代表 Wadhwa, Sanjay (Nokia - US/Mountain View)
发送时间: 2019年3月21日 23:39
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [bcause] interest and scope?

Hi

Thanks
-Sanjay

---

From: Gregory Dalle <[email-masked]>
Date: Sat, 23 Mar 2019 13:45:33 +0000

Hi Miao,

I am confident that PFCP can also be used for BNG. If you look at 4G, PFCP is used in 3 different use cases (for reference, Sxa, Sxb and Sxc) - each with distinct set of requirements. Quite flexible.

I will not be in Prague but I hope you will have good discussions.

Greg

On Mar 22, 2019, at 1:57 PM, Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

--------------------------------------------------
苗福友 Miao Fuyou
M: +86-18911316478<tel:+86-18911316478>(优先)
E: [email-masked]<mailto:[email-masked]>
产品与解决方案-网络标准专利部
Products & Solutions-Network Standard & Patent Dept
发件人：Gregory Dalle <[email-masked]<mailto:[email-masked]>>
收件人：Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>
抄 送：Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-22 16:28:33
主 题：Re: [bcause] 答复: interest and scope?

Hi Miao,

Greg

> On Mar 22, 2019, at 5:34 AM, Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Sanjay,
>

---

From: Rajesh A Shinde <[email-masked]>
Date: Sun, 24 Mar 2019 07:07:03 +0000

Hello All,

Basically, we should not have always new protocol, if we can manage with existing, well best fit protocol like PFCP as operationally it would be easier and skillset expectation would also meet from Telco perspective.

I will not be in Prague, however expect to have healthy discussions keeping telco perspective in mind.

~ Rajesh

Sent: Saturday, March 23, 2019 7:16 PM

Hi Miao,

Greg

Hi Miao,

Greg

> Therefore, an access or use-case specific CUPS protocol is a dead-end. A common CUPS protocol that enables convergence will provide flexibility to evolve the network without worrying about yet anot…
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Mar 2019 14:20:22 +0100

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

---

From: Gregory Dalle <[email-masked]>
Date: Mon, 25 Mar 2019 19:23:25 +0000

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 <[email-masked]> On Behalf Of Greg Mirsky
Sent: Monday, March 25, 2019 9:20 AM
To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

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

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

---

Thank you
Martin
--
Bcause mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Mar 2019 20:42:47 +0100

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 <[email-masked]> 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”.
>
>
>
> 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 <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Monday, March 25, 2019 9:20 AM
> *To:* Vigoureux, Martin (Nokia - FR/Paris-Saclay) <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [bcause] [Bcause] interest and scope?
>
>
>
> Hi Martin, et al.,
>
> On Mon, Mar 4, 2019 at 2:22 PM Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[email-masked]> wrote:
>
> Hello,
>
> 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
> <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://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://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://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=>
>
>
> ---
> <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=>
>
>

---

From: Gregory Dalle <[email-masked]>
Date: Mon, 25 Mar 2019 19:50:57 +0000

Hi Greg M,

Sorry, I am not clear.

  *   Why does use of PFCP instead of CUSP (since I assume this is the comparison) would have an increased OPEX?
  *   What do you mean by “new protocol” – PFCP is an existing standard protocol. Isn’t CUSP the new protocol candidate in this context?

Regards,
Greg D

From: Greg Mirsky <[email-masked]>
Sent: Monday, March 25, 2019 3:43 PM
To: Gregory Dalle <[email-masked]>
Cc: Martin Vigoureux <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg M,

Thanks,
Greg D

From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: Monday, March 25, 2019 9:20 AM
To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Aijun Wang@China Telecom" <[email-masked]>
Date: Mon, 25 Mar 2019 20:55:35 +0100

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=[email-masked]> wrote:
> 
> Hi Greg M,
>  
> 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
>  
> On Mon, Mar 4, 2019 at 2:22 PM Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]> wrote:
> Hello,
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Mar 2019 20:56:59 +0100

Hi Greg D,
PFCP, AFAIK, is not "in place of CUPS" but the protocol of CUPS, for one of
interfaces.
PFCP is not used in FN-only networks. FN-only operators expressed their
preference of the protocols to be considered for CUPS from among those
already used in their network, perhaps for other purposes.
Hope that clarifies things.

Regards,
Greg M

On Mon, Mar 25, 2019, 20:51 Gregory Dalle <[email-masked]> wrote:

> Hi Greg M,
>
>
> Sorry, I am not clear.
>
>    - Why does use of PFCP instead of CUSP (since I assume this is the
>    comparison) would have an increased OPEX?
>    - What do you mean by “new protocol” – PFCP is an existing standard
>    protocol. Isn’t CUSP the new protocol candidate in this context?
>
>
>
> Regards,
>
> Greg D
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Monday, March 25, 2019 3:43 PM
> *To:* Gregory Dalle <[email-masked]>
> *Cc:* Martin Vigoureux <[email-masked]>; [email-masked]

---

From: Gregory Dalle <[email-masked]>
Date: Mon, 25 Mar 2019 20:18:38 +0000

Hi Greg,

OK, that’s clearer. If I rephrase: Some operators are deploying CUPS based on a proprietary protocol today and if any other protocol (than the one they use) is selected for BNG CUPS standards, they will incur some new costs (testing, licensing, etc) when migrating to the standard solution.

Regards,
Greg D

Sent: Monday, March 25, 2019 3:57 PM

Hi Greg D,
PFCP, AFAIK, is not "in place of CUPS" but the protocol of CUPS, for one of interfaces.
PFCP is not used in FN-only networks. FN-only operators expressed their preference of the protocols to be considered for CUPS from among those already used in their network, perhaps for other purposes.
Hope that clarifies things.

Regards,
Greg M

On Mon, Mar 25, 2019, 20:51 Gregory Dalle <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg M,

Sorry, I am not clear.

Regards,
Greg D

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 25, 2019 3:43 PM
To: Gregory Dalle <[email-masked]<mailto:[email-masked]>>
Cc: Martin Vigoureux <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: Gregory Dalle <[email-masked]>
Date: Mon, 25 Mar 2019 20:30:22 +0000

Hi Aijun,

I hear you have to join the BBF meetings to get the answers to these questions 😉
That being said, this mailing list is not about BNG versus AGF and 5G core. You could use PFCP between BNG-CP and BNG-UP, without any form of 5G convergence.

Personally I don’t subscribe to a view that would split BNG domain into 2 clearly isolated segments: the “basic BNG” (TR178) and the “integrated BNG” (with wireless or convergence support). My view is that this is a continuum and we cannot just artificially build a wall in-between. For example, does Diameter Gx on a BNG make it “an integrated BNG”, since this is based on TR-300 (Policy Convergence)? I know “Fixed Network only” operators that use Gx/PCRF.

Regards,
Greg

From: Aijun Wang@China Telecom <[email-masked]>
Sent: Monday, March 25, 2019 3:56 PM
To: Gregory Dalle <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>; [email-masked]
Subject: Re: [bcause] [Bcause] interest and scope?

Hi, Gregory:

On Mar 25, 2019, at 20:23, Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=[email-masked]>> wrote:
Hi Greg M,

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

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

---

Thank you
Martin
--
Bcause mailing list
[email-masked]<mailto:[email-masked]>
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=>
--
bcause mailing list
[email-masked]<mailto:[email-masked]>
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=GGbsRmcqJ3a17WOYMLVlwPyVDTIpdb9ItkZSHgdBDaw&s=2TkSZomez3l81DzY7ouAgpNcdTaahpMJNo8-eqzZAUI&e=>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 26 Mar 2019 00:36:51 +0000

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 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Sent: Tuesday, March 26, 2019 3:43 AM
To: Gregory Dalle ([email-masked])
Cc: [email-masked]; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: <[email-masked]>
Date: Tue, 26 Mar 2019 08:46:59 +0000

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 <[email-masked]> On Behalf Of Greg Mirsky
Sent: maandag 25 maart 2019 20:43
To: Gregory Dalle ([email-masked]) <[email-masked]>
Cc: [email-masked]; Martin Vigoureux <[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Mar 2019 09:56:26 +0100

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) <
[email-masked]> 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 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Sent:* Tuesday, March 26, 2019 3:43 AM
> *To:* Gregory Dalle ([email-masked])
> *Cc:* [email-masked]; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
>> 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
>> On Mon, Mar 4, 2019 at 2:22 PM Vigoureux, Martin (Nokia -

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 26 Mar 2019 08:57:43 +0000

Thanks for clarifying

Kind regards,
Andrew

On 2019-03-26, 4:56 PM, "Greg Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

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) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Regards,
Andrew

________________________________
From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 26, 2019 3:43 AM
To: Gregory Dalle ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]<mailto:[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Greg D.,

Regards,
Greg M

A.      2 operators said they are interested only in fixed access BNG

B.      5 operators said they don’t want to restrict the protocol discussion to fixed access only

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:14:35 +0000

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.

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.
发件人：eduard.metz=[email-masked] <eduard.metz=[email-masked]>
收件人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
抄 送：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-03-26 09:47:34
主 题：Re: [bcause] [Bcause] interest and scope?

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: David Allan I <[email-masked]>
Date: Tue, 26 Mar 2019 09:21:26 +0000

Hi Miao

You are assuming a particular way of working when asserting your concern.  If all that is needed is additional information elements and the protocol semantics are effectively complete for our purposes, your concern would be significantly mitigated.

Cheers

Dave

From: bcause <[email-masked]> On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Tuesday, March 26, 2019 10:15 AM
To: eduard.metz=[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [bcause] [Bcause] interest and scope?

发件人：eduard.metz=[email-masked] <mailto:eduard.metz=[email-masked]>  <eduard.metz=[email-masked] <mailto:eduard.metz=[email-masked]> >

收件人：[email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >;[email-masked] <[email-masked] <mailto:[email-masked]> >

抄 送：[email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >;[email-masked] <[email-masked] <mailto:[email-masked]> >

时间：2019-03-26 09:47:34

 

cheers,

               Eduard

From: bcause <[email-masked] <mailto:[email-masked]> > On Behalf Of Greg Mirsky
Sent: maandag 25 maart 2019 20:43
To: Gregory Dalle ([email-masked] <mailto:[email-masked]> ) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Martin Vigoureux <[email-masked] <mailto:[email-masked]> >
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Greg D.,

Regards, 

Greg M

On Mon, Mar 25, 2019, 20:23 Gregory Dalle <[email-masked] <mailto:[email-masked]> > wrote:

Hi Greg M,

Thanks,

Greg D

From: bcause <[email-masked] <mailto:[email-masked]> > On Behalf Of Greg Mirsky
Sent: Monday, March 25, 2019 9:20 AM
To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Martin, et al.,

Regards,

Greg

On Mon, Mar 4, 2019 at 2:22 PM Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked] <mailto:[email-masked]> > wrote:

Hello,

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 

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

---

Thank you
Martin
-- 
Bcause mailing list
[email-masked] <mailto:[email-masked]> 
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=>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:23:07 +0000

To shime in here

From: bcause <[email-masked]> on behalf of "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Tuesday, 26 March 2019 at 10:14
To: "eduard.metz=[email-masked]" <eduard.metz=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

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.

WH> We already checked with our 3GPP people and the protocol can be extendable easily based on codepoint assignment.

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Aijun Wang@China Telecom" <[email-masked]>
Date: Tue, 26 Mar 2019 10:28:10 +0100

Can we define first the TLV/IE first and put the protocols selection in future?

Aijun Wang
China Telecom

> On Mar 26, 2019, at 10:23, Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> To shime in here
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Mar 2019 10:30:35 +0100

Hi Wim,
I'll note that applicability of PFCP in AGF CUPS and FMIF CUPS still under
investigation. And one of the questions to be answered is Why 3GPP narrowed
the scope of applicability of PFCP in 5G comparing to LTE? It may be the
case that only introduction of the new IEs would not be sufficient to
address all the requirements of DBNG CUPS and some architectural, e.g. FSM,
changes may be needed. Would 3GPP accept such changes or will consider this
as the new, different from PFCP protocol and decide not to own it?

Regards,
Greg

On Tue, Mar 26, 2019 at 10:23 AM Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> To shime in here
>
>
>
> *From: *bcause <[email-masked]> on behalf of "Miaofuyou (Miao
> Fuyou)" <[email-masked]>
> *Date: *Tuesday, 26 March 2019 at 10:14
> *To: *"eduard.metz=[email-masked]" <eduard.metz=
> [email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia -
> FR/Paris-Saclay)" <[email-masked]>
> *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=[email-masked] <eduard.metz=
> [email-masked]>
>
> *收件人：[email-masked] <[email-masked]>;[email-masked] <
> [email-masked]>
>
> *抄* *送：[email-masked] <[email-masked]>;[email-masked] <
> *时间**：*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
>
>
>
>
>
> *Sent:* maandag 25 maart 2019 20:43
> *To:* Gregory Dalle ([email-masked]) <[email-masked]>
> *Cc:* [email-masked]; Martin Vigoureux <[email-masked]>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:32:29 +0000

If the issue is understanding how PFCP can be extended to support this we have a proposal that can be discussed and we also have an implementation that shows the feasibility if that helps.

From: "Aijun Wang@China Telecom" <[email-masked]>
Date: Tuesday, 26 March 2019 at 10:28
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "Miaofuyou (Miao Fuyou)" <[email-masked]>, "eduard.metz=[email-masked]" <eduard.metz=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

On Mar 26, 2019, at 10:23, Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:
To shime in here

From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of "Miaofuyou (Miao Fuyou)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 26 March 2019 at 10:14
To: "eduard.metz=[email-masked]<mailto:eduard.metz=[email-masked]>" <eduard.metz=[email-masked]<mailto:eduard.metz=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] [Bcause] interest and scope?

发件人：eduard.metz=[email-masked]<mailto:eduard.metz=[email-masked]> <eduard.metz=[email-masked]<mailto:eduard.metz=[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-26 09:47:34
主 题：Re: [bcause] [Bcause] interest and scope?

cheers,
               Eduard

From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: maandag 25 maart 2019 20:43
To: Gregory Dalle ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Mar 2019 10:34:59 +0100

Hi Aijun,
I believe that our work will be more efficient if we start with the
requirements and the functional architecture of DBNG CUPS. IEs will be more
clear once we get the requirements and the functional architecture work
stable.

Regards,
Greg

On Tue, Mar 26, 2019 at 10:28 AM Aijun Wang@China Telecom <
[email-masked]> wrote:

> *To: *"eduard.metz=[email-masked]" <
> eduard.metz=[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *发**件人：*eduard.metz=[email-masked] <
> eduard.metz=[email-masked]>
>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:39:35 +0000

Greg, PFCP is running in 4G/LTE already and is not depending on 5G. Hence why I said this is running and is deployed at scale.
We have a proposal and implementation which shows the feasibility for the fixed use case. The extensions are fairly straightforward and the good thing is we can reuse the majority of the capabilities in the PFCP protocol. Reusing a hardened protocol and serving the industry a common protocol is what we should aim for. As such:

  *   If people want to use it for fixed only, they can
  *   If people want to use it for mobile only use cases they can
  *   If people want to combine fixed and mobile use case they can
So serving all scenario’s. I fail to see why we should not do this.

From: Greg Mirsky <[email-masked]>
Date: Tuesday, 26 March 2019 at 10:30
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "Miaofuyou (Miao Fuyou)" <[email-masked]>, "eduard.metz=[email-masked]" <eduard.metz=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Wim,
I'll note that applicability of PFCP in AGF CUPS and FMIF CUPS still under investigation. And one of the questions to be answered is Why 3GPP narrowed the scope of applicability of PFCP in 5G comparing to LTE? It may be the case that only introduction of the new IEs would not be sufficient to address all the requirements of DBNG CUPS and some architectural, e.g. FSM, changes may be needed. Would 3GPP accept such changes or will consider this as the new, different from PFCP protocol and decide not to own it?

Regards,
Greg

On Tue, Mar 26, 2019 at 10:23 AM Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:
To shime in here

To: "eduard.metz=[email-masked]<mailto:[email-masked]>" <eduard.metz=[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

发件人：eduard.metz=[email-masked]<mailto:[email-masked]> <eduard.metz=[email-masked]<mailto:[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-26 09:47:34
主 题：Re: [bcause] [Bcause] interest and scope?

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:46:11 +0000

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) <[email-masked]>
收件人：Miaofuyou (Miao Fuyou) <[email-masked]>;eduard.metz=[email-masked] <eduard.metz=[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
抄 送：[email-masked] <[email-masked]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
时间：2019-03-26 10:23:21
主 题：Re: [bcause] [Bcause] interest and scope?

To shime in here

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: David Sinicrope <[email-masked]>
Date: Tue, 26 Mar 2019 09:49:13 +0000

(IETF Liaison Manager - BBF hat on)

Greg,

When you say “our work will be more efficient if we start with the requirements and functional architecture of DBNG CUPS.”  are you advocating overlap with and/or duplication of the BBF Disaggregated BNG work that they reference in the liaison (WT-459)?  I’m interpreting “we” to be IETF.  Is this correct?
Thanks,
Dave

From: bcause <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Tuesday, March 26, 2019 at 10:35 AM
To: "Aijun Wang@China Telecom" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Miaofuyou (Miao Fuyou)" <[email-masked]>, "eduard.metz=[email-masked]" <eduard.metz=[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, Wim Henderickx <[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Aijun,
I believe that our work will be more efficient if we start with the requirements and the functional architecture of DBNG CUPS. IEs will be more clear once we get the requirements and the functional architecture work stable.

Regards,
Greg

On Tue, Mar 26, 2019 at 10:28 AM Aijun Wang@China Telecom <[email-masked]<mailto:[email-masked]>> wrote:
Can we define first the TLV/IE first and put the protocols selection in future?
Aijun Wang
China Telecom

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.

cheers,
               Eduard

Cc: bcause@ietf..org<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Cc: bcause@ietf..org<mailto:[email-masked]>

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:53:13 +0000

I would say let’s do it rather than trying to debate why it in theory is slow. If you want the codepoint from 3GPP that will be can allocated very quick (days).  Btw BBF has the expertise on this environment and knows how to extend IE in existing protocols. So if we want to hurry up lets speed up things in BBF.

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Tuesday, 26 March 2019 at 10:46
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, "eduard.metz=[email-masked]" <eduard.metz=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Subject: RE: [bcause] [Bcause] interest and scope?

Hi Wim,

To shime in here

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Mar 2019 10:53:32 +0100

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:
> 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.
> 
> 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) <[email-masked]>
> *收件人：*Miaofuyou (Miao Fuyou) 
> <[email-masked]>;eduard.metz=[email-masked] 
> <eduard.metz=[email-masked]>;[email-masked] 
> <[email-masked]>;[email-masked] <[email-masked]>
> *抄 送：[email-masked] <[email-masked]>;Vigoureux, Martin (Nokia - 
> FR/Paris-Saclay) <[email-masked]>
> *时间：*2019-03-26 10:23:21
> *主 题：*Re: [bcause] [Bcause] interest and scope?
> 
> To shime in here
> 
> *To: *"eduard.metz=[email-masked]" 
> <eduard.metz=[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> 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.
> 
> *发**件人：*eduard.metz=[email-masked] 
> <eduard.metz=[email-masked]>
> 
> *收件人：[email-masked] 
> <[email-masked]>;[email-masked] <[email-masked]>
> 
> *抄** **送：[email-masked] 
> <[email-masked]>;[email-masked] <[email-masked]>
> 
> *主** **题**：*Re: [bcause] [Bcause] interest and scope?
> 
> thank you for consideration. The situation for the FN-only operators, as 
> I understand it, is complicated by the insistence that only PFCP-based 
>     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”.
> 
>     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 <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of *Greg Mirsky
>     *To:* Vigoureux, Martin (Nokia - FR/Paris-Saclay)
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     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
>     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
> 
>     FR/Paris-Saclay) <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hello,
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Mar 2019 10:56:45 +0100

Hi Dave,
my comment was not specific to SDO. I was pointing that before defining IEs
would be appropriate to agree on the requirements and the functional
architecture. As you know, I'm willing to contribute to the effort
regardless of where it will be anchored.

Regards,
Greg

On Tue, Mar 26, 2019 at 10:49 AM David Sinicrope <
[email-masked]> wrote:

> When you say “our work will be more efficient if we start with the
> requirements and functional architecture of DBNG CUPS.”  are you advocating
> overlap with and/or duplication of the BBF Disaggregated BNG work that they
> reference in the liaison (WT-459)?  I’m interpreting “we” to be IETF.  Is
> this correct?
>
> Thanks,
>
> Dave
>
>
>
> *From: *bcause <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Tuesday, March 26, 2019 at 10:35 AM
> *To: *"Aijun Wang@China Telecom" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Miaofuyou (Miao Fuyou)" <
> [email-masked]>, "eduard.metz=[email-masked]"
> <eduard.metz=[email-masked]>, "[email-masked]" <
> [email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <
> [email-masked]>, Wim Henderickx <[email-masked]>
> It really dpends on how much of PFCP could be reused.. There are
> *抄 **送：[email-masked] <[email-masked]>;[email-masked] <
> *主 **题**：*Re: [bcause] [Bcause] interest and scope?
>
>
>
>
>
> *Cc:* bcause@ietf..org <[email-masked]>; Martin Vigoureux <
> *Cc:* bcause@ietf..org <[email-masked]>

---

From: Mach Chen <[email-masked]>
Date: Tue, 26 Mar 2019 10:00:13 +0000

Hi all,

I just had a quick look at the PFCP protocol, seems that the messages and IEs(TLVs) are designed to couple with the specific interfaces (Sxa, Sxb, Sx, N4), if we are going to consider BNG, AGF, FMIF, xxxF…., more interfaces will be introduced, does it mean that for each new added interface, it has to verify whether all the existing IEs can be applied to the new interfaces, and then update the protocol accordingly.  In addition, for a new added IE, it seems that it needs to verify whether this IE can be applied to the existing interfaces and protocol updated also needed.

I am not an 3GPP expert, I am just curious whether the above is the case?

FYI, below are two tables that I just copied from PFCP protocol.

Message Type value (Decimal)

Message

Applicability

Sxa

Sxb

Sxc

N4

0

Reserved

PFCP Node related messages

1

PFCP Heartbeat Request

X

X

X

X

2

PFCP Heartbeat Response

X

X

X

X

3

PFCP PFD Management Request

-

X

X

X

4

PFCP PFD Management Response

-

X

X

X

5

PFCP Association Setup Request

X

X

X

X

6

PFCP Association Setup Response

X

X

X

X

7

PFCP Association Update Request

X

X

X

X

8

PFCP Association Update Response

X

X

X

X

9

PFCP Association Release Request

X

X

X

X

10

PFCP Association Release Response

X

X

X

X

11

PFCP Version Not Supported Response

X

X

X

X

12

PFCP Node Report Request

X

X

X

X

13

PFCP Node Report Response

X

X

X

X

Octet 1 and 2

Application ID's PFDs IE Type = 58 (decimal)

Octets 3 and 4

Length = n

Information elements

P

Condition / Comment

Appl.

IE Type

Sxa

Sxb

Sxc

N4

Application ID

M

This IE shall identify the Application ID for which PFDs shall be provisioned in the UP function.

-

X

X

X

Application ID

PFD

C

This IE shall be present if the PFD needs to be provisioned in the UP function.

When present, it shall describe the PFD to be provisioned in the UP function.

Several IEs with the same IE type may be present to provision multiple PFDs for this Application ID.

When this IE is absent, the UP function shall delete all the PFDs received and stored earlier in the UP function for this Application ID.

-

X

X

X

PFD

From: bcause [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, March 26, 2019 5:31 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Cc: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>; [email-masked]; eduard.metz=[email-masked]; [email-masked]; Miaofuyou (Miao Fuyou) <[email-masked]>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Wim,

Regards,
Greg

发件人：eduard.metz=[email-masked]..org<mailto:[email-masked]> <eduard.metz=[email-masked]<mailto:[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-26 09:47:34
主 题：Re: [bcause] [Bcause] interest and scope?

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 26 Mar 2019 10:16:51 +0000

The idea is to define applicability matrix for IEs and then define needed extensions to current IEs or new IEs. The messages are largely applicable as one would notice.
We have looked at applicability for BNG and identified extensions. We intend to expeditiously bring this as formal contribution to start discussions.

-Sanjay

From: bcause <[email-masked]> On Behalf Of Mach Chen
Sent: Tuesday, March 26, 2019 3:00 AM
To: Greg Mirsky <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]; eduard.metz=[email-masked]; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]>; [email-masked]
Subject: Re: [bcause] [Bcause] interest and scope?

Hi all,

Message

Applicability

Sxa

Sxb

Sxc

N4

0

Reserved

1

PFCP Heartbeat Request

X

X

X

X

2

PFCP Heartbeat Response

X

X

X

X

3

-

X

X

X

4

-

X

X

X

5

X

X

X

X

6

X

X

X

X

7

X

X

X

X

8

X

X

X

X

9

X

X

X

X

10

X

X

X

X

11

X

X

X

X

12

PFCP Node Report Request

X

X

X

X

13

X

X

X

X

Octet 1 and 2

Octets 3 and 4

Length = n

Information elements

P

Condition / Comment

Appl.

IE Type

Sxa

Sxb

Sxc

N4

Application ID

M

-

X

X

X

Application ID

PFD

C

-

X

X

X

PFD

From: bcause [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, March 26, 2019 5:31 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>
Cc: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; eduard.metz=[email-masked]<mailto:eduard.metz=[email-masked]>; [email-masked]<mailto:[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] [Bcause] interest and scope?

Hi Wim,

Regards,
Greg

cheers,
               Eduard

Hi Greg D.,

Regards,
Greg M

Thanks,
Greg D

Hi Martin, et al.,

Regards,
Greg

---

Thank you
Martin