Subject: Re: [bcause] to wait or not to wait

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 Mar 2019 17:10:30 +0000

There is not a single draft of requirements but multiple since you have not covered all operators use cases in your draft. So the current scope of your draft is incomplete from that pov. I list the sets of docs I am aware about

https://tools.ietf.org/html/draft-cuspdt-rtgwg-cusp-requirements-03
https://tools.ietf.org/html/draft-wadhwa-rtgwg-bng-cups-protocol-requirements-02
https://tools.ietf.org/html/draft-wadhwa-rtgwg-bng-cups-03

On top you don’t have any requirements on overload, latency, # transactions for a session setup, lawful intercept, session definition/information elements required, etc. So if you believe it is complete I don’t agree.

From: "[email-masked]" <[email-masked]>
Date: Wednesday, 27 March 2019 at 11:01
To: "[email-masked]" <[email-masked]>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re:[bcause] to wait or not to wait

The requirements we are waiting for from BBF till Q3 have actually been right here in great degree in RTGWG for one year, some latest new upload was a quarter ago, so I do not think it is less informed and not aware for the community in IETF when it comes to protocol requirements of DBNG. The expected gap between what we have and what we are waiting for from BBF does not justify the total suspension of the work here in IETF.

发自我的zMail

原始邮件
发件人：秦凤伟<[email-masked]>;
收件人：David Fan<[email-masked]>;Henderickx. Wim (Nok<[email-masked]>;MachChen<[email-masked]>;Loa Andersson<[email-masked]>;Vigoureux. Martin(No<[email-masked]>;
抄送人：[email-masked]<[email-masked]>;
日期：2019-03-27 10:08:02
主题：Re: [bcause] to wait or not to wait
--
bcause mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bcause

Hi,

Given that the requirements draft have been submitted 2 year ago , the requirement of China Mobile is clear and the large-scale deployment is planned early 2020. It is very urgent for us and could not wait another 5 months to confirm the requirements of long-term evolution.

 I think it is a good idea that starts work in parallel in both BBF and IETF. As we all know, there are too many protocols done in IETF, such as PPPoE(RFC 2516), IPoE (RFC 1541/RFC2132/RFC4046), AAA (RFC3539), IETF should define the communication protocols for the confirmed architecture and requirements. BBF works on the requirements of the long-term evolution.

Thanks,

Fengwei Qin

China Mobile

----邮件原文----
发件人：David Fan  <[email-masked]>
收件人："Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>,MachChen <[email-masked]>,Loa Andersson  <[email-masked]>,"Vigoureux, Martin(Nokia - FR/Paris-Saclay)" <[email-masked]>
抄　送: "[email-masked]" <[email-masked]>
发送时间：2019-03-27 16:51:54
主题：Re: [bcause] to wait or not to wait

Hi Wim

I think China Mobile Requirements is quite clear, Do you agree? I cover the BNG requirements.
The problem is do we(IETF) need to wait for more requirement beyond BNG. And maybe make one operator thing we are slow and maybe go to other place?
I heard someone already said some delay at the meeting.
And if we wait 3~5 month , just get a list requirement and more than 80% requirement is just requirement already in BNG, what about our waiting for.
So, we must give a formal way to continue about this work and not to block.

David.Fan
----- -----
From: bcause [mailto:[email-masked]] 代表 Henderickx, Wim (Nokia - BE/Antwerp)
TIme: 2019年3月27日 14:38
Receipt: Mach Chen  Loa Andersson  Vigoureux, Martin (Nokia - FR/Paris-Saclay)
CC: [email-masked]
Title: Re: [bcause] to wait or not to wait

I haven’t said we start from 0. I am saying put the effort in 1 place and we will speed things up rather than trying to debate forever.
I say this for the following reasons:
1. in IETF I have yet to find a definition what a BNG is.
2. Your work is missing use cases which many operators have expressed to be required on the mailing list. So you have an incomplete scope and BBF incorporated them.
3. you say BBF milestones which are Q3/2019, so don’t see how this can be improved with parallel work

On 27/03/2019, 00:03, "Mach Chen" wrote:

 Hi Wim,

 We do not start from zero, the work have been around in IETF since 2017, the DBNG project just started on Feb this year, I think it was more or less motivated by the activities in IETF.

 I don't think that starting the work parallel in both IETF and BBF will disperse the energy in BBF. On the contrary, the work in IETF is very likely to promote and accelerate the work in BBF. At the same time, the output of BBF is also conducive to the work in IETF. It's a mutual process IMHO.

 Best regards,
 Mach

 > -----Original Message-----
 > From: Henderickx, Wim (Nokia - BE/Antwerp)
 > [mailto:[email-masked]]
 > Sent: Wednesday, March 27, 2019 12:53 AM
 > To: Mach Chen  Loa Andersson
 > Vigoureux, Martin (Nokia - FR/Paris-Saclay)
 > Cc: [email-masked]
 > Subject: Re: [bcause] to wait or not to wait
 >
 > If we want to speedup things I will repeat myself we should focus effort in 1
 > place and not 2. Given BBF has the expertise lets unite there.
 >
 > On 26/03/2019, 17:43, "bcause on behalf of Mach Chen"
 > wrote:
 >
 > Hi Loa and all,
 >
 > I tend to agree with Loa, wait is not good option.
 >
 > Given that there are clear requirements from Operator and timeframe for
 > deployment is very tight. I think we'd better to speed up the standard process
 > to satisfy their requirements, but not the other way around.
 >
 > Regarding the requirements, actually, there are two requirement
 > individual drafts submitted in 2017, and presented in RTGWG several times.
 > Seems that we are not lack of requirements here.
 >
 > We have missed the past two years, to wait another 5 months seems not
 > an efficient way. As many people said, there are quite a lot of people actively
 > involved in the work in both BBF and IETF. To start the work parallel in both BBF
 > and IETF can definitely speed up process.
 >
 > Best regards,
 > Mach
 >
 > > -----Original Message-----
 > > From: bcause [mailto:[email-masked]] On Behalf Of Loa
 > Andersson
 > > Sent: Tuesday, March 26, 2019 8:28 PM
 > > To: Martin Vigoureux
 > > Cc: [email-masked]
 > > Subject: [bcause] to wait or not to wait
 > >
 > > Martin,
 > >
 > > When you summarized the BoF you said that the you had the feeling in
 > the
 > > room was that we wait for BBF to complete their requirements.
 > >
 > > While, I think your evaluation might be right, I don't think that it should
 > stop us
 > > from doing some work in the mean time. I think that that was the feeling
 > that
 > > most people left the room.
 > >
 > > As things are, we have enough people participating in both BBF and IETF,
 > and
 > > that they well understand what should be done. We know the major part
 > of
 > > what the BBF requirents will, and it is enough to start working.
 > > And yes I understand that there might be late surprises, but we can
 > manage
 > > that.
 > >
 > > /Loa
 > >
 > > --
 > >
 > >
 > > Loa Andersson email: [email-masked]
 > > Senior MPLS Expert
 > > Bronze Dragon Consulting phone: +46 739 81 21 64
 > >
 > > --
 > > bcause mailing list
 > > [email-masked]
 > > https://www.ietf.org/mailman/listinfo/bcause
 >
 > --
 > bcause mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/bcause
 >

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

Subject：Re: [bcause] to wait or not to wait

Hi Wim

I think China Mobile Requirements is quite clear, Do you agree? I cover the BNG requirements.
The problem is do we(IETF) need to wait for more requirement beyond BNG. And maybe make one operator thing we are slow and maybe go to other place?
I heard someone already said some delay at the meeting.
And if we wait 3~5 month , just get a list requirement and more than 80% requirement is just requirement already in BNG, what about our waiting for.
So, we must give a formal way to continue about this work and not to block.

David.Fan
----- -----
From: bcause [mailto:[email-masked]] 代表 Henderickx, Wim (Nokia - BE/Antwerp)
TIme: 2019年3月27日 14:38
Receipt: Mach Chen  Loa Andersson  Vigoureux, Martin (Nokia - FR/Paris-Saclay)
CC: [email-masked]
Title: Re: [bcause] to wait or not to wait

I haven’t said we start from 0. I am saying put the effort in 1 place and we will speed things up rather than trying to debate forever.
I say this for the following reasons:
1. in IETF I have yet to find a definition what a BNG is.
2... Your work is missing use cases which many operators have expressed to be required on the mailing list. So you have an incomplete scope and BBF incorporated them.
3. you say BBF milestones which are Q3/2019, so don’t see how this can be improved with parallel work

On 27/03/2019, 00:03, "Mach Chen" wrote:

 Hi Wim,

 We do not start from zero, the work have been around in IETF since 2017, the DBNG project just started on Feb this year, I think it was more or less motivated by the activities in IETF.

 I don't think that starting the work parallel in both IETF and BBF will disperse the energy in BBF. On the contrary, the work in IETF is very likely to promote and accelerate the work in BBF. At the same time, the output of BBF is also conducive to the work in IETF. It's a mutual process IMHO.

 Best regards,
 Mach

 > -----Original Message-----
 > From: Henderickx, Wim (Nokia - BE/Antwerp)
 > [mailto:[email-masked]]
 > Sent: Wednesday, March 27, 2019 12:53 AM
 > To: Mach Chen  Loa Andersson
 > Vigoureux, Martin (Nokia - FR/Paris-Saclay)
 > Cc: [email-masked]
 > Subject: Re: [bcause] to wait or not to wait
 >
 > If we want to speedup things I will repeat myself we should focus effort in 1
 > place and not 2. Given BBF has the expertise lets unite there.
 >
 > On 26/03/2019, 17:43, "bcause on behalf of Mach Chen"
 > wrote:
 >
 > Hi Loa and all,
 >
 > I tend to agree with Loa, wait is not good option.
 >
 > Given that there are clear requirements from Operator and timeframe for
 > deployment is very tight. I think we'd better to speed up the standard process
 > to satisfy their requirements, but not the other way around.
 >
 > Regarding the requirements, actually, there are two requirement
 > individual drafts submitted in 2017, and presented in RTGWG several times.
 > Seems that we are not lack of requirements here.
 >
 > We have missed the past two years, to wait another 5 months seems not
 > an efficient way. As many people said, there are quite a lot of people actively
 > involved in the work in both BBF and IETF. To start the work parallel in both BBF
 > and IETF can definitely speed up process...
 >
 > Best regards,
 > Mach
 >
 > > -----Original Message-----
 > > From: bcause [mailto:[email-masked]] On Behalf Of Loa
 > Andersson
 > > Sent: Tuesday, March 26, 2019 8:28 PM
 > > To: Martin Vigoureux
 > > Cc: [email-masked]
 > > Subject: [bcause] to wait or not to wait
 > >
 > > Martin,
 > >
 > > When you summarized the BoF you said that the you had the feeling in
 > the
 > > room was that we wait for BBF to complete their requirements.
 > >
 > > While, I think your evaluation might be right, I don't think that it should
 > stop us
 > > from doing some work in the mean time. I think that that was the feeling
 > that
 > > most people left the room.
 > >
 > > As things are, we have enough people participating in both BBF and IETF,
 > and
 > > that they well understand what should be done. We know the major part
 > of
 > > what the BBF requirents will, and it is enough to start working.
 > > And yes I understand that there might be late surprises, but we can
 > manage
 > > that.
 > >
 > > /Loa
 > >
 > > --
 > >
 > >
 > > Loa Andersson email: [email-masked]
 > > Senior MPLS Expert
 > > Bronze Dragon Consulting phone: +46 739 81 21 64
 > >
 > > --
 > > bcause mailing list
 > > [email-masked]
 > > https://www.ietf.org/mailman/listinfo/bcause
 >
 > --
 > bcause mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/bcause
 >

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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 Mar 2019 19:54:24 +0000

As mentioned we should stop this discussion, but we are going in circles. There is no need for multiple protocols here and we do the industry a disservice.
The mailing list has given info to the IETF community and we will be advised how to proceed. So let’s wait for IETF’s decision.

From: "[email-masked]" <[email-masked]>
Date: Wednesday, 27 March 2019 at 20:32
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re:[bcause] to wait or not to wait

Hi Wim,
I start to understand there might be solution with pfcp extension which is designed to address multi-access use cases by some vendors, this is really good news to the industry particularly the operators. so let me put them in a clear picture, there are two industry practices with trial protocol solution's, one is the pfcp extension you mentioned or suggested by some experts  in this list, the other is the practice from China Mobile which has been in the DBNG deployment for over three years 
with 150 millions fixed subscribers to migrate to DBNG, both could be standardized and either one adopted by the operator according to its use cases , I am deeply confused why we so strongly assume one is certainly better than other in a sense such that we put there enough evidence from market deployments. I don' t believe operator A'  choice 1 over 2 or operator B'  choice 2 over 1 proves unhealthy  when it comes to standard adoptions. 

BR Daniel H 

发自我的zMail

原始邮件
发件人：Henderickx,Wim(Nokia-BE/Antwerp)<[email-masked]>;
收件人：Greg Mirsky<[email-masked]>;
抄送人：[email-masked]<[email-masked]>;Mach Chen<[email-masked]>;Miaofuyou (Miao Fuyou)<[email-masked]>;Vigoureux,Martin (Nokia - FR/Paris-Saclay)<[email-masked]>;STARK,BARBARA H<[email-masked]>;Loa Andersson<[email-masked]>;
日期：2019-03-27 19:29:03
主题：Re: [bcause] to wait or not to wait
--
bcause mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bcause
There is nothing in the operational requirements you have listed that is not satisfied by PFCP and is even deployed in much more scalable environments.

From: Greg Mirsky <[email-masked]>
Date: Wednesday, 27 March 2019 at 19:13
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: Mach Chen <[email-masked]>, "Miaofuyou (Miao Fuyou)" <[email-masked]>, "STARK, BARBARA H" <[email-masked]>, Loa Andersson <[email-masked]>, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bcause] to wait or not to wait

Hi Wim,
I think you understand how different is operational consideration for an operator that has 150000000 subscribers comparing with an operator with, let's say, 1000000. I feel that, for some unexplainable reason, many dismiss the operational considerations of introducing a new protocol, PFCP in this case, compared with using the protocol that the operations already is familiar with, trained on.

Regards,
Greg

On Wed, Mar 27, 2019 at 6:11 PM Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:
If you want to develop a protocol for 1 operator you don’t need IETF for that.

On 27/03/2019, 15:49, "Mach Chen" <[email-masked]<mailto:[email-masked]>> wrote:

    Given that China Mobile's requirements are quite clear and focused, and they have asked IETF to develop a protocol to satisfy their requirements. I don't see any reason here (IETF) to reject Operator's requirements.

    Best regards,
    Mach

    > From: Miaofuyou (Miao Fuyou)
    > Sent: Wednesday, March 27, 2019 10:34 PM
    > To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; 'Henderickx, Wim (Nokia -
    > BE/Antwerp)' <[email-masked]<mailto:[email-masked]>>; Mach Chen
    > <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; Vigoureux, Martin
    > (Nokia - FR/Paris-Saclay) <[email-masked]<mailto:[email-masked]>>
    > Cc: [email-masked]<mailto:[email-masked]>
    > Subject: 答复: [bcause] to wait or not to wait
    >
    >
    > It's a fair question to be asked to the community.
    >
    > "So to me, the question is: Is there consensus in IETF to quickly develop a new
    > protocol intended to satisfy the use case presented by China Mobile (but
    > shared by numerous other operators), with no expectation of use case support
    > or extensibility beyond that?"
    >
    > - Miao
    >
    > -----邮件原件-----
    > 发件人: bcause [mailto:[email-masked]<mailto:[email-masked]>] 代表 STARK, BARBARA H
    > 发送时间: 2019年3月27日 20:02
    > 收件人: 'Henderickx, Wim (Nokia - BE/Antwerp)'
    > <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>; Loa
    > Andersson <[email-masked]<mailto:[email-masked]>>; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
    > <[email-masked]<mailto:[email-masked]>>
    > 抄送: [email-masked]<mailto:[email-masked]>
    > 主题: Re: [bcause] to wait or not to wait
    >
    > -- snip --
    > > 2. Your work is missing use cases which many operators have expressed
    > > to be required on the mailing list. So you have an incomplete scope
    > > and BBF incorporated them.
    > -- snip --
    >
    > and
    >
    > > From: David Fan <[email-masked]<mailto:[email-masked]>>
    > -- snip --
    > > The problem is do we(IETF) need to wait for more requirement beyond BNG.
    > -- snip --
    >
    > I agree with David here. The fact that other use cases (beyond the one
    > presented by China Mobile -- but which is not unique to China Mobile) exist is
    > certainly important information for individuals forming opinions in IETF. But,
    > from what I can see, there is not agreement on a constraint of "if IETF does
    > something it must do something that handles all use cases". And trying to push
    > that as the primary question is muddying the waters, IMO.
    >
    > The CUSP proposal does not handle all use cases. I think no-one disagrees with
    > that.
    > It's goal is to handle the use case presented by China Mobile.
    >
    > So to me, the question is: Is there consensus in IETF to quickly develop a new
    > protocol intended to satisfy the use case presented by China Mobile (but
    > shared by numerous other operators), with no expectation of use case support
    > or extensibility beyond that?
    >
    > If the answer is yes, then go ahead and do it and get started.
    > If the answer is no, then the proponents of CUSP can start now to figure out
    > where they go from here.
    >
    > It really shouldn't take that long to get an answer to this question. I'm pretty
    > sure everyone on this list feels like they have the information needed to provide
    > an educated hummed opinion on it.
    >
    > Other operators (with different use cases) are not asking for IETF to produce a
    > new, extensible protocol to meet all use cases. These operators aren't asking
    > for IETF to participate in extending PFCP. The lack of different-use-case
    > operators speaking up during/after the BoF (and their lack of willingness to
    > provide details on their use cases on the list) may be a good indicator of just
    > how interested other operators' BNG experts would be in such an effort.
    >
    > And in case anyone is confused... the BoF is over and I am not a chair of
    > anything in Routing Area. Nor am I in the IESG or a holder of any other official
    > position potentially influential to such a decision.
    > Barbara
    >
    > --
    > bcause mailing list
    > [email-masked]<mailto:[email-masked]>

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

