Subject: [bcause] Barbara's view (was Re: to wait or not to wait)

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 28 Mar 2019 17:41:16 +0000

Well, since we’re talking Barbara’s view...

My view is that there needs to be a decision in IETF to work on CUSP or not. One way or the other. From the comments on the list, it appears everyone else is interpreting “wait for BBF” the same way I am: it’s an implicit decision not to work on CUSP (because the probability of IETF working on CUSP decreases as more time passes).

Just to be clear: I have not expressed on this list whether I’m in favor of IETF working on CUSP (or against). But I think it’s clear that *I* have no personal interest in being involved in such work. It’s also true that I have been forming an opinion.

To form my opinion, I’ve been collecting the pros and cons (aka criteria for evaluation) I’ve read on this list. I’m sharing these on the list with the very selfish hope that maybe by acknowledging these, people won’t feel the need to express the same pros and cons over (and over and over) again.

For IETF working CUSP :
China Mobile very much wants CUSP. It satisfies their use case. They have 150+ million customers and a whole lot of BNGs using CUSP. Extensive experience with CUSP. [And I agree that the presentation from China Mobile was excellent and very informative.]
There are other operators with the same basic use case (but who may have specific needs that are different due to different networks and governments)
CUSP is highly complete (for the China Mobile deployment) and there is significant experience (2 years) with it in a live, deployed environment.

Against IETF working CUSP:
CUSP is not extensible for other (converged, multi/hybrid-access) use cases.
If CUSP is being worked in IETF, it may divert some resources from BBF effort to IETF. Not sure how much.
Other vendors (other than the 2 who created CUSP) may feel the need to also implement CUSP, which would divert resources from their implementing a “one protocol to solve all use cases” protocol. Put another way, there becomes a need for “fixed network, disaggregated BNG” vendors to implement and support 2 protocols instead of just one – which increases complexity of BNG implementations.

I’m sure I missed some. I’m in a hurry to go drink beer. Feel free to unicast me with the ones I missed (if you find this summary useful), and I’ll send an updated list of pros and cons tomorrow.

Barbara

From: Henderickx, Wim (Nokia - BE/Antwerp)

Look at the people who expressed why they wanted PFCP. Barbara’s view is one element but not the only one.

From: "Miaofuyou (Miao Fuyou)" <[email-masked]<mailto:[email-masked]>>

Please read Barbara’s message dated 3/27! There are insightful observations to your “many more”.

发件人: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]]
发送时间: 2019年3月29日 0:06
收件人: Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>; Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=[email-masked]>>; Donald Eastlake <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [bcause] 答复: to wait or not to wait

There are many more who did and voiced their opinion.

From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of "Miaofuyou (Miao Fuyou)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 28 March 2019 at 17:03
To: Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=[email-masked]>>, Donald Eastlake <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bcause] 答复: to wait or not to wait

Which operator has analyzed details of BNG CU against PFCP protocols? AFAIK, it’s only CMCC.  Informed decision counts, not number!

-          Miao

发件人: bcause [mailto:[email-masked]] 代表 Gregory Dalle
发送时间: 2019年3月28日 22:47
收件人: Donald Eastlake <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [bcause] to wait or not to wait

Hi Donald,

There is no paradox here. CUSP is existing to 1 operator (China Mobile) and 2 vendors (Huawei/ZTE). We have yet to hear anybody else who says CUSP covers their requirements.
So yes, you are asking to rubber stamp a new protocol, that is known only to satisfy one operator.
If you want to compare protocol to protocol, PFCP has reached standard status 2 years ago, having been implemented by a number of vendors and in production in a number of operators network. That makes it worth confirming we can use it for BNG based on additional IEs.

I hear the argument, that it is one operator but a very large one, as Greg emphasized it. But it makes no sense to say that this is representative of the market because of size. When it is about capturing requirements, I trust 30 operators with 5M subscribers each, more than 1 operator with 150M subscribers. Wim sent a couple of shortcomings with CUSP yesterday, that in my opinion would not have been missed if more diversity of operators had been involved (lawful intercept is a good example; there was significant work done at 3GPP, where operators were concerned on how to reconcile control plane and user plane information for the lawful authorities).

At this stage, I am not sure we are learning much from the mailing list. I can only hope that we eventually come together and channel all the passion and energy into what is at the end of the BoF meeting notes:

“Tendency to prefer BBF complete this work on requirements.”

Greg

PS: just to avoid any misunderstanding, I like China Mobile! I thought the content prepared for the BoF was excellent and that’s great that China Mobile is taking the initiative to solve their problems by evolving the architecture. So nothing personal, just my opinion on what I think is the best way forward.
On Mar 28, 2019, at 7:31 AM, Donald Eastlake <[email-masked]<mailto:[email-masked]>> wrote:
You know it is interesting: When convenient to their argument, some say that starting with S-CUSP means inventing a new protocol starting from scratch. Others, when convenient to their argument, say that starting with S-CUSP means rubber stamping a complete existing protocol. It really can't be that both of these are true.

It is understood that when a protocol is turned over to the IETF, the IETF has change control.

As far as I know, PFCP is under 3GPP change control. And, while there are limited vendor extension mechanisms in PFCP, I'm not aware of any proposal to put PFCP under BBF (or IETF) change control.

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

--
bcause mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=b7uOOH94vS8SLizH9edYuSighMIVDbp5v3QRWGeBygQ&s=wO6Qromk0vPZLFVWDYCkudGetM3GoDv_KbhJ9wv3Ddk&e=

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 Mar 2019 23:44:36 +0100

Hi Barbara,
many thanks! I agree with your summary. Hope we collectively arrive at the
agreement that will be win-win for everyone interested.

Regards,
Greg

On Thu, Mar 28, 2019 at 6:41 PM STARK, BARBARA H <[email-masked]> wrote:

