Subject: [bcause] to wait or not to wait

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Mar 2019 13:28:19 +0100

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

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Tue, 26 Mar 2019 15:16:44 +0000

Hi,

The key issue is whether IETF, as a protocols definition organization, should rely on other SDO to kick off protocols work.

IETF has a long history to define protocols for BNG, much longer than BBF. And, no one protocol development in IETF had needed input from BBF, not to say put it on critical path. PPPoE had not. Radius had not. DHCP had not, too.

For CU separation, the same applies. Actually the protocols may depend much more on other IETF protocols, such as PPPoE, rather than a BBF project.

- Miao
发件人：Loa Andersson <[email-masked]>
收件人：Martin Vigoureux <[email-masked]>
抄 送：[email-masked] <[email-masked]>
时间：2019-03-26 13:29:03
主 题：[bcause] to wait or not to wait

Martin,

/Loa

--

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

---

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

Miao

An SDO version of “eminent domain” does not really apply here.  I would respectfully suggest you have misidentified any issue associated with this.

The IETF did not define protocols for BNGs, didn’t even know how to spell BNG.   BBF BNG specification referenced IETF protocols, and where necessary, has extended them. The BBF is where the services platform known  as a BNG has been defined and refined for a very long time and hence is where the domain knowledge resides. (FYI,  PPPoE (RFC 2516) was an individual submission from UUnet. Not an IETF standards track product. I was in the room when that screaming match occurred at IETF 42 as were several others who were at this BOF. The BBF subsequently extended it when they did TR-101.)

Given the cornucopia of possible protocols that could be applied to CUPS, protocol SPECIFICATION (the part IETF is really good at) is not the actual problem that needs to be solved IMO.

Cheers

Dave

From: bcause <[email-masked]> On Behalf Of Miaofuyou (Miao Fuyou)
Sent: Tuesday, March 26, 2019 4:17 PM
To: Loa Andersson <[email-masked]>; Martin Vigoureux <[email-masked]>
Cc: [email-masked]
Subject: [bcause] IETF to rely on BBF?

Hi,

- Miao

发件人：Loa Andersson <[email-masked] <mailto:[email-masked]> >

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

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

时间：2019-03-26 13:29:03

Martin,

/Loa

-- 

Loa Andersson                        email: [email-masked] <mailto:[email-masked]> 
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Mar 2019 17:02:06 +0100

I did not hear anything resembling a rough consensu (even among those in 
the room and choosing to speak) for doing any specific work in the IETF. 
  I did hear some people wanting to do so.

Yours,
Joel

---

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

Hi Dave,

When we talk about BNG, I mean a certain kind of  gateway, rather just the acronym. What happen if we use other acronym, such as BRAS? With that in mind, I am surprised that you said IETF didn't define protocols for BNG.

Spec of BNG as a network element or function for IP network was defined in BBF for sure. It's good and useful to the industry. The case with network element / function definition in SDO is different. Actually it is more a confirmation to what already existed in network, to build a consistent understanding across the industry, rather than designing something new. I do agree expertise is needed to define it, while it does not mean other organization lacks such expertise, even some organization, for example IETF, has more such expertise, considering protocols of BNG in IETF and participation base.

Miao
发件人：David Allan I <[email-masked]>
收件人：Miaofuyou (Miao Fuyou) <[email-masked]>;Loa Andersson <[email-masked]>;Martin Vigoureux <[email-masked]>
抄 送：[email-masked] <[email-masked]>
时间：2019-03-26 16:41:57
主 题：RE: IETF to rely on BBF?

Miao

Cheers
Dave

Hi,

- Miao
发件人：Loa Andersson <[email-masked]<mailto:[email-masked]>>
收件人：Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-26 13:29:03
主 题：[bcause] to wait or not to wait

Martin,

/Loa

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

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

---

From: Mach Chen <[email-masked]>
Date: Tue, 26 Mar 2019 16:43:34 +0000

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 <[email-masked]>
> 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
> 
> --
> 
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 26 Mar 2019 16:44:39 +0000

<bhs> Calling PPPoE an “IETF protocol” just because the IESG agreed to publish it as an Informational RFC (no WG worked on it) is an interesting characterization of PPPoE.
Barbara