---

From: qinfengwei<[email-masked]>
Date: 28 Mar 2019 17:00:53 +0800

Hi Sanjay and all,

we have analysed the feasibility used PFCP in DBNG for almost half a year with 3GPP team, of course, your colleage Miao has been involved in the discussion. 

PFCP is designed specifically for the wireless, there are lots of gaps between wireless and fixed-network, for example PPPoE, L2TP, Route information, detect result , Nat management and so on. Please get analysis result as the following figure, most BNG attributes need be newly defined in PFCP, and as we all know, there is not communication between different manufactures in wireless network, that means there needs a huge amount of work if PFCP is used to support BNG's function. But we have done lots of work on CUSP, and perform lab interoperation test in July 2019. For the massive deployment in 2020, we need the more professional team (such as IETF) to formulate and perfect the standard.  

发件人: Wadhwa, Sanjay (Nokia - US/Mountain View)

时间: 2019/03/28(星期四)15:26

收件人: Chase, Chris;STARK, BARBARA H;Henderickx, Wim (Nokia - BE/Antwerp);Mach Chen;Loa Andersson;Vigoureux, Martin (Nokia - FR/Paris-Saclay);

抄送人: bcause;

主题: Re: [bcause] to wait or not to waitAgreed. It will be to the benefit of both vendors and operators if a single protocol is defined for BNG CUPS irrespective of access. PFCP is the de-facto standard protocol between SMF/UPF today. It is hard to see why PFCP should not be used for BNG CUPS irrespective of the access over which the residential services are delivered (fixed, fixed-wireless, or hybrid). BBF has a stated goal of considering PFCP for AGF CUPS, which together with SMF/UPF functionally mimics a BNG.