> My view is that there needs to be a decision in IETF to work on CUSP or
> not. One way or the other. From the comments on the list, it appears
> everyone else is interpreting “wait for BBF” the same way I am: it’s an
> implicit decision not to work on CUSP (because the probability of IETF
> working on CUSP decreases as more time passes).
>
>
>
> Just to be clear: I have not expressed on this list whether I’m in favor
> of IETF working on CUSP (or against). But I think it’s clear that **I**
> have no personal interest in being involved in such work. It’s also true
> that I have been forming an opinion.
>
>
>
> To form my opinion, I’ve been collecting the pros and cons (aka criteria
> for evaluation) I’ve read on this list. I’m sharing these on the list with
> the very selfish hope that maybe by acknowledging these, people won’t feel
> the need to express the same pros and cons over (and over and over) again.
>
>
>
> For IETF working CUSP :
>
> China Mobile very much wants CUSP. It satisfies their use case. They have
> 150+ million customers and a whole lot of BNGs using CUSP. Extensive
> experience with CUSP. [And I agree that the presentation from China Mobile
> was excellent and very informative.]
>
> There are other operators with the same basic use case (but who may have
> specific needs that are different due to different networks and governments)
>
> CUSP is highly complete (for the China Mobile deployment) and there is
> significant experience (2 years) with it in a live, deployed environment.
>
>
>
> Other vendors (other than the 2 who created CUSP) may feel the need to
> also implement CUSP, which would divert resources from their implementing a
> “one protocol to solve all use cases” protocol. Put another way, there
> becomes a need for “fixed network, disaggregated BNG” vendors to implement
> and support 2 protocols instead of just one – which increases complexity of
> BNG implementations.
>
>
>
> I’m sure I missed some. I’m in a hurry to go drink beer. Feel free to
> unicast me with the ones I missed (if you find this summary useful), and
> I’ll send an updated list of pros and cons tomorrow.
>
>
>
> Barbara
>
>
>
> *From:* Henderickx, Wim (Nokia - BE/Antwerp)
>
> *From: *"Miaofuyou (Miao Fuyou)" <[email-masked]>
>
>
> *发件人**:* Henderickx, Wim (Nokia - BE/Antwerp) [
> mailto:[email-masked] <[email-masked]>]
> *发送时间**:* 2019年3月29日 0:06
> *收件人**:* Miaofuyou (Miao Fuyou) <[email-masked]>; Gregory Dalle <
> gdalle=[email-masked]>; Donald Eastlake <[email-masked]>
> *抄送**:* [email-masked]
> *主题**:* Re: [bcause] 答复: to wait or not to wait
>
>
>
> *From: *bcause <[email-masked]> on behalf of "Miaofuyou (Miao
> Fuyou)" <[email-masked]>
> *Date: *Thursday, 28 March 2019 at 17:03
> *To: *Gregory Dalle <gdalle=[email-masked]>, Donald
> Eastlake <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[bcause] 答复: to wait or not to wait
>
>
>
>
>
> Which operator has analyzed details of BNG CU against PFCP protocols?
> AFAIK, it’s only CMCC.  Informed decision counts, not number!
>
>
>
> -          Miao
>
>
>
> *发件人**:* bcause [mailto:[email-masked] <[email-masked]>]
> *代表* Gregory Dalle
> *发送时间**:* 2019年3月28日 22:47
> *收件人**:* Donald Eastlake <[email-masked]>
> *抄送**:* [email-masked]
> *主题**:* Re: [bcause] to wait or not to wait
>
>
>
> Hi Donald,
>
>
>
> There is no paradox here. CUSP is existing to 1 operator (China Mobile)
> and 2 vendors (Huawei/ZTE). We have yet to hear anybody else who says CUSP
> covers their requirements.
>
> If you want to compare protocol to protocol, PFCP has reached standard
> status 2 years ago, having been implemented by a number of vendors and in
> production in a number of operators network. That makes it worth confirming
> we can use it for BNG based on additional IEs.
>
>
>
> I hear the argument, that it is one operator but a very large one, as Greg
> emphasized it. But it makes no sense to say that this is representative of
> the market because of size. When it is about capturing requirements, I
> trust 30 operators with 5M subscribers each, more than 1 operator with 150M
> subscribers. Wim sent a couple of shortcomings with CUSP yesterday, that in
> my opinion would not have been missed if more diversity of operators had
> been involved (lawful intercept is a good example; there was significant
> work done at 3GPP, where operators were concerned on how to reconcile
> control plane and user plane information for the lawful authorities).
>
>
>
> At this stage, I am not sure we are learning much from the mailing list. I
> can only hope that we eventually come together and channel all the passion
> and energy into what is at the end of the BoF meeting notes:
>
> On Mar 28, 2019, at 7:31 AM, Donald Eastlake <[email-masked]> wrote:
>
> You know it is interesting: When convenient to their argument, some say
> that starting with S-CUSP means inventing a new protocol starting from
> scratch. Others, when convenient to their argument, say that starting with
> S-CUSP means rubber stamping a complete existing protocol. It really can't
> be that both of these are true.
>
>
>
> As far as I know, PFCP is under 3GPP change control. And, while there are
> limited vendor extension mechanisms in PFCP, I'm not aware of any proposal
> to put PFCP under BBF (or IETF) change control.
>
>
>
> Thanks,
>
> Donald
>
>  [email-masked]
> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bcause
>

---

From: "Wan, Kenneth (Nokia - CA/Markham)" <[email-masked]>
Date: Thu, 28 Mar 2019 23:38:06 +0000

The other question I think we should ask.

Should time be spent on a new protocol that solves only ONE use case?
OR
Should time be spent on extending an existing protocol that solves multiple use cases (including the one above)?  For multiple service providers?  And offer service providers an opportunity for FMC?

What standardization would benefit the industry the most?

Regards,
-kw

From: bcause <[email-masked]> On Behalf Of Greg Mirsky
Sent: Thursday, March 28, 2019 6:45 PM
To: STARK, BARBARA H <[email-masked]>
Cc: Donald Eastlake <[email-masked]>; [email-masked]; Gregory Dalle <gdalle=[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Barbara,
many thanks! I agree with your summary. Hope we collectively arrive at the agreement that will be win-win for everyone interested.

Regards,
Greg

On Thu, Mar 28, 2019 at 6:41 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
Well, since we’re talking Barbara’s view...

For IETF working CUSP :

Barbara

To: Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=40juniper.net@dmarc..ietf.org>>, Donald Eastlake <[email-masked]<mailto:[email-masked]>>

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Fri, 29 Mar 2019 02:34:51 +0000

IETF works based on “running code and community consensus”. This basic IETF rule exists to make progress, compromise, not have single vendor/operator dictate to the industry one-off/proprietary implementations (we have informational drafts for sharing proprietary solutions), and to get many eye balls and brains with a different perspective on a problem to produce a quality standard.

For running code and community consensus we need a solution that meets industry requirements (many operators across many regions) and allows vendors to optimize development to achieve quality implementation and based cost points that benefit everyone. That is a win-win.

Kind regards,
Andrew

On 2019-03-29, 7:38 AM, "bcause on behalf of Wan, Kenneth (Nokia - CA/Markham)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 29 Mar 2019 05:30:09 +0000

Just an observation.

It seems that most people have made the assumption that the CUSP for the case of CMCC will for sure not be suitable for the FMC scenario, and CMCC as an operator will neither want FMC nor the potentially extensible CUSP to support FMC.

This may not be true since CMCC is an MOBILE operator but using the BNGs to provide the fixed network services for now supporting their 150m subscribers. That would be the first step to evolve to FMC but a solid step as Barbara already summarized in her email (“CUSP is highly complete (for the China Mobile deployment) and there is significant experience (2 years) with it in a live, deployed environment.”).

Therefore, compared to evaluate the possibility of using PFCP (with the amount of unknown extensions) to support this case and FMC cases consuming both the resources of BBF and IETF and maybe other SDOs over an unknown period, the CUSP as the first step has already been concrete and solid with running code.

Also as Barbara summarized in her email that “There are other operators with the same basic use case (but who may have specific needs that are different due to different networks and governments)”. Can we say that this case also has rough consensus?

The question to the community now would be: do we want to start with a concrete case with rough consensus and solid deployment with running code, or do we want to live in the cloud for (quite) a while to figure out a case that is not clear yet (neither for as least the past 20 years) and also to spend unknown amount of energy to explore the feasibility of a proposed solution for realizing this uncertain case?

Surely the community will make a wise decision. Just a reminder that every email we are sending consumers the energy on this planet as well.

My 2 cents.

Best regards,
Shuping

发件人： Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked]<mailto:[email-masked]>>
收件人： Wan, Kenneth (Nokia - CA/Markham)<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;STARK, BARBARA H<[email-masked]<mailto:[email-masked]>>;bcause<[email-masked]<mailto:[email-masked]>>
抄送： Donald Eastlake<[email-masked]<mailto:[email-masked]>>;Gregory Dalle<gdalle=[email-masked]<mailto:gdalle=[email-masked]>>;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked]<mailto:[email-masked]>>;Miaofuyou (Miao Fuyou)<[email-masked]<mailto:[email-masked]>>
主题： Re: [bcause] Barbara's view (was Re: to wait or not to wait)
时间： 2019-03-29 03:35:18

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

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

PFCP is a de-facto standard for CUPS in 3GPP. Try taking CUSP or any alternative with extensions for 3GPP interfaces to 3GPP. From FMC perspective CUSP is a dead-end (may be it is “highly complete” in that sense).

In my view CM’s technical requirements are not mutually exclusive with what other operators on the list have asked for, but is a subset. So why should we be compelled to fragment the solution space? Is it just to accommodate a proprietary implementation? We should look for a single solution.
PFCP with extensions is a good starting point that can satisfy the requirements expressed by many large operators on the list including CM. This is the way forward.

