Subject: [bcause] Coexistence of short and long term goals make a better WG not worse

From: Liang GENG <[email-masked]>
Date: Wed, 27 Mar 2019 14:52:46 +0000

Hi all,

Many who attended the BoF agreed on use case and requirement of this work. It is a shame that the "uncertainty" of requirement from other SDOs is blocking on the way. This reminds me the back and forth discussion on Network Slicing Management between IETF and 3GPP 2 years ago. The result was that IP network slicing is so left behind compared with the progress on Core Network (3GPP) and Optical Transport Network (ITU-T). We don't even have a reasonable simple tool for cross-domain VPN service - given the fact it is a most simplest type of network slicing.

I simply don't see a point to let this happening again in IETF. And I see the following 2 main reasons why IETF should take this work on in a timely manner

  1.  As an operator, we have clear requirement to standardize protocol / interface between BNG-UP and BNG-CP for fixed line services. And believe me, if taking FMC/WWC as an extended use case is the concern, China Mobile would be the first to support it as a long term goal - given that we are one of the few operators across the globe who has clear SA 5GC deployment plan. However, there is no conflicts between fulfilling short-term (and clear) goal and being open to the work for long-term goal. It is also too early for a proposed WG to decide a single solution that fulfill all use cases. It makes perfect sense to start with one clear use case and proceed to more when the requirements and interests are there.
  2.  Being called BNG does not make it less-IETF - most of the basic protocols are IETF technologies. I think there is no better place to work this out than in IETF - given the fact this is needed timely and we need an organization with enough people who would like to contribute. See the number of people who attend the BoF. Although the chairs did not ask the "willing to contribute" question - there is no doubt of good participation rate.

I would encourage people should continue the discussion on charter updates in the mailing list - of course it is the AD's decision on advising the next steps.

Best wishes
Liang

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 27 Mar 2019 15:10:21 +0000

Well said! Support to start with the one clear use case.

________________________________
彭书萍 Peng Shuping
M：+86-18210364128<tel:+86-18210364128>(优先)
E：[email-masked]<mailto:[email-masked]>
网络产品与解决方案-IP技术研究部
Network Products & Solutions-IP Technology Research Dept, NW

发件人： Liang GENG<[email-masked]<mailto:[email-masked]>>
收件人： bcause<[email-masked]<mailto:[email-masked]>>;'Liang Geng | 耿亮'<[email-masked]<mailto:[email-masked]>>
主题： [bcause] Coexistence of short and long term goals make a better WG not worse
时间： 2019-03-27 15:53:09

Hi all,

Best wishes
Liang

---

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

+1

Best regards,
Mach
发件人：Pengshuping (Peng Shuping) <[email-masked]>
收件人：Liang GENG <[email-masked]>;bcause <[email-masked]>;'Liang Geng | 耿亮' <[email-masked]>
时间：2019-03-27 16:11:36
主 题：Re: [bcause] Coexistence of short and long term goals make a better WG not worse

Hi all,

Best wishes
Liang

---

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

+1

Hi all,

Best wishes
Liang

---

From: <[email-masked]>
Date: Wed, 27 Mar 2019 15:43:36 +0000

Agree that the interface between CP and UP should be standardized. Standardizing a solution for a use-case 1 with the outlook that use-cases 2,3,4 will not be covered by that solution but rather require another (even though use-case 1 is subset of 2/3/4) doesn’t seem the right thing to do though. At least I would like to see a solution that covers multiple use-cases, in line with the convergence we see ahead of us and the need to simplify and thus reduce protocols rather than adding more. Fixed BNG is certainly one use-case, but others should not be ignored in this effort as they obviously overlap in requirements.

I don’t have a strong preference on where the works is done, as long as it gets done. Some coordination / agreement is needed probably, since having competing “standards” in different bodies doesn’t help either.

My 2 cents,

cheers,
               Eduard

From: bcause <[email-masked]> On Behalf Of Liang GENG
Sent: woensdag 27 maart 2019 15:53
To: [email-masked]; 'Liang Geng | 耿亮' <[email-masked]>
Subject: [bcause] Coexistence of short and long term goals make a better WG not worse