---

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

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Loa and all,

    

    Best regards,
    Mach

---

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

We need to focus on speeding BBF. That is who defines requirements and we, as IETF, shall respect that. Some key requirements may move solution into a clear solution standardization path.

In the meantime, if some want to document - as informational - what at this point is a proprietary/limited deployment implementation - there is nothing wrong with that.

Once requirements are done the above work can be evaluated for applicability and value to decide whether it is applicable or becomes a one-off proprietary solution that we may have an informational draft on.

Regards,
Andrew
Sent from my iPhone Outlook<https://aka.ms/qtex0l>

________________________________
From: bcause <[email-masked]> on behalf of Mach Chen <[email-masked]>
Sent: Wednesday, March 27, 2019 12:43 AM
To: Loa Andersson; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Cc: [email-masked]
Subject: Re: [bcause] to wait or not to wait

Hi Loa and all,

Best regards,
Mach

---

From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Tue, 26 Mar 2019 17:36:25 +0000

Loa,

I don't think we should wait in the sense that each person concerned by this topic should focus his/her efforts to contributing to the requirements activity in bbf such that not only their view is considered but also the associated document progresses fast.

-m

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: Tuesday, March 26, 2019 13:28
To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
Subject: 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

--

---

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

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

> From: Henderickx, Wim (Nokia - BE/Antwerp)
> [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2019 12:53 AM
> To: Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>;
> Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
> Cc: [email-masked]
> 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"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     Hi Loa and all,
> 
>     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
> 
> the
> and
> manage

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 Mar 2019 07:30:15 +0100

Martin,

This strategy makes sense only if we expect that there will be work to
do in the area for IETF, right?

If the expectation is that there will be no work for us, then this 
becomes an BBF activity and we should not recommend anything.

If we expect there to be work for us, why should we not spend the time
until we have the BBF requirements preparing for doing the job? 
Especially since we have expertise in the area and pretty well know in
which direction the BBF requirements will go.

/Loa

--

---

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

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" <[email-masked]> wrote:

    Hi Wim,

    
    Best regards,
    Mach

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 27 Mar 2019 09:26:04 +0000

Following the waterfall model and serializing things so that no step can start until the previous one finishes is the recipe for slowing things down.

I think there is at least as much to be learned from continuing trial deployments as from paper requirements exercises.

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

-----Original Message-----
From: bcause [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Wednesday, March 27, 2019 2:38 AM
To: 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

    Hi Wim,

    
    Best regards,
    Mach

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 27 Mar 2019 12:01:38 +0000

> From: Henderickx, Wim (Nokia - BE/Antwerp)
-- 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]>
-- snip --
> 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.
-- 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

---

From: "Chase, Chris" <[email-masked]>
Date: Wed, 27 Mar 2019 13:48:13 +0000

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.

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]>;
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> 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.
> 
> 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?
> 
> 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&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=FW70RKF5w5SM1Lm0CwnNEw&m=uJSLopx6mvTSt59z
> xAgEMmuaNaL8MIdRQ3ihRA8kuOY&s=GQ9S3twMIX7ctY1W4SOhcjWGeBKIkM
> ddYBm4bdek4GU&e=

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Wed, 27 Mar 2019 14:22:13 +0000

Hi Chris, 

Where is the document saying " one being pushed by BBF that covers BNG for both wireline and wireless use cases "? 

There are a couple of misunderstandings within it. First, BBF has not make any decision on BNG protocol selection. Second, there is not any document to say that AGF (BNG for wireless use case in your message) is BNG. You could develop an AGF based on BNG, you could also develop based on other platforms, such as UPF, router, and even switch. Vendor makes such choice, SDO does not. Third, there is no decision within BBF that AGF will use PFCP as the CU protocol. 

- Miao

-----邮件原件-----
发件人: bcause [mailto:[email-masked]] 代表 Chase, Chris
发送时间: 2019年3月27日 21:48
收件人: 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]>
抄送: [email-masked]
主题: Re: [bcause] to wait or not to wait

Chris Chase

