Re: [bcause] 答复: PFCP not equal to FMC, Why not choose PFCP

"Wadhwa, Sanjay (Nokia - US/Mountain View)" <sanjay.wadhwa@nokia.com> Mon, 01 April 2019 18:21 UTC

Return-Path: <sanjay.wadhwa@nokia.com>
X-Original-To: bcause@ietfa.amsl.com
Delivered-To: bcause@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52D12011C for <bcause@ietfa.amsl.com>; Mon, 1 Apr 2019 11:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXrPWTI9ycUz for <bcause@ietfa.amsl.com>; Mon, 1 Apr 2019 11:21:24 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10118.outbound.protection.outlook.com [40.107.1.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BBE120075 for <bcause@ietf.org>; Mon, 1 Apr 2019 11:21:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EQh0dFpSQAUhDKLMHWDo2dQMisTMsDrA2YBhSs/NVdo=; b=AORE2dwxvyWwrsNS/MVz/ulw02F5qhvAbz5rgzSfL5DfLLeksFJ9yCRYKX708cLvfOMurHSmAdEz3gqv6RM7RAHnzrciiiPZSuSPiYBEgzvUAhsgmvEna7QA1NH76k6ye8CWfAPRDjMdQQOtwuV17yQjFjwB55i+9hHAP1Rq+1Y=
Received: from AM0PR07MB5361.eurprd07.prod.outlook.com (20.178.82.211) by AM0PR07MB6163.eurprd07.prod.outlook.com (20.178.17.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Mon, 1 Apr 2019 18:21:20 +0000
Received: from AM0PR07MB5361.eurprd07.prod.outlook.com ([fe80::11be:e529:9100:be21]) by AM0PR07MB5361.eurprd07.prod.outlook.com ([fe80::11be:e529:9100:be21%7]) with mapi id 15.20.1771.007; Mon, 1 Apr 2019 18:21:20 +0000
From: "Wadhwa, Sanjay (Nokia - US/Mountain View)" <sanjay.wadhwa@nokia.com>
To: "Songjun (Network)" <song.jun@huawei.com>, Richard Patterson <richard@helix.net.nz>
CC: "bcause@ietf.org" <bcause@ietf.org>
Thread-Topic: [bcause] 答复: PFCP not equal to FMC, Why not choose PFCP
Thread-Index: AQHU6H+kVLopPLK53k6TPsaTwKisXKYnmuyg
Date: Mon, 01 Apr 2019 18:21:19 +0000
Message-ID: <AM0PR07MB536198175AEC56E3BD09F13AFB550@AM0PR07MB5361.eurprd07.prod.outlook.com>
References: <BN6PR22MB0771AD2F5A785C1B08318D8B87580@BN6PR22MB0771.namprd22.prod.outlook.com> <F14D3C24A54A484FB585F96F625D2D991E528046@dggeml509-mbx.china.huawei.com> <CAHL_VyBjcomyhKvjW8EB01m3QSifKfonhZCux9vx=OCH30fr+g@mail.gmail.com> <F14D3C24A54A484FB585F96F625D2D991E533C05@dggeml509-mbx.china.huawei.com>
In-Reply-To: <F14D3C24A54A484FB585F96F625D2D991E533C05@dggeml509-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sanjay.wadhwa@nokia.com;
x-originating-ip: [2601:647:5280:3007:2975:ce48:ee52:da40]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eb9b5c2b-7fd3-4473-3c01-08d6b6ced6a9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:AM0PR07MB6163;
x-ms-traffictypediagnostic: AM0PR07MB6163:
x-microsoft-antispam-prvs: <AM0PR07MB616304EA27016CB699FE374FFB550@AM0PR07MB6163.eurprd07.prod.outlook.com>
x-forefront-prvs: 0994F5E0C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(396003)(346002)(136003)(199004)(189003)(93886005)(81166006)(4326008)(71200400001)(11346002)(55016002)(102836004)(81156014)(486006)(478600001)(46003)(6246003)(52536014)(186003)(86362001)(6306002)(54556002)(54896002)(236005)(7696005)(71190400001)(446003)(6506007)(53546011)(476003)(53936002)(9686003)(99286004)(53946003)(68736007)(14454004)(33656002)(229853002)(5660300002)(6116002)(6436002)(97736004)(76176011)(733005)(790700001)(105586002)(224303003)(2906002)(99936001)(106356001)(25786009)(8936002)(74316002)(110136005)(5070765005)(7736002)(256004)(316002)(14444005)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6163; H:AM0PR07MB5361.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: r4ZYnNZXIu8KVgT3nCwQaG+RvOjK1vv838jbqQFvPh+KxdIib7stiC/kjEke2LcQs+2Xhct63WP/ohOtVplyReNasrfI6QDzfCk62duzahnK+BssTfZPzzkEznJ5OqBSQ12mCV6YLr2MvLFqNjcbegzojyLYgVGL3EgetVL+WmHbpF79ol8a58zFmPNtLIgl9wrlimEY8ja4DRFz0W4t4Bivmx0hGQp3imBGiQTXVoDyi5nIN7NyyUR5IduucQvCKVoHyPjaLWzc42X7XFmzfr/ZVWsgEYf5oeCcBCSV97cNKVr/MTaSsT3YFOaDTW6lFowx6dk+P6Emnm15ohBNSprtqDkuXhPsKAjPH9VvQDmJZdp8bBcCJytu3l0ODC4Sq7TRAFQQ52bll620KM5T5gZ/tkRrHom6yHCc0u5TZUQ=
Content-Type: multipart/related; boundary="_004_AM0PR07MB536198175AEC56E3BD09F13AFB550AM0PR07MB5361eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eb9b5c2b-7fd3-4473-3c01-08d6b6ced6a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 18:21:19.9567 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6163
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/3fpU0uAvcvr_NIhYSCRCkufaSMs>
Subject: Re: [bcause] 答复: PFCP not equal to FMC, Why not choose PFCP
X-BeenThere: bcause@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <bcause.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bcause>, <mailto:bcause-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bcause/>
List-Post: <mailto:bcause@ietf.org>
List-Help: <mailto:bcause-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bcause>, <mailto:bcause-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 18:21:28 -0000

Songjun
See  response from myself and Andrew to Fengwei’s mail on the list on 3/28. I guess you missed it. It should clear the FUD below. BTW, your examples of objects passed are specific to your proprietary protocol and not to PFCP. PFCP uses standard match rules and actions which can have IE extensions or new IEs to program data-path and to send/receive in-band signaling. You don’t need new messages or containers to pass the IEs. These are used as is. I suggest you look deeper into PFCP before posting.

You said below:
>>CUSP is just the internal interface of BNG.

This is not what one wants. What you need is a standard interface that is purpose built for state exchange between a CP and multiple UPs. Just pulling out the proprietary interface on your BNG between CP and UP, and try to force it as a standard is not the best way forward.

-Sanjay

From: bcause <bcause-bounces@ietf.org> On Behalf Of Songjun (Network)
Sent: Monday, April 1, 2019 4:40 AM
To: Richard Patterson <richard@helix.net.nz>
Cc: bcause@ietf.org
Subject: [bcause] 答复: PFCP not equal to FMC, Why not choose PFCP

Hi, Richard

CMCC organized a study on the gaps of PFCP for BNG in the last year, including Nokia, Huawei, ZTE, H3C,etc.  The conclusion is in the email sent by  Qinfengwei in this maillist.

On 2019-03-28, 5:01 PM, "bcause on behalf of qinfengwei" <bcause-bounces@ietf.org<mailto:bcause-bounces@ietf.org> on behalf of qinfengwei@chinamobile.com<mailto:qinfengwei@chinamobile.com>> wrote:
Hi Sanjay and all,
we have analysed the feasibility used PFCP in DBNG for almost half a year with 3GPP team, of course, your colleage Miao has been involved in the discussion.
PFCP is designed specifically for the wireless, there are lots of gaps between wireless and fixed-network, for example PPPoE, L2TP, Route information, detect result , Nat management and so on. Please get analysis result as the following figure, most BNG attributes need be newly defined in PFCP, and as we all know, there is not communication between different manufactures in wireless network, that means there needs a huge amount of work if PFCP is used to support BNG's function. But we have done lots of work on CUSP, and perform lab interoperation test in July 2019. For the massive deployment in 2020, we need the more professional team (such as IETF) to formulate and perfect the standard.
About 82% BNG attributes have to extend or defined.
[cid:Thinkmail@5627590]
Some examples as the following.
CP to send user's flow table to UPs.

Num

Flow Name

Description

3GPP CUSP

1

BRAS_USER_BASIC_INFO

User’s basic information

yes

2

BRAS_USER_PPP_INFO

User’s PPP information

yes

3

BRAS_USER_IFSRV_INFO

User’s access interface

No

4

BRAS_USER_IPV4_INFO

User’s IPv4 address

No

5

BRAS_USER_IPV6_INFO

User’s IPv6 address

No

6

BRAS_USER_QOS_AUTH_INFO

User’s QoS authorization

No

7

BRAS_ROUTEV4_INFO

BRAS IPv4 Routing information

No

8

BRAS_ROUTEV6_INFO

BRAS IPv6 Routing information

No

9

BRAS_STATIC_USER_INFO

Static user information

No

CP to send user's flow table to UPs.



Num

Flow Name

Description

3GPP CUSP



1

BRAS_USER_BASIC_INFO

User’s basic information

yes



2

BRAS_USER_PPP_INFO

User’s PPP information

yes



3

BRAS_USER_IFSRV_INFO

User’s access interface

No



4

BRAS_USER_IPV4_INFO

User’s IPv4 address

No



5

BRAS_USER_IPV6_INFO

User’s IPv6 address

No



6

BRAS_USER_QOS_AUTH_INFO

User’s QoS authorization

No



7

BRAS_ROUTEV4_INFO

BRAS IPv4 Routing information

No



8

BRAS_ROUTEV6_INFO

BRAS IPv6 Routing information

No



9

BRAS_STATIC_USER_INFO

Static user information

No




        IP engineer likes to use IP terms instead of 3GPP’s terms.  This also means changes in PFCP.    200+pages  PFCP standard is not easy to read for IP engineer.
          PFCP uses UDP for high throughput. But in IP network, I do not know which control protocol use UDP.   Using TCP is a simple way to keep control information reliable and in sequence.   CUSP is a lightweight control protocol.

There are many co-operations between BBF and IETF. Normally, BBF defines requirement and architecture, IETF define protocols, such as ANCP.  IETF is more professional in defining protocols.

In any way, I suggest IETF and BBF define protocols by themselves, without lost controlling.    BNG is not a new one. CUSP is just the internal interface of BNG.

Best Regards!

Jun SONG


发件人: Richard Patterson [mailto:richard@helix.net.nz]
发送时间: 2019年3月30日 8:05
收件人: Songjun (Network) <song.jun@huawei.com<mailto:song.jun@huawei.com>>
抄送: bcause@ietf.org<mailto:bcause@ietf.org>
主题: Re: [bcause] PFCP not equal to FMC, Why not choose PFCP

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