Hi all,

Best wishes
Liang

---

From: Liang GENG <[email-masked]>
Date: Wed, 27 Mar 2019 14:42:28 +0000

Hi all,

Best wishes
Liang

---

From: "Songjun (Network)" <[email-masked]>
Date: Fri, 29 Mar 2019 13:24:11 +0000

1.       PFCP is not important for FMC

Mobile core is keeping evolution. PFCP must follow on it.

The CUPS interfaces are different between mobile core and BNG.

vBNG-UP and vEPC-UP will run in VM or Container independently. We can do FMC now basing on large-scale deployed protocols (PFCP and S-CUSP), and keep smooth evolution following the development of mobile network and fixed network.

We can guarantee there is PFCP in 6G and 7G. The latest information from 3GPP, they are discussing to change the mechanism between UPF and SMF.

Using PFCP is not equal to implement FMC.

2.       Why not choose PFCP
Why 3GPP not reuse Openflow?

ü  PFCP use the openflow mechanism, openflow was a mature protocol then.

ü  3GPP has its own requirements, using UDP for high throughput.

ü  Defining mobile standard in ONF makes no sense.
Why we did not choose PFCP?

ü  In 2016, we studied Openflow and PFCP, and discussed with PFCP editor (Peter from Huawei).

ü  We found that nearly all requirements of BNG were needed to extended in current protocol. That seems to rewrite a new protocol.

ü  Reusing Openflow and PFCP, the CUSP will be heavily affected by ONF and 3GPP. Discussing BNG in ONF and 3GPP makes no sense.

ü  We decided to define a new protocol with good points from Openflow and PFCP in IETF for BNG.

ü  Mobile core can not use PFCP for interworking with different vendors now in technical reason.

ü  When talking about using PFCP, let me recall the story of T-MPLS(MPLS-TP).  IETF asked ITU-T to stop using MPLS or standardize T-MPLS in IETF.  ITU-T lost the control of T-MPLS, and the standard process was delayed.

3.       DBNG story in BBF

ü  I attended last two BBF meetings.  I found that they want to put everything into MS-BNG, as the following picture. According to Nokia's IETF Draft, EPC and 5GC will also be input into it.

ü  If just put all function together without any changes of outside interfaces and protocols, it is an implementation issues, not a standard issues. We can do it now because we have all related products.

ü  If needing converging functions and changing protocols, someone said that the work could be finished in 5 month.  I do not believe that it can be finished based on running code instead of paperwork.

ü  There are about 20 people attend ATA meeting, with more than 1/3 from Huawei and ZTE.

BTW, this picture was rejected in BBF. It is not easy to draw a clear picture including all functions, even to me.

4.       Suggest IETF  start CUPS protocols for BNG

ü  CU separation is an internal mechanism, unaware to outside, without adding new functions and changing current protocols. TR-384 shows how to separate the functions into CP and UP, it is enough to start the protocols design, basing on running code and scale deployment.

ü  Most BNG in current and in near future, will be used for fixed network users. Requirements on fixed BNG is clear and urgent. How to do FMC is still in discussion, with multiple ways to support it.

ü  S-CUSP's running code is 1/10 of PFCP, because of the different service requirement. CUSP for BNG is a very lightweight protocol, because fixed user does not migrate, always on line, very simple billing. BNG-UP can still forwarding, without BNG-CP. Mobile core reverses. Of cause, we can absorb the good points of Openflow and PFCP.

ü  IETF is the right place to define a protocol for BNG, 3GPP is the right place to extend PFCP.

ü  If using PFCP and including unclear FMC functions, we will mesh 3 SDOs together, many device functions(BNG,AC,TWAF,HAG,EPC,5GC) together. When can we meet the real IP network requirements?

5.       How to deal with FWA requirements, such as HAG?

ü  HAG can be deployed independently or with BNG. CUPS HAG can be added in WT378, with its owner CUSP.

ü  Venders can provide independent HAG or integrated HAG with BNG according Carrier's requirements.

ü  Optimization on integrated HAG is a kind of vendor's implementation, not standard issues.

