Re: [bcause] to wait or not to wait

[Gregory Dalle <[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, March 27, 2019 11:35 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [bcause] to wait or not to wait

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<[e-mail]<mailto:[e-mail]>>;
收件人：Mach Chen<[e-mail]<mailto:[e-mail]>>;Miaofuyou (Miao Fuyou)<[e-mail]<mailto:[e-mail]>>;STARK, BARBARA H<[e-mail]<mailto:[e-mail]>>;'Henderickx,Wim (Nokia - BE/Antwerp)'<[e-mail]<mailto:[e-mail]>>;Loa Andersson<[e-mail]<mailto:[e-mail]>>;Vigoureux, Martin (Nokia - FR/Paris-Saclay)<[e-mail]<mailto:[e-mail]>>;
抄送人：[e-mail]<[e-mail]<mailto:[e-mail][e-mail]>>;
日期：2019-03-27 15:59:40
主题：Re: [bcause] to wait or not to wait
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Mach Chen
Sent: Wednesday, March 27, 2019 3:49 PM
To: Miaofuyou (Miao Fuyou) <[e-mail]<mailto:[e-mail]>>; STARK, BARBARA H <[e-mail]<mailto:[e-mail]>>; 'Henderickx, Wim (Nokia - BE/Antwerp)' <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Vigoureux, Martin (Nokia - FR/Paris-Saclay) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [bcause] to wait or not to wait

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 <[e-mail]<mailto:[e-mail]>>; 'Henderickx, Wim (Nokia -
> BE/Antwerp)' <[e-mail]<mailto:[e-mail]>>; Mach Chen
> <[e-mail]<mailto:[e-mail]>>; Loa Andersson <[e-mail]<mailto:[e-mail]>>; Vigoureux, Martin
> (Nokia - FR/Paris-Saclay) <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> 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:[e-mail]] 代表 STARK, BARBARA H
> 发送时间: 2019年3月27日 20:02
> 收件人: 'Henderickx, Wim (Nokia - BE/Antwerp)'
> <[e-mail]<mailto:[e-mail]>>; Mach Chen <[e-mail]<mailto:[e-mail]>>; Loa
> Andersson <[e-mail]<mailto:[e-mail]>>; Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> <[e-mail]<mailto:[e-mail]>>
> 抄送: [e-mail]<mailto:[e-mail]>
> 主题: 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 <[e-mail]<mailto:[e-mail]>>
> -- 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/bcause
--
bcause mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bcause
--
bcause mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bcause