-Sanjay

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Chase, Chris
Sent: Wednesday, March 27, 2019 6:48 AM
To: STARK, BARBARA H <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
Subject: Re: [bcause] to wait or not to wait

 AT&amp;T has fixed wireless today on sub 6 providing residential broadband service in rural areas.  We are looking at deploying fixed wireless with 5G mmwave option 3x next year.  For this later effort we are considering a BNG that speaks S11/S1u solution.  Because we will have both our existing wireline IPoE BNG solution and this fixed wireless service there is a strong desire that we evolve to a converged BNG CU+UP solution that is common for instantiation, policy, and charging.

To me it seems an inefficient use of resources and confusion in architecting solutions in the market place to have two solutions - one being pushed by BBF that covers BNG for both wireline and wireless use cases and another using a different protocol that only covers a subcase of that.  Vendors will be compelled to support both, probably inadequately or more expensively.

Chris Chase

> From: bcause [mailto:[email-masked]] On Behalf Of STARK, 
> BARBARA H
> Sent: Wednesday, March 27, 2019 7:02 AM
> To: 'Henderickx, Wim (Nokia - BE/Antwerp)' <[email-masked]>; 
> Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; 
> <[email-masked]>
> Cc: [email-masked]
> *** Security Advisory: This Message Originated Outside of AT&amp;T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> > 2. Your work is missing use cases which many operators have 
> > expressed to be required on the mailing list. So you have an 
> > incomplete scope and BBF incorporated them.
> -- snip --
> 
> and
> 
> > From: David Fan <[email-masked]>
> -- snip --
> presented by China Mobile -- but which is not unique to China Mobile) 
> exist is certainly important information for individuals forming 
> opinions in IETF. But, from what I can see, there is not agreement on 
> a constraint of "if IETF does something it must do something that 
> handles all use cases". And trying to push that as the primary question is muddying the waters, IMO.
> 
> The CUSP proposal does not handle all use cases. I think no-one 
> disagrees with that.
> So to me, the question is: Is there consensus in IETF to quickly 
> develop a new protocol intended to satisfy the use case presented by 
> China Mobile (but shared by numerous other operators), with no 
> expectation of use case support or extensibility beyond that?
> 
> If the answer is no, then the proponents of CUSP can start now to 
> figure out where they go from here.
> 
> It really shouldn't take that long to get an answer to this question. 
> I'm pretty sure everyone on this list feels like they have the 
> information needed to provide an educated hummed opinion on it.
> 
> Other operators (with different use cases) are not asking for IETF to 
> produce a new, extensible protocol to meet all use cases. These 
> operators aren't asking for IETF to participate in extending PFCP. The 
> lack of different-use-case operators speaking up during/after the BoF 
> (and their lack of willingness to provide details on their use cases 
> on the list) may be a good indicator of just how interested other operators' BNG experts would be in such an effort.
> 
> And in case anyone is confused... the BoF is over and I am not a chair 
> of anything in Routing Area. Nor am I in the IESG or a holder of any 
> other official position potentially influential to such a decision.
> Barbara
> 
> --
> bcause mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bcause&amp;d=DwICAg&amp;c=LFYZ-
> o9_HUMeMTSQicvjIg&amp;r=FW70RKF5w5SM1Lm0CwnNEw&amp;m=uJSLopx6mvTSt59z
> xAgEMmuaNaL8MIdRQ3ihRA8kuOY&amp;s=GQ9S3twMIX7ctY1W4SOhcjWGeBKIkM
> ddYBm4bdek4GU&amp;e=

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Thu, 28 Mar 2019 09:25:54 +0000