> From: bcause [mailto:[email-masked]] On Behalf Of STARK, 
> BARBARA H
> > 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
> 
> > I think China Mobile Requirements is quite clear, Do you agree? I 
> > cover the BNG requirements.
> 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.
> 
> 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?
> 
> 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]

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Wed, 27 Mar 2019 14:34:19 +0000

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]] 代表 STARK, BARBARA H
发送时间: 2019年3月27日 20:02
收件人: 'Henderickx, Wim (Nokia - BE/Antwerp)' <[email-masked]>; Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
抄送: [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

-- snip --
-- snip --

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Mar 2019 15:45:23 +0100

I have still seen no evidence that a new protocol is needed.  As such, 
no, I do not support the IETF (or anyone) going off to quickly design 
yet another new protocol for some ill-defined aspect of BNG management.

To the degree that folks want to address the need for control of the BNG 
quickly, it seems to me far more effective to build on the ongoing work 
in the BBF.

As a final point, the only way I know to actually finish the work really 
fast is to assume that one knows the answer going in, and not review or 
discuss it.  Chartering a working group to rubber stamp an existing 
protocol is not the spirit of the IETF process.  Even in cases where the 
external work has been produced by multiple collaborators, we still try 
to treat new input fairly.  And that takes time.

Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 Mar 2019 14:49:11 +0000

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]>; '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: 答复: [bcause] to wait or not to wait
> 
> 
> "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
> 
> -----邮件原件-----
> 收件人: 'Henderickx, Wim (Nokia - BE/Antwerp)'
> <[email-masked]>; Mach Chen <[email-masked]>; Loa
> Andersson <[email-masked]>; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[email-masked]>
> 抄送: [email-masked]
> 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?
>

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 27 Mar 2019 14:56:08 +0000

Nothing stops one from experimenting. Your initial drafts proposed OpenFlow for state exchange. Now it is something completely different. This kind of churn is likely to happen when there is lack of detailed requirements and discussion. I think everyone understands the urgency to solve what carriers have asked for, and are willing to contribute. However, we will be faster to the market if we can design a consistent solution based on agreed upon architecture and requirements. For all the BNG related work, BBF has typically produced excellent documents covering architecture and requirements, which are almost always referenced in BNG RFPs from carriers. Doing this with BBF involvement will only help. 
Just an observation, even though all the IETF drafts have been in RTG-WG for some time, there have been hardly any comments on technical content. I hope it tells us something. 

-Sanjay

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Donald Eastlake
Sent: Wednesday, March 27, 2019 2:26 AM
To: [email-masked]
Subject: Re: [bcause] to wait or not to wait

Thanks,
Donald