ü  CUSP for HAG can be defined according to HAG requirements, with smooth independent evolution.

Simple and Flexible are the keys for success of IP network, when you think about Ethernet/IP against ATM.

---

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

I am amused to see the relentless effort here. First, based on Wikipedia PFCP would not work, then number of pages of the spec made it prohibitive, now it is "PFCP is defined by 3GPP, so it is not suitable".
But then you also suggest you could start with CUSP day one, throw it day two and move to PFCP. Why should we not start with the right interface day one, especially if it can provide a single solution irrespective of access.

BTW, PFCP includes both the interface to exchange state between CP and UP and the interface to pass in-band control e.g. PPPoE/DHCP signaling between UP and CP. You don't need VxLAN shown in your picture.
The third interface is completely orthogonal and nothing to do with dynamic state between CP and UP. It is a local management interface where CP provide single point for management and control for a set of UPs. You can think of it as a way to provide CLI on the CP for entire CUPS system. It could be NETCONF or gNMI or your favorite one, as long as you have a well-defined data model.

You talk about additional functions in BNG. With PFCP, you don't need to throw away the underlying protocol if you want to integrate another function in the BNG. PFCP (via PDRs) are flexible in specifying forwarding between different access and network facing encapsulations i.e. [access <-> network] as needed by different functions e.g. for fixed-access this may be [L2 <-> IP], for fixed-wireless [GTP-u <-> IP], for hybrid-access both [L2, GTP-u <-> IP], for (T)WAG [L2oGRE <-> IP or GTP-u]. Hope you get the idea. You also have the flexibility on the transport encapsulations in the access for fixed-network. Could be VLANs, MPLS-PW, VxLAN, L2oGRE, pick your favorite. No change to the underlying protocol.
But wait...what a tragedy that PFCP is defined by 3GPP.

-Sanjay

From: bcause <[email-masked]> On Behalf Of Songjun (Network)
Sent: Friday, March 29, 2019 6:24 AM
To: [email-masked]
Subject: [bcause] PFCP not equal to FMC, Why not choose PFCP

2.       Why not choose PFCP

?  PFCP use the openflow mechanism, openflow was a mature protocol then.

?  3GPP has its own requirements, using UDP for high throughput.

?  Defining mobile standard in ONF makes no sense.
Why we did not choose PFCP?

?  In 2016, we studied Openflow and PFCP, and discussed with PFCP editor (Peter from Huawei).

?  We found that nearly all requirements of BNG were needed to extended in current protocol. That seems to rewrite a new protocol.

?  Reusing Openflow and PFCP, the CUSP will be heavily affected by ONF and 3GPP. Discussing BNG in ONF and 3GPP makes no sense.

?  We decided to define a new protocol with good points from Openflow and PFCP in IETF for BNG.

?  Mobile core can not use PFCP for interworking with different vendors now in technical reason.

?  When talking about using PFCP, let me recall the story of T-MPLS(MPLS-TP).  IETF asked ITU-T to stop using MPLS or standardize T-MPLS in IETF.  ITU-T lost the control of T-MPLS, and the standard process was delayed.

3.       DBNG story in BBF

?  I attended last two BBF meetings.  I found that they want to put everything into MS-BNG, as the following picture. According to Nokia's IETF Draft, EPC and 5GC will also be input into it.

?  If just put all function together without any changes of outside interfaces and protocols, it is an implementation issues, not a standard issues. We can do it now because we have all related products.

?  If needing converging functions and changing protocols, someone said that the work could be finished in 5 month.  I do not believe that it can be finished based on running code instead of paperwork.

?  There are about 20 people attend ATA meeting, with more than 1/3 from Huawei and ZTE.

?  CU separation is an internal mechanism, unaware to outside, without adding new functions and changing current protocols. TR-384 shows how to separate the functions into CP and UP, it is enough to start the protocols design, basing on running code and scale deployment.

?  Most BNG in current and in near future, will be used for fixed network users. Requirements on fixed BNG is clear and urgent. How to do FMC is still in discussion, with multiple ways to support it.