> your colleage Miao has been involved in the discussion

Not me, maybe someone else from Nokia with the same name...
发件人：qinfengwei <[email-masked]>
收件人：Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>;Chase, Chris <[email-masked]>;STARK, BARBARA H <[email-masked]>;Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>;Mach Chen <[email-masked]>;Loa Andersson <[email-masked]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
抄 送：bcause <[email-masked]>
时间：2019-03-28 10:02:01
主 题：Re: [bcause] to wait or not to wait

Hi Sanjay and all,

发件人: Wadhwa, Sanjay (Nokia - US/Mountain View)<mailto:[email-masked]>
时间: 2019/03/28(星期四)15:26
收件人: Chase, Chris<mailto:[email-masked]>;STARK, BARBARA H<mailto:[email-masked]>;Henderickx, Wim (Nokia - BE/Antwerp)<mailto:[email-masked]>;Mach Chen<mailto:[email-masked]>;Loa Andersson<mailto:[email-masked]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay)<mailto:[email-masked]>;
抄送人: bcause<mailto:[email-masked]>;
主题: Re: [bcause] to wait or not to wait
Agreed. It will be to the benefit of both vendors and operators if a single protocol is defined for BNG CUPS irrespective of access. PFCP is the de-facto standard protocol between SMF/UPF today. It is hard to see why PFCP should not be used for BNG CUPS irrespective of the access over which the residential services are delivered (fixed, fixed-wireless, or hybrid). BBF has a stated goal of considering PFCP for AGF CUPS, which together with SMF/UPF functionally mimics a BNG.