-----Original Message-----
From: bcause [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Wednesday, March 27, 2019 2:38 AM
To: 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

    Hi Wim,

    
    Best regards,
    Mach

---

From: David Allan I <[email-masked]>
Date: Wed, 27 Mar 2019 14:59:22 +0000

Mach

The whole purpose of standardization from a vendor's point of view, is to maximize the addressable market for one's products.

I'll leave that thought there...

Dave

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Mach Chen
Sent: Wednesday, March 27, 2019 3:49 PM
To: Miaofuyou (Miao Fuyou) <[email-masked]>; STARK, BARBARA H <[email-masked]>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[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

Best regards,
Mach

> "So to me, the question is: Is there consensus in IETF to quickly 
> expectation of use case support or extensibility beyond that?"
> 
> - Miao
> 
> -----邮件原件-----

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 Mar 2019 16:15:23 +0100

Hi Miao,
I'd take the opportunity to note (I don't argue with you but to clarify the
characterization of the FN-BNG CUPS status, that the CUSP proposal is much
further specified than something that may be referred to as "develop the
new protocol". Indeed, updates, clarifications, and extensions might be
necessary, but the authors of CUSP have already done lots of work.

Best regards,
Greg

On Wed, Mar 27, 2019 at 3:34 PM Miaofuyou (Miao Fuyou) <
[email-masked]> wrote:

> "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
>
> -----邮件原件-----
> 收件人: 'Henderickx, Wim (Nokia - BE/Antwerp)' <[email-masked]>;
> Mach Chen <[email-masked]>; Loa Andersson <[email-masked]>; Vigoureux,
> Martin (Nokia - FR/Paris-Saclay) <[email-masked]>
> 抄送: [email-masked]
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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]

---

From: Liang GENG <[email-masked]>
Date: Wed, 27 Mar 2019 15:20:18 +0000

Sorry to jump in the queue David.

I think what you stated is pointing a gun on half(maybe more) of the published RFCs.

Even an unified solution for all use cases exists sometime - it is very likely to be too complicated or expensive - Network is diversified geographically and technically. Controlled convergence is better than absolute convergence in term of solution options.

Isn't it a tradition in IETF to encourage diversified solutions? Since when it became a trade market?

Liang

________________________________
From: bcause <[email-masked]> on behalf of David Allan I <[email-masked]>
Sent: 27 March 2019 22:59
To: Mach Chen; Miaofuyou (Miao Fuyou); STARK, BARBARA H; 'Henderickx, Wim (Nokia - BE/Antwerp)'; Loa Andersson; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Cc: [email-masked]
Subject: Re: [bcause] to wait or not to wait

Mach

Dave

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Mach Chen
Sent: Wednesday, March 27, 2019 3:49 PM
To: Miaofuyou (Miao Fuyou) <[email-masked]>; STARK, BARBARA H <[email-masked]>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[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

Best regards,
Mach

---

From: <[email-masked]>
Date: Wed, 27 Mar 2019 23:35:27 +0800 (CST)

some posts in this list after the bof seem to address the one protocol solution for all use cases rather than waiting for BBF to make the final requirements by the end of Q3 as why we stop here, I would like to make 2 points as following:
1, the fixed-only use case is an important one which is in the scope of BBF WT459 to be specified, and this use case has been discussed and adopted upon a few editorial changes in the BBF meeting last week in Warsaw, I am one of the authors of the contribution. it is going to remain what it is now as it will be shown to IETF by BBF by Q3.

2, again, one size fits all is fantastic, but it depends on the real business reasoning, and it is also not the usual real industry practices. the fixed-only BNG CUSP requirements are clear of any further identifications, not to mention 5 months. it does not make any sense for the industry with fixed-only DBNG requirements to wait for the undefined solution to be defined from a wireless-born solution to address its problems when we have good chance to do and handle it now without any uncertainty. we do not have to go through liaisons and frequent coordinations with any other SDOs for approval such as 3gpp. we can do it and make it happen right now.

BR Daniel Huang

发自我的zMail

原始邮件

发件人：DavidAllanI<[email-masked]>;
收件人：Mach Chen<[email-masked]>;Miaofuyou (Miao Fuyou)<[email-masked]>;STARK, BARBARA H<[email-masked]>;'Henderickx,Wim (Nokia - BE/Antwerp)'<[email-masked]>;Loa Andersson<[email-masked]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay)<[email-masked]>;
抄送人：[email-masked]<[email-masked]>;
日期：2019-03-27 15:59:40
主题：Re: [bcause] to wait or not to wait

Mach

Dave

-----Original Message-----
From: bcause <[email-masked]> On Behalf Of Mach Chen
Sent: Wednesday, March 27, 2019 3:49 PM
To: Miaofuyou (Miao Fuyou) <[email-masked]>; STARK, BARBARA H <[email-masked]>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[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

Best regards,
Mach

---

From: Gregory Dalle <[email-masked]>
Date: Wed, 27 Mar 2019 15:39:52 +0000

Please, nobody is pointing guns 😉 and it is not productive to have divisive rhetoric between SDOs, we all trying to come to progress together. I assume China Mobile is not interested only in getting a rubber stamp on CUSP, but also hopes that there will be an ecosystem of operators and vendors who use the same CUPS BNG approach. If that’s the case, the little extra time you will spend with other operators making sure their needs are also covered, will bear very positive returns.

Greg

From: bcause <[email-masked]> On Behalf Of Liang GENG
Sent: Wednesday, March 27, 2019 11:20 AM
To: David Allan I <[email-masked]>; Mach Chen <[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]>; STARK, BARBARA H <[email-masked]>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[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

Liang

________________________________
From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of David Allan I <[email-masked]<mailto:[email-masked]>>
Sent: 27 March 2019 22:59
To: Mach Chen; Miaofuyou (Miao Fuyou); STARK, BARBARA H; 'Henderickx, Wim (Nokia - BE/Antwerp)'; Loa Andersson; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bcause] to wait or not to wait

Mach

Dave

-----Original Message-----
From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Wednesday, March 27, 2019 3:49 PM
To: Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[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

Best regards,
Mach

> 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]>
> <[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]>
> > From: David Fan <[email-masked]<mailto:[email-masked]>>
> -- snip --
> https://www.ietf.org/mailman/listinfo/bcause<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=XcyS9IQjx-ER2kTzVWv7HiRavZgzL4Spoj8I5J-BTRg&s=Ox6ib9h_MVOyvpeklI9tiR77Z5HuITjWYhrizdiik1c&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=DwMFoQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=XcyS9IQjx-ER2kTzVWv7HiRavZgzL4Spoj8I5J-BTRg&s=Ox6ib9h_MVOyvpeklI9tiR77Z5HuITjWYhrizdiik1c&e=>

---

From: Gregory Dalle <[email-masked]>
Date: Wed, 27 Mar 2019 16:15:08 +0000

Daniel,

We are going full circle here. You make the assumption that there is such thing as a “fixed-only” BNG (aka vanilla BNG, basic BNG, etc) versus a “rest of the world BNG” (aka “integrated BNG”) and that it justifies an entirely different CUPS approach for the “basic BNG” and the “integrated BNG”. So what is “basic” vs “integrated”?
If I do my policies based on PCRF, it is  an integrated BNG?
If I do my accounting based on Gy, is it an integrated BNG?
If I use L7 traffic detection, is it an integrated BNG?
If I aggregate connected cars on my LNS, is it an integrated BNG?
If my RG has a community WiFi SSID, is it an integrated BNG?
If I do fixed wireless, is it an integrated BNG?
And the list goes on. And I assume we have different views on this. We already got the operators feedback on this mailing list that imposing a complete CUPS change when going from basic BNG to integrated BNG (or call it bronze BNG to silver BNG or whatever names you like) is not the right approach. Why do you want to ignore this feedback?

PS: your characterization of BBF work on WT-459 as it is going to be your contribution from last week + editorial changes + 5 months, is a misunderstanding on your side. Else we would just take draft-cuspdt-rtgwg-cu-separation-bng-deployment and call it WT-459.

Greg

From: bcause <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, March 27, 2019 11:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bcause] to wait or not to wait

BR Daniel Huang

发自我的zMail

原始邮件
发件人：DavidAllanI<[email-masked]<mailto:[email-masked]>>;
收件人：Mach Chen<[email-masked]<mailto:[email-masked]>>;Miaofuyou (Miao Fuyou)<[email-masked]<mailto:[email-masked]>>;STARK, BARBARA H<[email-masked]<mailto:[email-masked]>>;'Henderickx,Wim (Nokia - BE/Antwerp)'<[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]<[email-masked]<mailto:[email-masked][email-masked]>>;
日期：2019-03-27 15:59:40
主题：Re: [bcause] to wait or not to wait
Mach

Dave

-----Original Message-----
From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Wednesday, March 27, 2019 3:49 PM
To: Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[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

Best regards,
Mach

---

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

Not if the same people are involved since people so far can do 1 thing at the time. So having them work on 1 thing is better than having them work in parallel on the same thing. 
On top when working on the same thing in parallel you need to coordinate and consolidate which is making things worse.
All interested parties are part of BBF and this is where the expertise is and where we should unite. Again please provide an IETF definition of a BNG, which will show you this is not an environment IETF worked on in the past. IETF has done pieces, but when you talk about a BNG as a whole I have yet to see this from an IETF pov.

On 27/03/2019, 10:26, "bcause on behalf of Donald Eastlake" <[email-masked] on behalf of [email-masked]> wrote:

    
    Thanks,
    Donald
    
    -----Original Message-----
    From: bcause [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
    Sent: Wednesday, March 27, 2019 2:38 AM
    To: 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

    
        Hi Wim,

        
        Best regards,
        Mach

---

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

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]> wrote:

    Best regards,
    Mach

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 Mar 2019 17:57:18 +0000

How can you say it's just one operator's requirement? Don't you think they are representive of this kind of operators with the similar requirements?

Best regards,
Mach
发件人：Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
收件人：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]>
时间：2019-03-27 18:11:32
主 题：Re: [bcause] to wait or not to wait

    Best regards,
    Mach

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 Mar 2019 19:13:37 +0100

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]> 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
>
> develop a new
> expressed
>     > The CUSP proposal does not handle all use cases. I think no-one
> disagrees with
>     > that.
> develop a new
>     > If the answer is no, then the proponents of CUSP can start now to
> figure out
>     > where they go from here.
>     >