?  S-CUSP's running code is 1/10 of PFCP, because of the different service requirement. CUSP for BNG is a very lightweight protocol, because fixed user does not migrate, always on line, very simple billing. BNG-UP can still forwarding, without BNG-CP. Mobile core reverses. Of cause, we can absorb the good points of Openflow and PFCP.

?  IETF is the right place to define a protocol for BNG, 3GPP is the right place to extend PFCP.

?  If using PFCP and including unclear FMC functions, we will mesh 3 SDOs together, many device functions(BNG,AC,TWAF,HAG,EPC,5GC) together. When can we meet the real IP network requirements?

?  HAG can be deployed independently or with BNG. CUPS HAG can be added in WT378, with its owner CUSP..

?  Venders can provide independent HAG or integrated HAG with BNG according Carrier's requirements.

?  Optimization on integrated HAG is a kind of vendor's implementation, not standard issues.

?  CUSP for HAG can be defined according to HAG requirements, with smooth independent evolution.

---

From: "Songjun (Network)" <[email-masked]>
Date: Fri, 29 Mar 2019 17:20:30 +0000

1.       PFCP is mature for mobile core, not for BNG. It is about 2 years behind.

http://www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS-phase2.pdf

2.       Modifying PFCP is a tough way

ü  Any changes on PFCP will go to 3GPP for approve, then adding into the PFCP document(more than 200 pages now). Any changes against 3GPP principles and rules will be rejected.  (3GPP and IETF have different principles and design mechanisms)

ü  3GPP just claimed to delay 5G standards 6 month.  Extending PFCP for BNG is not a  key task in 3GPP.

ü  There is no group in 3GPP for EPC, where to discussing BNG and EPC merging and the related protocol?

ü  If 3GPP will not use PFCP in the next release or next generation?  3GPP is discussing to use micro service mechanism between SMF and UPF.

发件人: Wadhwa, Sanjay (Nokia - US/Mountain View) [mailto:[email-masked]]
发送时间: 2019年3月29日 22:45
收件人: Songjun (Network); [email-masked]
主题: RE: PFCP not equal to FMC, Why not choose PFCP

I am amused to see the relentless effort here. First, based on Wikipedia PFCP would not work, then number of pages of the spec made it prohibitive, now it is “PFCP is defined by 3GPP, so it is not suitable”.
But then you also suggest you could start with CUSP day one, throw it day two and move to PFCP. Why should we not start with the right interface day one, especially if it can provide a single solution irrespective of access.

BTW, PFCP includes both the interface to exchange state between CP and UP and the interface to pass in-band control e.g. PPPoE/DHCP signaling between UP and CP. You don’t need VxLAN shown in your picture.
The third interface is completely orthogonal and nothing to do with dynamic state between CP and UP. It is a local management interface where CP provide single point for management and control for a set of UPs. You can think of it as a way to provide CLI on the CP for entire CUPS system. It could be NETCONF or gNMI or your favorite one, as long as you have a well-defined data model.

You talk about additional functions in BNG. With PFCP, you don’t need to throw away the underlying protocol if you want to integrate another function in the BNG. PFCP (via PDRs) are flexible in specifying forwarding between different access and network facing encapsulations i.e. [access <-> network] as needed by different functions e.g. for fixed-access this may be [L2 <-> IP], for fixed-wireless [GTP-u <-> IP], for hybrid-access both [L2, GTP-u <-> IP], for (T)WAG [L2oGRE <-> IP or GTP-u]. Hope you get the idea. You also have the flexibility on the transport encapsulations in the access for fixed-network. Could be VLANs, MPLS-PW, VxLAN, L2oGRE, pick your favorite. No change to the underlying protocol.
But wait…what a tragedy that PFCP is defined by 3GPP.

-Sanjay

2.       Why not choose PFCP

*  PFCP use the openflow mechanism, openflow was a mature protocol then.

*  3GPP has its own requirements, using UDP for high throughput.

*  Defining mobile standard in ONF makes no sense.
Why we did not choose PFCP?

*  In 2016, we studied Openflow and PFCP, and discussed with PFCP editor (Peter from Huawei).

*  We found that nearly all requirements of BNG were needed to extended in current protocol. That seems to rewrite a new protocol.