-Sanjay

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Chase, Chris
Sent: Wednesday, March 27, 2019 6:48 AM
To: STARK, BARBARA H <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
Subject: Re: [bcause] to wait or not to wait

AT&T has fixed wireless today on sub 6 providing residential broadband service in rural areas. We are looking at deploying fixed wireless with 5G mmwave option 3x next year. For this later effort we are considering a BNG that speaks S11/S1u solution. Because we will have both our existing wireline IPoE BNG solution and this fixed wireless service there is a strong desire that we evolve to a converged BNG CU+UP solution that is common for instantiation, policy, and charging.

Chris Chase

> *** Security Advisory: This Message Originated Outside of AT&T ***.
> 3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=FW70RKF5w5SM1Lm0CwnNEw&m=uJSLopx6mvTSt59z
> xAgEMmuaNaL8MIdRQ3ihRA8kuOY&s=GQ9S3twMIX7ctY1W4SOhcjWGeBKIkM
> ddYBm4bdek4GU&e=

---

From: David Fan <[email-masked]>
Date: Thu, 28 Mar 2019 17:57:29 +0000

Hi All

I found we are talking about implementation about CUSP. And I think requirement is clear and this work IETF can do, but we have different thinking about detail solution.
My suggestion is why not set up a task force to discuss and include more people. By the way, after that presentation at BoF, some people have interesting at that use case (deployment model) and talk lot.
And AT&T 5G mmwave option 3x can also discuss as Phase II requirements.
Need more classification (Does the mmwave RG has wireless and fixed line at same time(BBF is working on Bridge-RG), Traffic will go to 5G Core or Offload, BNG and 5G Core will NFV or Router Based, …)