---

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

You said it yourself.

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

Best regards,
Mach

    Best regards,
    Mach

---

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

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:

    Best regards,
    Mach

    > 发件人: bcause [mailto:[email-masked]<mailto:[email-masked]>] 代表 STARK, BARBARA H
    > 发送时间: 2019年3月27日 20:02

---

From: <[email-masked]>
Date: Thu, 28 Mar 2019 03:32:29 +0800 (CST)

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

 

 

 
 
Hi Wim, 

 

 
Regards,

Greg

 
On Wed, Mar 27, 2019 at 6:11 PM Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> wrote:

 

     Best regards,
     Mach

---

From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 28 Mar 2019 07:26:47 +0000

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

Chris Chase

> disagrees with that.
> figure out where they go from here.
>

---

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

Hi Sanjay,

How long time do you predict to get PFCP for BNG protocol released, and by which SDO? Are you aware how long time it takes for a liaison (again, between/among which SDOes?), just to get a consistent understanding for a paragraph of text between two SDOes?

It's not only about how to design CU separation feature in product, it's also about interoperability as required by operators. You have to take account of the standardization process into consideration, in the same time, to think how to meet the immediate requirement of operators, as CUSP is trying to address.

Miao
发件人：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]>
抄 送：[email-masked] <[email-masked]>
时间：2019-03-28 08:27:31
主 题：Re: [bcause] to wait or not to wait