-Sanjay

From: bcause <[email-masked]> On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, March 28, 2019 10:30 PM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; Wan, Kenneth (Nokia - CA/Markham) <[email-masked]>; Greg Mirsky <[email-masked]>; STARK, BARBARA H <[email-masked]>; bcause <[email-masked]>
Cc: Donald Eastlake <[email-masked]>; Gregory Dalle <gdalle=[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Just an observation.

My 2 cents.

Best regards,
Shuping

发件人： Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked]<mailto:[email-masked]>>
收件人： Wan, Kenneth (Nokia - CA/Markham)<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;STARK, BARBARA H<[email-masked]<mailto:[email-masked]>>;bcause<[email-masked]<mailto:[email-masked]>>
抄送： Donald Eastlake<[email-masked]<mailto:[email-masked]>>;Gregory Dalle<gdalle=[email-masked]<mailto:gdalle=[email-masked]>>;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked]<mailto:[email-masked]>>;Miaofuyou (Miao Fuyou)<fuyou.miao@huawei..com<mailto:[email-masked]>>
主题： Re: [bcause] Barbara's view (was Re: to wait or not to wait)
时间： 2019-03-29 03:35:18

Kind regards,
Andrew

Regards,
-kw

From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: Thursday, March 28, 2019 6:45 PM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>
Cc: Donald Eastlake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

Please read Barbara’s message dated 3/27! There are insightful observations to your “many more”..

To: Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=40juniper.net@dmarc...ietf.org>>, Donald Eastlake <[email-masked]<mailto:[email-masked]>>

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 Mar 2019 07:02:45 +0000

I agree with Sanjay here and other who expressed the same. We should not fragment the market since CM use case is indeed a subset of the complete requirements we need to develop. So let’s not fragment the market and ensure we do the industry a favor.
PFCP will be a given, whether people like it or not, 3GPP will not give this up for anything that interfaces with mobile. It is proven in the field and as said before we have a proposal and implementation which proofs it is easy to extend PFCP, but we believe it is better to do this effort in BBF where the expertise of the BNG resides.

From: bcause <[email-masked]> on behalf of Sanjay WADHWA <[email-masked]>
Date: Friday, 29 March 2019 at 07:43
To: "Pengshuping (Peng Shuping)" <[email-masked]>, Andrew Dolganow <[email-masked]>, Greg Mirsky <[email-masked]>, "STARK, BARBARA H" <[email-masked]>
Cc: bcause <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 Mar 2019 07:05:20 +0000

Btw if people are interested we can show a demo how PFCP can be extended to support fixed use cases.

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Friday, 29 March 2019 at 08:02
To: Sanjay WADHWA <[email-masked]>, "Pengshuping (Peng Shuping)" <[email-masked]>, Andrew Dolganow <[email-masked]>, Greg Mirsky <[email-masked]>, "STARK, BARBARA H" <[email-masked]>
Cc: bcause <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 29 Mar 2019 08:03:14 +0000

While choosing protocol, we MUST take protocol which has been wide  deployed  and worked by larger audience. There is a general good overall community gets due to contribution by larger number of people. A good example is one reason  3GPP choosing HTTP2 for SBA architecture  and dumping  all Telco  protocols like GTP-C/Diameter/Radius.
            In  IETF,  we have leveraged BGP to solve MPLS VPNs, EVPNs, VPLS  etc  rather than reinventing some other protocols and BGP also becoming defacto for inter-domain exchanges.

Here in CUPS,  PFCP will be widely deployed as it will be used  for 5G. I am using “5g “ rather than mobile operators since its applicability is beyond carriers . May be even enterprises  verticals etc for their use cases.  So even though CUSP may have some users, its limited applicability in solving specific use case and work by small set of folks makes it less obvious choice for CUPS  and the balance favors  asymmetrically  for  PFCP making it defacto for  CUPS.

-Praveen

From: bcause <[email-masked]> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Friday, March 29, 2019 12:05 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; Greg Mirsky <[email-masked]>; STARK, BARBARA H <[email-masked]>
Cc: bcause <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, 29 March 2019 at 08:02
To: Sanjay WADHWA <[email-masked]<mailto:[email-masked]>>, "Pengshuping (Peng Shuping)" <[email-masked]<mailto:[email-masked]>>, Andrew Dolganow <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Cc: bcause <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of Sanjay WADHWA <[email-masked]<mailto:[email-masked]>>
Date: Friday, 29 March 2019 at 07:43
To: "Pengshuping (Peng Shuping)" <[email-masked]<mailto:[email-masked]>>, Andrew Dolganow <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Cc: bcause <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

-Sanjay

From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, March 28, 2019 10:30 PM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>>; Wan, Kenneth (Nokia - CA/Markham) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>; bcause <[email-masked]<mailto:[email-masked]>>
Cc: Donald Eastlake <[email-masked]<mailto:[email-masked]>>; Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Miaofuyou (Miao Fuyou) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: Liang GENG <[email-masked]>
Date: Fri, 29 Mar 2019 08:41:23 +0000

I think no one is refusing PFCP for CUPS.

I mean, yes PFCP is a good choice for FMC because FMC implies Mobile Core conquering Broadband and PFCP is a Mobile Core native solution. This is a reasonable choice.

However I am yet to see FMC coming in terms of mass deployment in next 3-5 years. I think It is also reasonable to have a fix-line specific CUPS solution as a transitional technology.  It gives you more choices and flexibility of evolving your BNG network.

Without clear requirement and road map for FMC (Here I mean implementation driven, not technology driven), there would be no good reason to consider PFCP in first place. However, PFCP extension for Fix line, or for a longer term FMC, could be and should be discussed here simultaneously in IETF.

________________________________
From: bcause <[email-masked]> on behalf of Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>
Sent: 29 March 2019 16:03
To: Henderickx, Wim (Nokia - BE/Antwerp); Wadhwa, Sanjay (Nokia - US/Mountain View); Pengshuping (Peng Shuping); Dolganow, Andrew (Nokia - SG/Singapore); Greg Mirsky; STARK, BARBARA H
Cc: bcause
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

-Praveen

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

时间： 2019-03-29 03:35:18

Kind regards,

Andrew

OR

Regards,

-kw

Hi Barbara,

Regards,

Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,

Donald

---

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

Thanks, Barbara, a good summary!

One thing I am confused is "divert resource from BBF to IETF".  I think it's a statement rather than fact. There are very limited overlapping of participants base between BBF and IETF(less than 15 on many areas besides BNG, my estimation). In the same time, if you care both, why not participate both? If not, it's your problem, not problem of IETF or others who are working hard to meet the immediate deployment requirement.
发件人：STARK, BARBARA H <[email-masked]>
收件人：'Henderickx, Wim (Nokia - BE/Antwerp)' <[email-masked]>;Miaofuyou (Miao Fuyou) <[email-masked]>;Gregory Dalle <gdalle=[email-masked]>;Donald Eastlake <[email-masked]>
抄 送：[email-masked] <[email-masked]>
时间：2019-03-28 18:41:31
主 题：Barbara's view (was Re: to wait or not to wait)

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: David Sinicrope <[email-masked]>
Date: Fri, 29 Mar 2019 09:39:51 +0000

(IETF Liaison Manager to BBF hat on)

The statements on this list, especially those to the effect that CUSP work in the IETF would not exclude FMC, indicate that there is high potential (and intent?) that both the BBF and the IETF would be working on two competing solutions, i.e., two different solutions competing for the same problem.  

The two organizations pursuing competing solutions creates an inherent strain on the inter SDO relationship, that to this point has been coordinated, cooperative and cordial.

Further, given the indications in the liaisons from BBF that they intend to work cooperatively with 3GPP, should they decide to pursue PFCP as a solution, would then potentially put IETF in competition with 3GPP as well.

