Re: [bcause] Inter SDO relationship considerations

"Wan, Kenneth (Nokia - CA/Markham)" <kenneth.wan@nokia.com> Fri, 29 March 2019 13:44 UTC

Return-Path: <kenneth.wan@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 BCD031203B6 for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 06:44:03 -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 dLAeTehHDHM2 for <bcause@ietfa.amsl.com>; Fri, 29 Mar 2019 06:43:59 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::702]) (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 280EA120388 for <bcause@ietf.org>; Fri, 29 Mar 2019 06:43:59 -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=3RPgP6fifXtdOJWv3sYUt7B5lLJ/QxinRUM/wqqXp7o=; b=KvWip9FyNoZ1OnUgdvCf7Rmar+YB4hzpGiqk/uTADMMrHj2r1ElSUBniT55TyyodEogEHuf/nc3+Hi1y7EywBpWiENCVfdEyUDwd78TCgTyroisTFIehGAwlkKynNMj4gXeIDyt3486+ltwLbLX7Qg8liygQxeXr4oTiJzA0dPo=
Received: from AM5PR0701MB2691.eurprd07.prod.outlook.com (10.173.93.17) by AM5PR0701MB2658.eurprd07.prod.outlook.com (10.173.93.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Fri, 29 Mar 2019 13:43:56 +0000
Received: from AM5PR0701MB2691.eurprd07.prod.outlook.com ([fe80::5954:1163:ba0a:7055]) by AM5PR0701MB2691.eurprd07.prod.outlook.com ([fe80::5954:1163:ba0a:7055%9]) with mapi id 15.20.1771.007; Fri, 29 Mar 2019 13:43:56 +0000
From: "Wan, Kenneth (Nokia - CA/Markham)" <kenneth.wan@nokia.com>
To: Mach Chen <mach.chen@huawei.com>, Gregory Dalle <gdalle@juniper.net>
CC: "bcause@ietf.org" <bcause@ietf.org>, "trammell@tik.ee.ethz.ch" <trammell@tik.ee.ethz.ch>, David Sinicrope <david.sinicrope@ericsson.com>
Thread-Topic: [bcause] Inter SDO relationship considerations
Thread-Index: AQHU5hNmUDneNJ/iykGEN27bDyc+J6YiYr4AgAAUg4CAAAvBgIAAB0+AgAAMAYCAAAFGcA==
Date: Fri, 29 Mar 2019 13:43:56 +0000
Message-ID: <AM5PR0701MB26919B43CA44CF8419B46DBAF65A0@AM5PR0701MB2691.eurprd07.prod.outlook.com>
References: <2D09D61DDFA73D4C884805CC7865E6114E11FA36@GAALPA1MSGUSRBF.ITServices.sbc.com> 0484FBCE-34ED-432A-90F9-A054D9412F85, <987A987E-1667-424D-BAC8-7DF518E32735@ericsson.com>, 1DBED2D7-4A4C-4549-8EAC-C2C7A29EDA88, <1E3BA1F7-39B2-40CE-8129-32891959AE77@juniper.net>, B4498FEF-9E69-481C-8C7C-BF3FD471CF5E, <B12D6AAE-693C-4FAA-A2B5-028D71F77E96@juniper.net> 42FB447A-6546-4E80-B259-0EE898A0C5A1
In-Reply-To: 42FB447A-6546-4E80-B259-0EE898A0C5A1
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [99.244.34.121]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1546c3be-1d45-44a7-07df-08d6b44c96ec
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM5PR0701MB2658;
x-ms-traffictypediagnostic: AM5PR0701MB2658:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM5PR0701MB265858038BBEC7E37E834A05F65A0@AM5PR0701MB2658.eurprd07.prod.outlook.com>
x-forefront-prvs: 0991CAB7B3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(366004)(396003)(136003)(199004)(189003)(31014005)(606006)(76176011)(53546011)(1941001)(478600001)(186003)(4326008)(99286004)(256004)(52536014)(53936002)(93886005)(229853002)(486006)(33656002)(71200400001)(71190400001)(102836004)(5660300002)(966005)(25786009)(2906002)(6346003)(54906003)(66066001)(55016002)(110136005)(316002)(7696005)(6506007)(86362001)(81156014)(106356001)(8936002)(236005)(26005)(68736007)(3846002)(105586002)(81166006)(6246003)(446003)(6306002)(790700001)(6116002)(14454004)(9686003)(74316002)(54896002)(11346002)(8676002)(476003)(7736002)(6436002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2658; H:AM5PR0701MB2691.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)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kenneth.wan@nokia.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GC/SRwvbvcH1+SRtXtnB8lRXuPqQsOFI4oTF9+63qtUvUBk4Tcip2j8S4ORRbXIJjnxgqwJr2LGbRbz1x5K5cE/ecbJkHMwKZI+LeAxY+9SSP53X48/xLsb0Unk6cg0s83zShsOEYo58a47qZcHxahU/BrJm+GdID/nJaw17kFnYi7x7lwHFEnVIxBkuC5Wib9fTdz4kaANEjjl3ef7c4CRbAMAwQRs2GOi0j4v9vzrUiEbQpOASoEobf8vb31Z0Z3KXyoigVc2gAuF/6Hs+yY63plvU2ER7IRahn7jqKrv29C2QCZVefQLKiPmIpIadiPpcrFCjRPfFLVLdW0yK2CKnJb4MZBcgNC4+JqKzkxhzZHb2gVUPN7bVwrbgnDjUhxn2ClcBgUeSN5zRaB4+T0YArT+E/76IVYGz1Xeem7M=
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB26919B43CA44CF8419B46DBAF65A0AM5PR0701MB2691_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1546c3be-1d45-44a7-07df-08d6b44c96ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 13:43:56.1378 (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: AM5PR0701MB2658
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/a45TuQjvwEfplIIGNRxM8e0-Jwg>
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 13:44:11 -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 <bcause-bounces@ietf.org> On Behalf Of Mach Chen
Sent: Friday, March 29, 2019 9:14 AM
To: Gregory Dalle <gdalle@juniper.net>
Cc: bcause@ietf.org; trammell@tik.ee.ethz.ch; David Sinicrope <david.sinicrope@ericsson.com>
Subject: Re: [bcause] Inter SDO relationship considerations

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
发件人:Gregory Dalle <gdalle@juniper.net<mailto:gdalle@juniper.net>>
收件人:Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>
抄 送:David Sinicrope <david.sinicrope@ericsson.com<mailto:david.sinicrope@ericsson.com>>;bcause@ietf.org <bcause@ietf.org<mailto:bcause@ietf.org>>;trammell@tik.ee.ethz.ch <trammell@tik.ee.ethz.ch<mailto:trammell@tik.ee.ethz.ch>>
时间:2019-03-29 13:31:02
主 题:Re: [bcause] Inter SDO relationship considerations

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 <mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:
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 <gdalle@juniper.net<mailto:gdalle@juniper.net>>
收件人:Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>>
抄 送:David Sinicrope <david.sinicrope@ericsson.com<mailto:david.sinicrope@ericsson.com>>;bcause@ietf.org<mailto:bcause@ietf.org> <bcause@ietf.org<mailto:bcause@ietf.org>>;trammell@tik.ee.ethz.ch<mailto:trammell@tik.ee.ethz.ch> <trammell@tik.ee.ethz.ch<mailto:trammell@tik.ee.ethz.ch>>
时间:2019-03-29 12:22:46
主 题:Re: [bcause] Inter SDO relationship considerations

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 <mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:
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<mailto:david.sinicrope@ericsson.com>>
收件人:bcause@ietf.org<mailto:bcause@ietf.org> <bcause@ietf.org<mailto:bcause@ietf.org>>
抄 送:trammell@tik.ee.ethz.ch<mailto:trammell@tik.ee.ethz.ch> <trammell@tik.ee.ethz.ch<mailto: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

--
bcause mailing list
bcause@ietf.org<mailto:bcause@ietf.org>
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=