-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

Chris Chase

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Mar 2019 10:38:25 +0100

Greg, are you really claiming that the IETF should standardize a 
proprietary protocol (for a problem for which there are multiple 
standard protocols) because a major operator has experience with that 
proprietary protocol?

Yours,
Joel

On 3/27/19 7:13 PM, Greg Mirsky wrote:
> 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:
> 
>          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
> 
>          > -----Original Message-----
>          > 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
>          >
>          > > From: Henderickx, Wim (Nokia - BE/Antwerp)
>          > -- 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 --
>          > > 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.
>          > -- 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]>
>          > https://www.ietf.org/mailman/listinfo/bcause
> 
> 
>     -- 
>     bcause mailing list

---

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

Hi Joel,
thank you for your question. How many of these standard protocols had been
deployed at a scale comparable to what has been presented by China Mobile
at the BoF? And, at some time, people referred to VXLAN as "proprietary
protocol". Thus, I'm not looking at the label on the box but what in the
box. Would you agree?

Regards,
Greg

On Thu, Mar 28, 2019 at 10:38 AM Joel M. Halpern <[email-masked]>
wrote:

> >          > To: STARK, BARBARA H <[email-masked]
> >          > BE/Antwerp)' <[email-masked]
> >          > <[email-masked] <mailto:[email-masked]>>; Loa
> >          > Cc: [email-masked] <mailto:[email-masked]>
> >          > 发件人: bcause [mailto:[email-masked]
> >          > <[email-masked] <mailto:[email-masked]>>;
> >          > <[email-masked] <mailto:
> [email-masked]>>
> >          > 抄送: [email-masked] <mailto:[email-masked]>
> >          > 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.
> >          > If the answer is no, then the proponents of CUSP can start
> >     now to figure out
> >          > where they go from here.
> >          >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Mar 2019 10:48:11 +0100

No, I would not agree.
What is being requested in terms of keeping the protocol the same as the 
one China Mobile has experience with is to have the IETF rubber-stamp a 
vendor protocol.  Even in the days when Cisco completely dominated the 
router market, we tried very ahrd not to do that.

Yours,
Joel

On 3/28/19 10:45 AM, Greg Mirsky wrote:
> Hi Joel,
> thank you for your question. How many of these standard protocols had 
> been deployed at a scale comparable to what has been presented by China 
> Mobile at the BoF? And, at some time, people referred to VXLAN as 
> "proprietary protocol". Thus, I'm not looking at the label on the box 
> but what in the box. Would you agree?
> 
> Regards,
> Greg
> 
> On Thu, Mar 28, 2019 at 10:38 AM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[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]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     'Henderickx, Wim (Nokia -
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Mach Chen
>      >          > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Loa
>      >     Andersson <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Vigoureux, Martin
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>] 代表 STARK, BARBARA H
>      >          > 发送时间: 2019年3月27日 20:02
>      >          > <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>      >     Mach Chen <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Loa
>      >          > Andersson <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>; Vigoureux, Martin
>      >          > <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >          > -- snip --
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 Mar 2019 11:01:02 +0100