Introducing this inter-SDO strain has potential impacts beyond this immediate bcause issue to other work between the organizations.   

I would ask the participants and ADs to please consider these potential issues in your deliberations.

Thank-you,
Dave

---

From: Mach Chen <[email-masked]>
Date: Fri, 29 Mar 2019 10:09:08 +0000

I think your statement is not true, there is no overlap
. As one of the proponents, I am sure that the CUSP is only targeting to address CMCC's fixed BNG CUPS  requirements.

Best regards,
Mach
发件人：David Sinicrope <[email-masked]>
收件人：[email-masked] <[email-masked]>
抄 送：[email-masked] <[email-masked]>
时间：2019-03-29 10:40:16
主 题：[bcause] Inter SDO relationship considerations

Thank-you,
Dave

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 Mar 2019 11:33:13 +0100

Hi David,
I think that the comment that brought your attention is one of the
individual opinions that not necessarily reflect the opinion of CUSP
supporters.

Regards,
Greg

On Fri, Mar 29, 2019 at 10:40 AM David Sinicrope <
[email-masked]> wrote:

> The statements on this list, especially those to the effect that CUSP work
> in the IETF would not exclude FMC, indicate that there is high potential
> (and intent?) that both the BBF and the IETF would be working on two
> competing solutions, i.e., two different solutions competing for the same
> problem.
>
> The two organizations pursuing competing solutions creates an inherent
> strain on the inter SDO relationship, that to this point has been
> coordinated, cooperative and cordial.
>
> Further, given the indications in the liaisons from BBF that they intend
> to work cooperatively with 3GPP, should they decide to pursue PFCP as a
> solution, would then potentially put IETF in competition with 3GPP as well.
>
> Introducing this inter-SDO strain has potential impacts beyond this
> immediate bcause issue to other work between the organizations.
>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Fri, 29 Mar 2019 10:35:44 +0000

+1

Regards,
Andrew
Sent from my iPhone Outlook<https://aka.ms/qtex0l>
________________________________
From: bcause <[email-masked]> on behalf of David Sinicrope <[email-masked]>
Sent: Friday, March 29, 2019 5:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: [bcause] Inter SDO relationship considerations

Thank-you,
Dave

---

From: Gregory Dalle <[email-masked]>
Date: Fri, 29 Mar 2019 11:22:33 +0000

Mach, it would overlap. BBF is addressing CUPS both for BNG (WT-459) and CUPS for FMC (WT-458), as described in liaisons.

Greg

On Mar 29, 2019, at 6:09 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
Mach
发件人：David Sinicrope <[email-masked]<mailto:[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
抄 送：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-29 10:40:16
主 题：[bcause] Inter SDO relationship considerations

Thank-you,
Dave

--
bcause mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=JC3Qb6i8mCuJ1qoJ8V-GimcEg54-mMyrB33kAH77u5s&s=rParcq-0T3mErgJ0LkEVsN2Re1I49f7UqUi1l9dvxnU&e=

---

From: Mach Chen <[email-masked]>
Date: Fri, 29 Mar 2019 12:04:37 +0000

Hi Greg,

Let's put FMC, WT-458, aside, since it is not in the scope.

As for DBNG,WT-459, AFAIK, it just focuses on architecture, requirements, use cases. CUPS protocol definition for BNG is not in the scope.

Let's do not confuse the situation again and again.

Best regards,
Mach
发件人：Gregory Dalle <[email-masked]>
收件人：Mach Chen <[email-masked]>
抄 送：David Sinicrope <[email-masked]>;[email-masked] <[email-masked]>;[email-masked] <[email-masked]>
时间：2019-03-29 12:22:46
主 题：Re: [bcause] Inter SDO relationship considerations

Greg

Best regards,
Mach

Thank-you,
Dave

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 29 Mar 2019 08:26:38 +0000

hi, Sanjay

We are still talking about the CU interfaces for BNG, right? Why we need to extend the protocol to support “for 3GPP interfaces to 3GPP”?

BTW just a comment, how could you know it is a dead-end without even working on it? :)

Shuping

发件人： Wadhwa, Sanjay (Nokia - US/Mountain View)<[email-masked]<mailto:[email-masked]>>
收件人： Pengshuping (Peng Shuping)<[email-masked]<mailto:[email-masked]>>;Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked]<mailto:[email-masked]>>;Wan, Kenneth (Nokia - CA/Markham)<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;STARK, BARBARA H<[email-masked]<mailto:[email-masked]>>;bcause<[email-masked]<mailto:[email-masked]>>
抄送： Donald Eastlake<[email-masked]<mailto:[email-masked]>>;Gregory Dalle<gdalle=[email-masked]<mailto:gdalle=[email-masked]>>;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked]<mailto:[email-masked]>>;Miaofuyou (Miao Fuyou)<[email-masked]<mailto:[email-masked]>>
主题： RE: [bcause] Barbara's view (was Re: to wait or not to wait)
时间： 2019-03-29 07:40:24

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: Gregory Dalle <[email-masked]>
Date: Fri, 29 Mar 2019 11:52:58 +0000

Hi Shuping,

I see you talk about “rough consensus”. How can 1 operator and 2 vendors make a rough consensus?

I don’t see anything in the mailing list that changes one of the conclusions in the BoF minutes of meeting:

Greg

On Mar 29, 2019, at 4:27 AM, Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>> wrote:

hi, Sanjay

Shuping

-Sanjay

To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>>; Wan, Kenneth (Nokia - CA/Markham) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <bs7652@att..com>; bcause <[email-masked]<mailto:[email-masked]>>

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

To: Gregory Dalle <gdalle=[email-masked]<mailto:gdalle=40juniper.net@dmarc....ietf.org>>, Donald Eastlake <[email-masked]<mailto:[email-masked]>>

-          Miao

Hi Donald,

Greg

Thanks,
Donald

--
bcause mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=b7uOOH94vS8SLizH9edYuSighMIVDbp5v3QRWGeBygQ&s=wO6Qromk0vPZLFVWDYCkudGetM3GoDv_KbhJ9wv3Ddk&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=DwMFbw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=jxxFcaeYKgxAIfyCbZwD0fVKc_ljBIQirRVmJz94dkg&s=BGRApamcF3CKzKRWKz4UQXSUfKV-4vkBuxovNVYlCPM&e=>

---

From: Gregory Dalle <[email-masked]>
Date: Fri, 29 Mar 2019 12:30:47 +0000

Mach,

Current issue of WT-459 is posted. Have a look at the scope section. Protocol definition is in scope, protocol design is not in scope. Nothing new. Feel free to unicast me if you are still confused.

Greg

On Mar 29, 2019, at 8:04 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Greg,

Best regards,
Mach
发件人：Gregory Dalle <[email-masked]<mailto:[email-masked]>>
收件人：Mach Chen <[email-masked]<mailto:[email-masked]>>
抄 送：David Sinicrope <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
时间：2019-03-29 12:22:46
主 题：Re: [bcause] Inter SDO relationship considerations

Greg

Best regards,
Mach

Thank-you,
Dave

---

From: Mach Chen <[email-masked]>
Date: Fri, 29 Mar 2019 13:13:45 +0000

Hi Greg,

You are keep confusing the IETF with the terms that have different meanings in BBF.

Could you please clarify what is called protocol definition, what is call protocol design, what is called protocol specify in the context of BBF?

I remembered the word of "specify" was proposed, which result in quite a lot discussions. Because ”specify” in IETF has very clear meaning. But in BBF, the "specify" equal to "reference".

Best regards,
Mach

时间：2019-03-29 13:31:02

Mach,

Greg

Hi Greg,

Best regards,
Mach

Greg

Best regards,
Mach

Thank-you,
Dave

---

From: Gregory Dalle <[email-masked]>
Date: Fri, 29 Mar 2019 13:43:38 +0000