*  Reusing Openflow and PFCP, the CUSP will be heavily affected by ONF and 3GPP. Discussing BNG in ONF and 3GPP makes no sense.

*  We decided to define a new protocol with good points from Openflow and PFCP in IETF for BNG.

*  Mobile core can not use PFCP for interworking with different vendors now in technical reason.

*  When talking about using PFCP, let me recall the story of T-MPLS(MPLS-TP).  IETF asked ITU-T to stop using MPLS or standardize T-MPLS in IETF.  ITU-T lost the control of T-MPLS, and the standard process was delayed.

3.       DBNG story in BBF

*  I attended last two BBF meetings.  I found that they want to put everything into MS-BNG, as the following picture. According to Nokia’s IETF Draft, EPC and 5GC will also be input into it.

*  If just put all function together without any changes of outside interfaces and protocols, it is an implementation issues, not a standard issues. We can do it now because we have all related products.

*  If needing converging functions and changing protocols, someone said that the work could be finished in 5 month.  I do not believe that it can be finished based on running code instead of paperwork.

*  There are about 20 people attend ATA meeting, with more than 1/3 from Huawei and ZTE.

*  CU separation is an internal mechanism, unaware to outside, without adding new functions and changing current protocols. TR-384 shows how to separate the functions into CP and UP, it is enough to start the protocols design, basing on running code and scale deployment.

*  Most BNG in current and in near future, will be used for fixed network users. Requirements on fixed BNG is clear and urgent. How to do FMC is still in discussion, with multiple ways to support it.

*  S-CUSP’s running code is 1/10 of PFCP, because of the different service requirement. CUSP for BNG is a very lightweight protocol, because fixed user does not migrate, always on line, very simple billing. BNG-UP can still forwarding, without BNG-CP. Mobile core reverses. Of cause, we can absorb the good points of Openflow and PFCP.

*  IETF is the right place to define a protocol for BNG, 3GPP is the right place to extend PFCP.

*  If using PFCP and including unclear FMC functions, we will mesh 3 SDOs together, many device functions(BNG,AC,TWAF,HAG,EPC,5GC) together. When can we meet the real IP network requirements?

*  HAG can be deployed independently or with BNG. CUPS HAG can be added in WT378, with its owner CUSP..

*  Venders can provide independent HAG or integrated HAG with BNG according Carrier’s requirements.

*  Optimization on integrated HAG is a kind of vendor’s implementation, not standard issues.

*  CUSP for HAG can be defined according to HAG requirements, with smooth independent evolution.

---

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

PFCP base protocol is in real packet core networks today and runs with UPs that terminate millions of UEs. Fixed-access is relatively less taxing. BTW, these are actual deployments that exercise functionality, resiliency and performance in production, and are not just contrived test scenarios  such as “no AAA, no QOS, no accounting” to showcase performance.

Not sure what is CUSP reference here (no clarity) ? Is it a port of same internal interface that is used between CP and UP on a monolithic chassis, or is it OpenFlow which was originally presented in CUSP drafts but now gone?

Standardization decisions cannot be made on the basis of performance data from proprietary solutions with obscure interfaces and implementation. These should rather be driven from real requirements worked out between vendors and carriers in a transparent manner, which then result in scalable and interoperable solutions. However, you can use this data in your pre-sales. Mileage may vary based on customer savvy though.

-Sanjay

From: Songjun (Network) <[email-masked]>
Sent: Friday, March 29, 2019 10:21 AM
To: Wadhwa, Sanjay (Nokia - US/Mountain View) <[email-masked]>; [email-masked]
Subject: 答复: PFCP not equal to FMC, Why not choose PFCP

发件人: Wadhwa, Sanjay (Nokia - US/Mountain View) [mailto:[email-masked]]
发送时间: 2019年3月29日 22:45
收件人: Songjun (Network); [email-masked]<mailto:[email-masked]>
主题: RE: PFCP not equal to FMC, Why not choose PFCP

-Sanjay

From: bcause <[email-masked]<mailto:[email-masked]>> On Behalf Of Songjun (Network)
Sent: Friday, March 29, 2019 6:24 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [bcause] PFCP not equal to FMC, Why not choose PFCP