Hi Joel,
I haven't heard that anyone had asked to blindly accept, less publish as an
RFC the proposed solution. The set of documents explaining CUSP,
requirements, architecture, and the protocol specification, submitted to
IETF with the expectation and commitment to follow the IETF process. In my
experience, the IETF process is the process of rigorous reviews,
discussions, and, often than not, changes. That, in my opinion, is far from
"rubber-stamping". In my personal opinion, CUSP drafts, as well as
draft-wadhwa-*, need lots of work to get to WG AP level. I am willing and
committed to working with both teams whether under the new WG or one of the
already existing WGs.

Regards,
Greg

On Thu, Mar 28, 2019 at 10:48 AM Joel M. Halpern <[email-masked]>
wrote:

> >      >          > <[email-masked] <mailto:[email-masked]>
> >      >          > (Nokia - FR/Paris-Saclay) <[email-masked]
> >      >          > "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
> >      >          > <[email-masked]
> >      >          > Andersson <[email-masked] <mailto:[email-masked]>
> >      >          > <[email-masked]
> >      >          > > From: David Fan <[email-masked]
> >      >          > > I think China Mobile Requirements is quite clear, Do
> you
> >      >     agree? I
> >      >          > presented by China Mobile -- but which is not unique
> >     to China
> >      >     Mobile) exist is
> >      >          > 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
> >      >          > 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
> >      >          > It really shouldn't take that long to get an answer to
> >     this
> >      >     question. I'm pretty
> >      >          > Other operators (with different use cases) are not
> >     asking for
> >      >     IETF to produce a
> >      >          > 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Mar 2019 11:06:28 +0100

If it is properly open to IETF work, then the result of the IETF work 
will almost certainly be different from the proprietary protocol.  And 
it may be very different.  As such, the experience with the existing 
protocol becomes useful input to whatever body is doing the work, but 
not a reason for doing the work at the IETF, nor a reason for basing the 
effort itself on a particular proprietary protocol.

Yours,
Joel