Hi Mach,

This is all very clear in the working text, we even added text to avoid misunderstandings (Again, if you are not clear, ask questions, don’t spread FUD on BBF).

You told Dave  “your statement is not true, there is no overlap”
You told me “CUPS protocol definition for BNG is not in the scope.
Read WT-459 (your company is a BBF member) and see that protocol specification, by reference is in scope. It does not include protocol design, but does include requirements for protocol extensions. So if you thought that BBF will steer away from looking at CUSP vs PFCP vs FORCES vs Whatever, you didn’t understand.

There would be overlap.

Greg

Juniper Internal
From: Mach Chen <[email-masked]>
Sent: Friday, March 29, 2019 9:14 AM
To: Gregory Dalle <[email-masked]>
Cc: David Sinicrope <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [bcause] Inter SDO relationship considerations

Hi Greg,

Best regards,
Mach
发件人：Gregory Dalle <[email-masked]<mailto:[email-masked]>>
收件人：Mach Chen <[email-masked]<mailto:[email-masked]>>
抄 送：David Sinicrope <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>
时间：2019-03-29 13:31:02
主 题：Re: [bcause] Inter SDO relationship considerations

Mach,

Greg

Best regards,
Mach

Greg

Best regards,
Mach

Thank-you,
Dave

---

From: "Wan, Kenneth (Nokia - CA/Markham)" <[email-masked]>
Date: Fri, 29 Mar 2019 13:43:56 +0000

Hi Mach and all,

I’m one of the editors for the BBF “CUPS for a disaggregated BNG” and “CUPS for 5G FMC” working texts, and I found some distinction between the IETF draft and the BBF WT.

The IETF CUSP draft picks one use case of BNG to tackle.

The BBF WT builds a baseline definition of BNG (quoted all TRs).  It gather ALL use cases and explore deployment scenario from all members, service providers and vendors.   From this, it would build requirements: including protocol requirements, through thorough analysis and rigorous debate from multiple parties.  The WT is built upon consensus of the BNG industry (stake holders), not just one or two use cases.  As an attendee at the BBF, I noticed the quality and quantity of contributions and active participation/discussion we had last week in BBF.

Does the IETF draft goes into the depth of the deployment challenges or operation challenges which could influence the protocol requirements?  Would IETF do this work, in my opinion it would be a duplicate effort.

Regards,
-kw

From: bcause <[email-masked]> On Behalf Of Mach Chen
Sent: Friday, March 29, 2019 9:14 AM
To: Gregory Dalle <[email-masked]>
Cc: [email-masked]; [email-masked]; David Sinicrope <[email-masked]>
Subject: Re: [bcause] Inter SDO relationship considerations

Hi Greg,

Best regards,
Mach

Mach,

Greg

Best regards,
Mach

Greg

Best regards,
Mach

Thank-you,
Dave

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 29 Mar 2019 13:01:34 +0000

Hi Greg,

I was in the room. I don’t remember that there was any conclusion made there within the 1 hour BoF session. It would not be appropriate to take it as a conclusion in the meeting mins.

Best regards
Shuping

发件人： Gregory Dalle<[email-masked]<mailto:[email-masked]>>
收件人： Pengshuping (Peng Shuping)<[email-masked]<mailto:[email-masked]>>
抄送： Wadhwa, Sanjay (Nokia - US/Mountain View)<[email-masked]<mailto:[email-masked]>>;Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked]<mailto:[email-masked]>>;Wan, Kenneth (Nokia - CA/Markham)<[email-masked]<mailto:[email-masked]>>;Greg Mirsky<[email-masked]<mailto:[email-masked]>>;STARK, BARBARA H<[email-masked]<mailto:[email-masked]>>;bcause<[email-masked]<mailto:[email-masked]>>;Donald Eastlake<[email-masked]<mailto:[email-masked]>>;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked]<mailto:[email-masked]>>;Miaofuyou (Miao Fuyou)<[email-masked]<mailto:[email-masked]>>
主题： Re: [bcause] Barbara's view (was Re: to wait or not to wait)
时间： 2019-03-29 12:53:14

Hi Shuping,

Greg

hi, Sanjay

Shuping

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: Gregory Dalle <[email-masked]>
Date: Fri, 29 Mar 2019 13:50:08 +0000

Hi Shuping,

It is in the minutes. In any case, again, 1 operator and 2 vendors. I think the few months work at BBF will help you make your case for CUSP and build an ecosystem of interested parties.

Greg

Juniper Internal
From: Pengshuping (Peng Shuping) <[email-masked]>
Sent: Friday, March 29, 2019 9:02 AM
To: Gregory Dalle <[email-masked]>
Cc: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; Wan, Kenneth (Nokia - CA/Markham) <[email-masked]>; Greg Mirsky <[email-masked]>; STARK, BARBARA H <[email-masked]>; bcause <[email-masked]>; Donald Eastlake <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]>
Subject: RE: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Greg,

Best regards
Shuping

Hi Shuping,

Greg

Shuping

-Sanjay