2.       Why not choose PFCP

•  PFCP use the openflow mechanism, openflow was a mature protocol then.

•  3GPP has its own requirements, using UDP for high throughput.

•  Defining mobile standard in ONF makes no sense.
Why we did not choose PFCP?

•  In 2016, we studied Openflow and PFCP, and discussed with PFCP editor (Peter from Huawei).

•  We found that nearly all requirements of BNG were needed to extended in current protocol. That seems to rewrite a new protocol.

•  Reusing Openflow and PFCP, the CUSP will be heavily affected by ONF and 3GPP. Discussing BNG in ONF and 3GPP makes no sense.

•  We decided to define a new protocol with good points from Openflow and PFCP in IETF for BNG.

•  Mobile core can not use PFCP for interworking with different vendors now in technical reason.

•  When talking about using PFCP, let me recall the story of T-MPLS(MPLS-TP).  IETF asked ITU-T to stop using MPLS or standardize T-MPLS in IETF.  ITU-T lost the control of T-MPLS, and the standard process was delayed.

3.       DBNG story in BBF

•  I attended last two BBF meetings.  I found that they want to put everything into MS-BNG, as the following picture. According to Nokia’s IETF Draft, EPC and 5GC will also be input into it.

•  If just put all function together without any changes of outside interfaces and protocols, it is an implementation issues, not a standard issues. We can do it now because we have all related products.

•  If needing converging functions and changing protocols, someone said that the work could be finished in 5 month.  I do not believe that it can be finished based on running code instead of paperwork.

•  There are about 20 people attend ATA meeting, with more than 1/3 from Huawei and ZTE.

•  CU separation is an internal mechanism, unaware to outside, without adding new functions and changing current protocols. TR-384 shows how to separate the functions into CP and UP, it is enough to start the protocols design, basing on running code and scale deployment.

•  Most BNG in current and in near future, will be used for fixed network users. Requirements on fixed BNG is clear and urgent. How to do FMC is still in discussion, with multiple ways to support it.

•  S-CUSP’s running code is 1/10 of PFCP, because of the different service requirement. CUSP for BNG is a very lightweight protocol, because fixed user does not migrate, always on line, very simple billing. BNG-UP can still forwarding, without BNG-CP. Mobile core reverses. Of cause, we can absorb the good points of Openflow and PFCP.

•  IETF is the right place to define a protocol for BNG, 3GPP is the right place to extend PFCP.

•  If using PFCP and including unclear FMC functions, we will mesh 3 SDOs together, many device functions(BNG,AC,TWAF,HAG,EPC,5GC) together. When can we meet the real IP network requirements?

•  HAG can be deployed independently or with BNG. CUPS HAG can be added in WT378, with its owner CUSP..

•  Venders can provide independent HAG or integrated HAG with BNG according Carrier’s requirements.

•  Optimization on integrated HAG is a kind of vendor’s implementation, not standard issues.

•  CUSP for HAG can be defined according to HAG requirements, with smooth independent evolution.

---

From: Richard Patterson <[email-masked]>
Date: Sat, 30 Mar 2019 01:05:19 +0100

Hi Song Jun,

Thanks for your detailed email.

I think a lot of people will have queries around this particular statement
of yours regarding PFCP:
ü  We found that nearly all requirements of BNG were needed to extended in
current protocol. That seems to rewrite a new protocol.

Could you please elaborate on this statement?   Where do you see that PFCP
is deficient for fixed line BNG?
If you've got detailed analysis of this, this would be great to see
publicly. From what I've heard, PFCP is easily extendable to satisfy the
requirements for fixed-line BNG.

You also make the assertion:  ü  IETF is the right place to define a
protocol for BNG, 3GPP is the right place to extend PFCP.
There is precedent already for the BBF extending protocols such as DHCP and
PPPoE with various options.   I think we need to properly understand the
extent of how PFCP needs to be extended, in order to decide where best to
make the extension, or if we should just build a new protocol.   I do
however agree that if it's more than a small extension required, then
perhaps the IETF should start from scratch, but I don't see this right now.

-Richard