On 3/28/19 11:01 AM, Greg Mirsky wrote:
> Hi Joel,
> I haven't heard that anyone had asked to blindly accept, less publish as 
> an RFC the proposed solution. The set of documents explaining CUSP, 
> IETF with the expectation and commitment to follow the IETF process. In 
> my experience, the IETF process is the process of rigorous reviews, 
> discussions, and, often than not, changes. That, in my opinion, is far 
> from "rubber-stamping". In my personal opinion, CUSP drafts, as well as 
> draft-wadhwa-*, need lots of work to get to WG AP level. I am willing 
> and committed to working with both teams whether under the new WG or one 
> of the already existing WGs.
> 
> Regards,
> Greg
> 
> On Thu, Mar 28, 2019 at 10:48 AM Joel M. Halpern <[email-masked] 
>      > On Thu, Mar 28, 2019 at 10:38 AM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > 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)
>     <mailto:[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"
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[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
>      >      >
>      >      >          > -----Original Message-----
>      >      >          > From: Miaofuyou (Miao Fuyou)
>      >      >          > Sent: Wednesday, March 27, 2019 10:34 PM
>      >      >          > To: STARK, BARBARA H <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>;
>      >      >          > BE/Antwerp)' <[email-masked]
>     <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>; Mach Chen
>      >      >          > <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>; Loa
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>>; Vigoureux, Martin
>      >      >          > (Nokia - FR/Paris-Saclay)
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:martin.vigoureux@nokia..com>>
>      >      >     <mailto:[email-masked]
>     <mailto:martin.vigoureux@nokia..com>>>>
>      >      >          > Cc: [email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[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:bcause-bounces@ietf..org>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>] 代表 STARK, BARBARA H
>      >      >          > 发送时间: 2019年3月27日 20:02
>      >      >          > 收件人: 'Henderickx, Wim (Nokia - BE/Antwerp)'
>      >      >          > <[email-masked]
>     <mailto:[email-masked]>> <mailto:wim.henderickx@nokia..com
>     <mailto:[email-masked]>>>>;
>      >      >     Mach Chen <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>; Loa
>      >      >          > Andersson <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>; Vigoureux, Martin
>      >      >     (Nokia - FR/Paris-Saclay)
>      >      >          > <[email-masked]
>     <mailto:martin.vigoureux@nokia..com>>
>     <mailto:martin.vigoureux@nokia..com>
>     <mailto:[email-masked]>>>>
>      >      >          > 抄送: [email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >          > 主题: Re: [bcause] to wait or not to wait
>      >      >          >
>      >      >          > > From: Henderickx, Wim (Nokia - BE/Antwerp)
>      >      >          > -- 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] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>>
>      >      >          > -- snip --
>      >      >          > > 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.
>      >      >          > -- 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]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >          > https://www.ietf.org/mailman/listinfo/bcause
>      >      >
>      >      >
>      >      >     --
>      >      >     bcause mailing list
>     <mailto:[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: "Miaofuyou (Miao Fuyou)" <[email-masked]>
Date: Thu, 28 Mar 2019 10:11:44 +0000

AFAIK, the proponents of CUSP are open and flexible to any change to CUSP protocol that technically makes sense.
发件人：Joel M. Halpern <[email-masked]>
收件人：Greg Mirsky <[email-masked]>
抄 送：[email-masked] <[email-masked]>;Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[email-masked]>;STARK, BARBARA H <[email-masked]>
时间：2019-03-28 10:48:37
主 题：Re: [bcause] to wait or not to wait

No, I would not agree.

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 Mar 2019 11:14:56 +0100

Hi Joel,
I'm surprised by the position, taken by many in this discussion, to dismiss
opportunity for the thorough review, discussion of CUSP from the very start.

Regards,
Greg

On Thu, Mar 28, 2019 at 11:06 AM Joel M. Halpern <[email-masked]>
wrote:

> >      >      > I think you understand how different is operational
> >     consideration
> >      >     for an
> >      >      > PFCP in this case, compared with using the protocol that
> the
> >      >     operations
> >      >      >     On 27/03/2019, 15:49, "Mach Chen"
> >      >      >     <mailto:[email-masked]
> >      >      >     focused, and they have asked IETF to develop a
> protocol to
> >      >     satisfy
> >      >      >     <mailto:[email-masked] <mailto:[email-masked]>
> >      >      >          > <[email-masked]
> >      >      >          > "So to me, the question is: Is there consensus
> >     in IETF to
> >      >      >     quickly develop a new
> >      >      >     Mach Chen <[email-masked]
> >      >      >          > > 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
> >      >      >     <mailto:[email-masked]
> >      >      >          > > I think China Mobile Requirements is quite
> >     clear, Do you
> >      >      >     agree? I
> >      >      >          > > 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
> >      >      >          > certainly important information for individuals
> >     forming
> >      >      >     opinions in IETF. But,
> >      >      >          > 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
> >      >      >          > If the answer is yes, then go ahead and do it
> >     and get
> >      >     started.
> >      >      >          > sure everyone on this list feels like they have
> the
> >      >      >          > 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
> >      >      >          > And in case anyone is confused... the BoF is
> >     over and I am
> >      >      >     not a chair of