To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>>; Wan, Kenneth (Nokia - CA/Markham) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <bs7652@att..com<mailto:bs7652@att..com>>; bcause <[email-masked]<mailto:[email-masked]>>

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Galway, Keith (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 29 Mar 2019 14:06:07 +0000

As someone generally only peripherally involved in either IETF or BBF the only thing I saw in this list approaching concensus was a few days ago where is seemed to me there was agreement that BBF had the expertise and mandate to do the control-user plane separation work across the use cases of interest as represented by providers on this list -- and that there was a desire to speed that work.   It defies logic in my opinion how pursuing contradictory standards for sub use-cases at the same time can speed that work along or serve the interests of the networking community in general and I don’t see anything resembling concensus on doing that.

…keith

From: bcause <[email-masked]> on behalf of Gregory Dalle <gdalle=[email-masked]>
Date: Friday, March 29, 2019 at 8:18 AM
To: "Pengshuping (Peng Shuping)" <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, bcause <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Donald Eastlake <[email-masked]>, "Miaofuyou (Miao Fuyou)" <[email-masked]>, "Wadhwa, Sanjay (Nokia - US/Mountain View)" <[email-masked]>, "Wan, Kenneth (Nokia - CA/Markham)" <[email-masked]>, "STARK, BARBARA H" <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Shuping,

Greg

Shuping

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

Kind regards,
Andrew

Regards,
-kw

Hi Barbara,

Regards,
Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,
Donald

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 29 Mar 2019 18:08:28 +0000

We should also learn from our past mistakes (CR-LDP) and NOT have competing solutions and confuse industry  and eventually deprecating it.  In mobile world too, having PMIP as S5/s8 was short term benefit for some CDMA operators and eventually it didn’t help them while doing long term roaming scenarios.
               Just as much as  fixed BNG UPF will be used for PPPoE sessions it can be used for fixed wireless (5G) which will be using SBA architecture defined by 3GPP for residential broadband use case ( No FMC as bonding case).  So in that regard, BBF taking up the study and getting us clear guidance is reasonable proposal and that too if it’s a matter of few months.

-Praveen

From: Liang GENG <[email-masked]>
Sent: Friday, March 29, 2019 1:41 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; Greg Mirsky <[email-masked]>; STARK, BARBARA H <[email-masked]>
Cc: bcause <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

From: bcause <[email-masked]<mailto:[email-masked]>> on behalf of Muley, Praveen (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>

-Praveen

From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Friday, March 29, 2019 12:05 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>
Cc: bcause <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

时间： 2019-03-29 03:35:18

Kind regards,

Andrew

OR

Regards,

-kw

Hi Barbara,

Regards,

Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,

Donald

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 Mar 2019 19:23:07 +0100

Hi Praveen,
I'm not sure what in the history of CR-LDP vs. RSVP-TE you see as a
mistake. From the technical point and in my opinion, CR-LDP had advantages
over RSVP-TE and its demise, as I recall, was not for only technical
reasons. Yes, one can say that it was the market that sealed the fate of
CR-LDP and the products that were based on it. Then how that will be the
mistake? Or you refer to the fact that CR-LDP was canceled too early? Just
curious.

Regards,
Greg

PS. I'm not supportive of the idea to select one "champion" protocol among
several offered by their respective design teams. I'm more inclined to give
the protocols evenly leveled starting position and let the Market work its
magic.

On Fri, Mar 29, 2019 at 7:08 PM Muley, Praveen (Nokia - US/Mountain View) <
[email-masked]> wrote:

> We should also learn from our past mistakes (CR-LDP) and NOT have
> competing solutions and confuse industry  and eventually deprecating it.
> In mobile world too, having PMIP as S5/s8 was short term benefit for some
> CDMA operators and eventually it didn’t help them while doing long term
> roaming scenarios.
>
>                Just as much as  fixed BNG UPF will be used for PPPoE
> sessions it can be used for fixed wireless (5G) which will be using SBA
> architecture defined by 3GPP for residential broadband use case ( No FMC as
> bonding case).  So in that regard, BBF taking up the study and getting us
> clear guidance is reasonable proposal and that too if it’s a matter of few
> months.
>
>
>
> -Praveen
>
>
>
> *From:* Liang GENG <[email-masked]>
> *Sent:* Friday, March 29, 2019 1:41 AM
> *To:* Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>;
> Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Wadhwa,
> Sanjay (Nokia - US/Mountain View) <[email-masked]>; Pengshuping
> (Peng Shuping) <[email-masked]>; Dolganow, Andrew (Nokia -
> SG/Singapore) <[email-masked]>; Greg Mirsky <
> [email-masked]>; STARK, BARBARA H <[email-masked]>
> *Cc:* bcause <[email-masked]>
> *Subject:* Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> I mean, yes PFCP is a good choice for FMC because FMC implies Mobile Core
> conquering Broadband and PFCP is a Mobile Core native solution. This is a
> reasonable choice.
>
>
>
> However I am yet to see FMC coming in terms of mass deployment in next 3-5
> years. I think It is also reasonable to have a fix-line specific CUPS
> solution as a transitional technology.  It gives you more choices and
> flexibility of evolving your BNG network.
>
>
>
> Without clear requirement and road map for FMC (Here I mean implementation
> driven, not technology driven), there would be no good reason to consider
> PFCP in first place. However, PFCP extension for Fix line, or for a longer
> term FMC, could be and should be discussed here simultaneously in IETF.
>
>
>
>
> ------------------------------
>
> *From:* bcause <[email-masked]> on behalf of Muley, Praveen
> (Nokia - US/Mountain View) <[email-masked]>
> *Sent:* 29 March 2019 16:03
> *To:* Henderickx, Wim (Nokia - BE/Antwerp); Wadhwa, Sanjay (Nokia -
> US/Mountain View); Pengshuping (Peng Shuping); Dolganow, Andrew (Nokia -
> SG/Singapore); Greg Mirsky; STARK, BARBARA H
> *Cc:* bcause
> *Subject:* Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> While choosing protocol, we MUST take protocol which has been wide
>  deployed  and worked by larger audience. There is a general good overall
> community gets due to contribution by larger number of people. A good
> example is one reason  3GPP choosing HTTP2 for SBA architecture  and
> dumping  all Telco  protocols like GTP-C/Diameter/Radius.
>
>             In  IETF,  we have leveraged BGP to solve MPLS VPNs, EVPNs,
> VPLS  etc  rather than reinventing some other protocols and BGP also
> becoming defacto for inter-domain exchanges.
>
>
>
> Here in CUPS,  PFCP will be widely deployed as it will be used  for 5G. I
> am using “5g “ rather than mobile operators since its applicability is
> beyond carriers . May be even enterprises  verticals etc for their use
> cases.  So even though CUSP may have some users, its limited applicability
> in solving specific use case and work by small set of folks makes it less
> obvious choice for CUPS  and the balance favors  asymmetrically  for  PFCP
> making it defacto for  CUPS.
>
>
>
> -Praveen
>
>
>
>
>
> *From:* bcause <[email-masked]> *On Behalf Of *Henderickx, Wim
> (Nokia - BE/Antwerp)
> *Sent:* Friday, March 29, 2019 12:05 AM
> *To:* Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>;
> Pengshuping (Peng Shuping) <[email-masked]>; Dolganow, Andrew
> (Nokia - SG/Singapore) <[email-masked]>; Greg Mirsky <
> [email-masked]>; STARK, BARBARA H <[email-masked]>
> *Cc:* bcause <[email-masked]>
> *Subject:* Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> *From: *"Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
> *Date: *Friday, 29 March 2019 at 08:02
> *To: *Sanjay WADHWA <[email-masked]>, "Pengshuping (Peng
> Shuping)" <[email-masked]>, Andrew Dolganow <
> [email-masked]>, Greg Mirsky <[email-masked]>, "STARK,
> BARBARA H" <[email-masked]>
> *Cc: *bcause <[email-masked]>
> *Subject: *Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> I agree with Sanjay here and other who expressed the same. We should not
> fragment the market since CM use case is indeed a subset of the complete
> requirements we need to develop. So let’s not fragment the market and
> ensure we do the industry a favor.
>
> PFCP will be a given, whether people like it or not, 3GPP will not give
> this up for anything that interfaces with mobile. It is proven in the field
> and as said before we have a proposal and implementation which proofs it is
> easy to extend PFCP, but we believe it is better to do this effort in BBF
> where the expertise of the BNG resides.
>
>
>
> *From: *bcause <[email-masked]> on behalf of Sanjay WADHWA <
> [email-masked]>
> *Date: *Friday, 29 March 2019 at 07:43
> *To: *"Pengshuping (Peng Shuping)" <[email-masked]>, Andrew
> Dolganow <[email-masked]>, Greg Mirsky <[email-masked]>,
> "STARK, BARBARA H" <[email-masked]>
> *Cc: *bcause <[email-masked]>
> *Subject: *Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> PFCP is a de-facto standard for CUPS in 3GPP. Try taking CUSP or any
> alternative with extensions for 3GPP interfaces to 3GPP. From FMC
> perspective CUSP is a dead-end (may be it is “highly complete” in that
> sense).
>
>
>
> In my view CM’s technical requirements are not mutually exclusive with
> what other operators on the list have asked for, but is a subset. So why
> should we be compelled to fragment the solution space? Is it just to
> accommodate a proprietary implementation? We should look for a single
> solution.
>
> PFCP with extensions is a good starting point that can satisfy the
> requirements expressed by many large operators on the list including CM.
> This is the way forward.
>
>
>
> -Sanjay
>
>
>
>
>
> *From:* bcause <[email-masked]> *On Behalf Of *Pengshuping (Peng
> Shuping)
> *Sent:* Thursday, March 28, 2019 10:30 PM
> *To:* Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>;
> Wan, Kenneth (Nokia - CA/Markham) <[email-masked]>; Greg Mirsky <
> [email-masked]>; STARK, BARBARA H <[email-masked]>; bcause <
> [email-masked]>
> *Cc:* Donald Eastlake <[email-masked]>; Gregory Dalle <
> gdalle=[email-masked]>; Henderickx, Wim (Nokia -
> BE/Antwerp) <[email-masked]>; Miaofuyou (Miao Fuyou) <
> [email-masked]>
> *Subject:* Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> Just an observation.
>
> It seems that most people have made the assumption that the CUSP for the
> case of CMCC will for sure not be suitable for the FMC scenario, and CMCC
> as an operator will neither want FMC nor the potentially extensible CUSP to
> support FMC.
>
> This may not be true since CMCC is an MOBILE operator but using the BNGs
> to provide the fixed network services for now supporting their 150m
> subscribers. That would be the first step to evolve to FMC but a solid step
> as Barbara already summarized in her email (“CUSP is highly complete (for
> the China Mobile deployment) and there is significant experience (2 years)
> with it in a live, deployed environment.”).
>
> Therefore, compared to evaluate the possibility of using PFCP (with the
> amount of unknown extensions) to support this case and FMC cases consuming
> both the resources of BBF and IETF and maybe other SDOs over an unknown
> period, the CUSP as the first step has already been concrete and solid with
> running code.
>
> Also as Barbara summarized in her email that “There are other operators
> with the same basic use case (but who may have specific needs that are
> different due to different networks and governments)”. Can we say that this
> case also has rough consensus?
>
> The question to the community now would be: do we want to start with a
> concrete case with rough consensus and solid deployment with running code,
> or do we want to live in the cloud for (quite) a while to figure out a case
> that is not clear yet (neither for as least the past 20 years) and also to
> spend unknown amount of energy to explore the feasibility of a proposed
> solution for realizing this uncertain case?
>
> Surely the community will make a wise decision. Just a reminder that every
> email we are sending consumers the energy on this planet as well.
>
> My 2 cents.
>
> Best regards,
> Shuping
>
>
>
> *发件人： *Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked]>
>
> *收件人： *Wan, Kenneth (Nokia - CA/Markham)<[email-masked]>;Greg
> Mirsky<[email-masked]>;STARK, BARBARA H<[email-masked]>;bcause<
> [email-masked]>
>
> *抄送： *Donald Eastlake<[email-masked]>;Gregory Dalle<
> gdalle=[email-masked]>;Henderickx, Wim (Nokia - BE/Antwerp)<
> [email-masked]>;Miaofuyou (Miao Fuyou)<fuyou.miao@huawei..com
> <[email-masked]>>
>
> *主题： *Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
> *时间： *2019-03-29 03:35:18
>
>
>
> IETF works based on “running code and community consensus”. This basic
> IETF rule exists to make progress, compromise, not have single
> vendor/operator dictate to the industry one-off/proprietary implementations
> (we have informational drafts for sharing proprietary solutions), and to
> get many eye balls and brains with a different perspective on a problem to
> produce a quality standard.
>
>
>
> For running code and community consensus we need a solution that meets
> industry requirements (many operators across many regions) and allows
> vendors to optimize development to achieve quality implementation and based
> cost points that benefit everyone. That is a win-win.
>
>
>
> Kind regards,
>
> Andrew
>
>
>
>
>
> On 2019-03-29, 7:38 AM, "bcause on behalf of Wan, Kenneth (Nokia -
> CA/Markham)" <[email-masked] on behalf of [email-masked]>
> wrote:
>
>
>
> Should time be spent on extending an existing protocol that solves
> multiple use cases (including the one above)?  For multiple service
> providers?  And offer service providers an opportunity for FMC?
>
>
>
> *From:* bcause <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, March 28, 2019 6:45 PM
> *To:* STARK, BARBARA H <[email-masked]>
> *Cc:* Donald Eastlake <[email-masked]>; [email-masked]; Gregory Dalle <
> gdalle=[email-masked]>; Henderickx, Wim (Nokia -
> BE/Antwerp) <[email-masked]>; Miaofuyou (Miao Fuyou) <
> [email-masked]>
> *Subject:* Re: [bcause] Barbara's view (was Re: to wait or not to wait)
>
>
>
> Hi Barbara,
>
> *发**件人**:* Henderickx, Wim (Nokia - BE/Antwerp) [
> *发**送**时间**:* 2019年3月29日 0:06
> *主**题**:* Re: [bcause] 答复: to wait or not to wait
>
>
>
> *To: *Gregory Dalle <gdalle=[email-masked]
> <gdalle=40juniper.net@dmarc...ietf.org>>, Donald Eastlake <
> [email-masked]>
> *发**件人**:* bcause [mailto:[email-masked]
> <[email-masked]>] *代表* Gregory Dalle
> *发**送**时间**:* 2019年3月28日 22:47
> *主**题**:* Re: [bcause] to wait or not to wait
>
>
>
> Hi Donald,
>
>
>

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 29 Mar 2019 18:52:01 +0000

Hi Greg ,
         I see starting of some work based on short term requirements for one specific case while NOT looking larger picture and NOT even waiting for proper analysis as mistake. So  If we give some time for BBF to provide feedback on their analysis we will do good service for industry.
                     Competing protocols are good provided they clearly address some important aspect of problem. But if it ends up just a matter of adding TLV on different transport then it MAY NOT be helpful.

In context of (CR-LDP) , I see confusion due to competing solutions  in industry  NOT leading to quicker wider deployment as an issue .   As well said by you, products based on CR-LDP might also be the reason (rather than technical) but having vendors to spend double the effort to solve same problems can only lead to such issues due to resource constraints. And hence we should be little careful on our choices of protocol.

Thanks,
Praveen
From: Greg Mirsky <[email-masked]>
Sent: Friday, March 29, 2019 11:23 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>
Cc: Liang GENG <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>; STARK, BARBARA H <[email-masked]>; bcause <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Praveen,
I'm not sure what in the history of CR-LDP vs. RSVP-TE you see as a mistake. From the technical point and in my opinion, CR-LDP had advantages over RSVP-TE and its demise, as I recall, was not for only technical reasons. Yes, one can say that it was the market that sealed the fate of CR-LDP and the products that were based on it. Then how that will be the mistake? Or you refer to the fact that CR-LDP was canceled too early? Just curious.

Regards,
Greg

PS. I'm not supportive of the idea to select one "champion" protocol among several offered by their respective design teams. I'm more inclined to give the protocols evenly leveled starting position and let the Market work its magic.

On Fri, Mar 29, 2019 at 7:08 PM Muley, Praveen (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>> wrote:
We should also learn from our past mistakes (CR-LDP) and NOT have competing solutions and confuse industry  and eventually deprecating it.  In mobile world too, having PMIP as S5/s8 was short term benefit for some CDMA operators and eventually it didn’t help them while doing long term roaming scenarios.
               Just as much as  fixed BNG UPF will be used for PPPoE sessions it can be used for fixed wireless (5G) which will be using SBA architecture defined by 3GPP for residential broadband use case ( No FMC as bonding case).  So in that regard, BBF taking up the study and getting us clear guidance is reasonable proposal and that too if it’s a matter of few months.

-Praveen

From: Liang GENG <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 29, 2019 1:41 AM
To: Muley, Praveen (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>; Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>
Cc: bcause <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

-Praveen

-Sanjay

Just an observation.

My 2 cents.

Best regards,
Shuping

时间： 2019-03-29 03:35:18

Kind regards,

Andrew

OR

Regards,

-kw

Hi Barbara,

Regards,

Greg

For IETF working CUSP :

Barbara

-          Miao

Hi Donald,

Greg

Thanks,

Donald

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 30 Mar 2019 13:03:13 -0000

It’s in the minutes. And I heard it from the chair.

It is recorded as the AD saying what he thinks he heard from the meeting.

It is not recorded as the conclusion of the meeting.

I believe the record is accurate.

You may draw whatever conclusions you like from that.

Thanks,

Adrian

From: bcause <[email-masked]> On Behalf Of Gregory Dalle
Sent: 29 March 2019 13:50
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; bcause <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Donald Eastlake <[email-masked]>; Miaofuyou (Miao Fuyou) <[email-masked]>; Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; Wan, Kenneth (Nokia - CA/Markham) <[email-masked]>; STARK, BARBARA H <[email-masked]>
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Shuping,

Greg 

Juniper Internal

From: Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, March 29, 2019 9:02 AM
To: Gregory Dalle <[email-masked] <mailto:[email-masked]> >
Cc: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]> >; Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked] <mailto:[email-masked]> >; Wan, Kenneth (Nokia - CA/Markham) <[email-masked] <mailto:[email-masked]> >; Greg Mirsky <[email-masked] <mailto:[email-masked]> >; STARK, BARBARA H <[email-masked] <mailto:[email-masked]> >; bcause <[email-masked] <mailto:[email-masked]> >; Donald Eastlake <[email-masked] <mailto:[email-masked]> >; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked] <mailto:[email-masked]> >; Miaofuyou (Miao Fuyou) <[email-masked] <mailto:[email-masked]> >
Subject: RE: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Greg,

