IETF Logo Mail Archive

Re: [bcause] Inter SDO relationship considerations

Mach Chen <mach.chen@huawei.com> Fri, 29 March 2019 10:09 UTC

Return-Path: <mach.chen@huawei.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 02E2B12030C for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 03:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.631
X-Spam-Level:
X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 n1xmuL_5-qlW for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 03:09:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18AB1202ED for <bcause@ietf.org>; Fri, 29 Mar 2019 03:09:16 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 53EDA4B857AAC90E5069; Fri, 29 Mar 2019 10:09:14 +0000 (GMT)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 29 Mar 2019 10:09:13 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.190]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0415.000; Fri, 29 Mar 2019 18:09:09 +0800
From: Mach Chen <mach.chen@huawei.com>
To: David Sinicrope <david.sinicrope@ericsson.com>, "bcause@ietf.org" <bcause@ietf.org>
CC: "trammell@tik.ee.ethz.ch" <trammell@tik.ee.ethz.ch>
Thread-Topic: [bcause] Inter SDO relationship considerations
Thread-Index: AQHU5hNqkh3JEXIhe0KL6C9yKWuixqYiYr7A
Date: Fri, 29 Mar 2019 10:09:08 +0000
Message-ID: 1DBED2D7-4A4C-4549-8EAC-C2C7A29EDA88
References: <2D09D61DDFA73D4C884805CC7865E6114E11FA36@GAALPA1MSGUSRBF.ITServices.sbc.com> 0484FBCE-34ED-432A-90F9-A054D9412F85, <987A987E-1667-424D-BAC8-7DF518E32735@ericsson.com>
In-Reply-To: <987A987E-1667-424D-BAC8-7DF518E32735@ericsson.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_1DBED2D74A4C45498EACC2C7A29EDA88_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/HuN4S3Lf3F82nFVP5x6DrTvwZ1o>
Subject: Re: [bcause] Inter SDO relationship considerations
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: Fri, 29 Mar 2019 10:09:19 -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 <david.sinicrope@ericsson.com>
收件人：bcause@ietf.org <bcause@ietf.org>
抄 送：trammell@tik.ee.ethz.ch <trammell@tik.ee.ethz.ch>
时间：2019-03-29 10:40:16
主 题：[bcause] Inter SDO relationship considerations

(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

v2.23.0 | Report a Bug | By Email