FMC is many people’s dream , as dream to unify ISIS and OSPF. But Fixed industry and Mobile Industry really have lots of different.
To Forrest Gump, Jenny is his only choice and after more than 20 years, Jenny find it is truth. but in real world , most people choose no wait, maybe they need more time to find the loveliness of each other.

Repeat : why not put a table, let more people join in to discuss, if we did not have this table, maybe only us send mail every day and no contribution.

David.Fan

发件人: bcause [mailto:[email-masked]] 代表 Wadhwa, Sanjay (Nokia - US/Mountain View)
发送时间: 2019年3月28日 19:06
收件人: qinfengwei <[email-masked]>; Chase, Chris <[email-masked]>; STARK, BARBARA H <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
抄送: bcause <[email-masked]>
主题: Re: [bcause] to wait or not to wait

Hi Fengwei
We have a working implementation of PFCP with extensions for some of the common encapsulations on BNG. Based on implementation experience and also detailed analysis of other relevant encapsulations, let me say what you perceive and show below is rather naïve and misleading. PFCP uses well defined set of flexible match rules and actions to define forwarding state and processing on the UP, rather than dumping fixed format tables. These rules for BNG related applications either use existing IEs for specifying encaps/decaps or have trivial extension to existing IEs or define new IEs. The whole protocol machinery, messaging and containers that convey the state is used as is. Not to mention the overload handling, liveness detection, usage tracking, actions for mirroring, steering etc that is part of the base protocol. It takes a while to get all this right in a new protocol that is designed from scratch.
The state info that you need to pass to the UP does not depend on the protocol used but rather access and core facing interface encapsulations. So, this is same for any protocol that you will implement.
Just as a parallel, on a BNG we easily have over hundred RADIUS VSAs and DIAMETER AVPs (for applications such as NASREQ, Gx, Gy), which are added or extended incrementally as you add features. It is flawed thinking if you believe this is where the complexity lies. It is the underlying protocol that is the key. Adding support to specify new encapsulations in PFCP or new data-path actions (e.g. NAT) is incremental and rather straightforward. PFCP IEs allow vendor specific extensions where vendor can be an SDO. Capabilities aside, PFCP is very conscious about minimizing chattiness and round trips needed to create subscriber sessions, which is critical. Unfortunately, unlike PFCP , the alternatives (including one you endorse) are not optimized.

On inter-op, all I can say is that the base PFCP protocol is deployed in production in some of the largest packet core networks out there. Multiple vendors support it. Hardening is based on full scale deployments rather than limited trials/POCs. Given your scale requirement, you will likely be better off with a base protocol that has its design vetted by large deployments.
I am happy to discuss details with you to clear obvious misperceptions on PFCP. Please feel free to reach out per your convenience.

Thanks
-Sanjay

From: qinfengwei <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 28, 2019 2:01 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Chase, Chris <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]<mailto:[email-masked]>>
Cc: bcause <[email-masked]<mailto:[email-masked]>>
Subject: Re: Re: [bcause] to wait or not to wait

Hi Sanjay and all,

-Sanjay

-----Original Message-----
From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Chase, Chris
Sent: Wednesday, March 27, 2019 6:48 AM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bcause] to wait or not to wait

Chris Chase

> To: 'Henderickx, Wim (Nokia - BE/Antwerp)' <[email-masked]<mailto:[email-masked]>>;
> Mach Chen <[email-masked]<mailto:[email-masked]>>; Loa Andersson <[email-masked]<mailto:[email-masked]>>;