Best regards 
Shuping

发件人： Gregory Dalle<[email-masked] <mailto:[email-masked]> >

收件人： Pengshuping (Peng Shuping)<[email-masked] <mailto:[email-masked]> >

抄送： Wadhwa, Sanjay (Nokia - US/Mountain View)<[email-masked] <mailto:[email-masked]> >;Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked] <mailto:[email-masked]> >;Wan, Kenneth (Nokia - CA/Markham)<[email-masked] <mailto:[email-masked]> >;Greg Mirsky<[email-masked] <mailto:[email-masked]> >;STARK, BARBARA H<[email-masked] <mailto:[email-masked]> >;bcause<[email-masked] <mailto:[email-masked]> >;Donald Eastlake<[email-masked] <mailto:[email-masked]> >;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked] <mailto:[email-masked]> >;Miaofuyou (Miao Fuyou)<[email-masked] <mailto:[email-masked]> >

时间： 2019-03-29 12:53:14

Hi Shuping,

 
Greg

On Mar 29, 2019, at 4:27 AM, Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]> > wrote:

hi, Sanjay

Shuping

发件人： Wadhwa, Sanjay (Nokia - US/Mountain View)<[email-masked] <mailto:[email-masked]> >

收件人： Pengshuping (Peng Shuping)<[email-masked] <mailto:[email-masked]> >;Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked] <mailto:[email-masked]> >;Wan, Kenneth (Nokia - CA/Markham)<[email-masked] <mailto:[email-masked]> >;Greg Mirsky<[email-masked] <mailto:[email-masked]> >;STARK, BARBARA H<[email-masked] <mailto:[email-masked]> >;bcause<[email-masked] <mailto:[email-masked]> >

抄送： Donald Eastlake<[email-masked] <mailto:[email-masked]> >;Gregory Dalle<gdalle=[email-masked] <mailto:gdalle=[email-masked]> >;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked] <mailto:[email-masked]> >;Miaofuyou (Miao Fuyou)<fuyou.miao@huawei..com <mailto:[email-masked]> >

时间： 2019-03-29 07:40:24

-Sanjay

From: bcause <[email-masked] <mailto:[email-masked]> > On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, March 28, 2019 10:30 PM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked] <mailto:[email-masked]> >; Wan, Kenneth (Nokia - CA/Markham) <[email-masked] <mailto:[email-masked]> >; Greg Mirsky <[email-masked] <mailto:[email-masked]> >; STARK, BARBARA H <bs7652@att..com <mailto:bs7652@att..com> >; bcause <[email-masked] <mailto:[email-masked]> >
Cc: Donald Eastlake <[email-masked] <mailto:[email-masked]> >; Gregory Dalle <gdalle=[email-masked] <mailto:gdalle=[email-masked]> >; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked] <mailto:[email-masked]> >; Miaofuyou (Miao Fuyou) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Just an observation. 

My 2 cents. 

Best regards, 
Shuping 

发件人： Dolganow, Andrew (Nokia - SG/Singapore)<[email-masked] <mailto:[email-masked]> >

收件人： Wan, Kenneth (Nokia - CA/Markham)<[email-masked] <mailto:[email-masked]> >;Greg Mirsky<[email-masked] <mailto:[email-masked]> >;STARK, BARBARA H<[email-masked] <mailto:[email-masked]> >;bcause<[email-masked] <mailto:[email-masked]> >

抄送： Donald Eastlake<[email-masked] <mailto:[email-masked]> >;Gregory Dalle<gdalle=[email-masked] <mailto:gdalle=[email-masked]> >;Henderickx, Wim (Nokia - BE/Antwerp)<[email-masked] <mailto:[email-masked]> >;Miaofuyou (Miao Fuyou)<fuyou.miao@huawei..com <mailto:[email-masked]> >

时间： 2019-03-29 03:35:18

Kind regards,

Andrew

On 2019-03-29, 7:38 AM, "bcause on behalf of Wan, Kenneth (Nokia - CA/Markham)" <[email-masked] <mailto:[email-masked]>  on behalf of [email-masked] <mailto:[email-masked]> > wrote:

OR

Regards,

-kw

From: bcause <[email-masked] <mailto:[email-masked]> > On Behalf Of Greg Mirsky
Sent: Thursday, March 28, 2019 6:45 PM
To: STARK, BARBARA H <[email-masked] <mailto:[email-masked]> >
Cc: Donald Eastlake <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Gregory Dalle <gdalle=[email-masked] <mailto:gdalle=[email-masked]> >; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked] <mailto:[email-masked]> >; Miaofuyou (Miao Fuyou) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [bcause] Barbara's view (was Re: to wait or not to wait)

Hi Barbara,

Regards,

Greg

On Thu, Mar 28, 2019 at 6:41 PM STARK, BARBARA H <[email-masked] <mailto:[email-masked]> > wrote:

For IETF working CUSP :

Barbara

From: "Miaofuyou (Miao Fuyou)" <[email-masked] <mailto:[email-masked]> >

发件人: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:[email-masked]] 
发送时间: 2019年3月29日 0:06
收件人: Miaofuyou (Miao Fuyou) <[email-masked] <mailto:[email-masked]> >; Gregory Dalle <gdalle=[email-masked] <mailto:gdalle=[email-masked]> >; Donald Eastlake <[email-masked] <mailto:[email-masked]> >
抄送: [email-masked] <mailto:[email-masked]> 
主题: Re: [bcause] 答复: to wait or not to wait

From: bcause <[email-masked] <mailto:[email-masked]> > on behalf of "Miaofuyou (Miao Fuyou)" <[email-masked] <mailto:[email-masked]> >
Date: Thursday, 28 March 2019 at 17:03
To: Gregory Dalle <gdalle=[email-masked] <mailto:gdalle=40juniper.net@dmarc....ietf.org> >, Donald Eastlake <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: [bcause] 答复: to wait or not to wait

-          Miao

发件人: bcause [mailto:[email-masked]] 代表 Gregory Dalle
发送时间: 2019年3月28日 22:47
收件人: Donald Eastlake <[email-masked] <mailto:[email-masked]> >
抄送: [email-masked] <mailto:[email-masked]> 
主题: Re: [bcause] to wait or not to wait

Hi Donald,

On Mar 28, 2019, at 7:31 AM, Donald Eastlake <[email-masked] <mailto:[email-masked]> > wrote:

Thanks,

Donald

 [email-masked] <mailto:[email-masked]> 

-- 
bcause mailing list
[email-masked] <mailto:[email-masked]> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bcause&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=b7uOOH94vS8SLizH9edYuSighMIVDbp5v3QRWGeBygQ&s=wO6Qromk0vPZLFVWDYCkudGetM3GoDv_KbhJ9wv3Ddk&e=> &d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=b7uOOH94vS8SLizH9edYuSighMIVDbp5v3QRWGeBygQ&s=wO6Qromk0vPZLFVWDYCkudGetM3GoDv_KbhJ9wv3Ddk&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=DwMFbw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=VhX0NAIO1d7yQxdURKFPY59GAxttnQcfkn45tfRnREs&m=jxxFcaeYKgxAIfyCbZwD0fVKc_ljBIQirRVmJz94dkg&s=BGRApamcF3CKzKRWKz4UQXSUfKV-4vkBuxovNVYlCPM&e=>