[bcause] Short and long term goal

Liang GENG <liang.geng@hotmail.com> Wed, 27 March 2019 14:42 UTC

Return-Path: <liang.geng@hotmail.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 CCB4812004B for <bcause@ietfa.amsl.com>; Wed, 27 Mar 2019 07:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.125
X-Spam-Level:
X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 dg-B8wacFTqr for <bcause@ietfa.amsl.com>; Wed, 27 Mar 2019 07:42:30 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002109.outbound.protection.outlook.com [40.92.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F75612002F for <bcause@ietf.org>; Wed, 27 Mar 2019 07:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aSFgVKhjzTnYqslAbTIAK2UyWNcVqUKiGNCGE21MSlQ=; b=vPgASoboBdKCatqVCvI1Bu563r21Wci1WD2SBuiX2ur+6nbhzVkKWqMiOCISNHM4eINxTLZ1g3o3XbIlxPCTz0Ik/kE2ptdkHVp/y3kyd+8aGTeqr7PZrjhxmXYg0aNgXy/tZ+WtYoj8Xy4FIkbSIKva+emQhV0njcyynFmc1H7XyVSdhzNc+SC1scsOtP6xMonX5cpMHzI1eclCEAIRlkUJMBZJqGO+qUcTWX9WZ1GbqkG3u5ZNaxYuHUAxGXmfmZGkhMToA9mcLcw38MjqKWo4M/BZ58wFOCV1B8HMlguVdHnHzyPwDcCym4AEClpA7i2infmE2olh2zMWJe+mIg==
Received: from BY2NAM01FT038.eop-nam01.prod.protection.outlook.com (10.152.68.59) by BY2NAM01HT090.eop-nam01.prod.protection.outlook.com (10.152.69.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1750.16; Wed, 27 Mar 2019 14:42:28 +0000
Received: from BN6PR22MB0771.namprd22.prod.outlook.com (10.152.68.55) by BY2NAM01FT038.mail.protection.outlook.com (10.152.68.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1750.16 via Frontend Transport; Wed, 27 Mar 2019 14:42:28 +0000
Received: from BN6PR22MB0771.namprd22.prod.outlook.com ([fe80::d870:f2dd:13e7:a2aa]) by BN6PR22MB0771.namprd22.prod.outlook.com ([fe80::d870:f2dd:13e7:a2aa%6]) with mapi id 15.20.1750.014; Wed, 27 Mar 2019 14:42:28 +0000
From: Liang GENG <liang.geng@hotmail.com>
To: "bcause@ietf.org" <bcause@ietf.org>, 'Liang Geng | 耿亮' <gengliang@chinamobile.com>
Thread-Topic: Short and long term goal
Thread-Index: AQHU5J+7x2DfMtYUgkqHBJV632PtYA==
Date: Wed, 27 Mar 2019 14:42:28 +0000
Message-ID: <BN6PR22MB0771AD2F5A785C1B08318D8B87580@BN6PR22MB0771.namprd22.prod.outlook.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:F0E53DF656E588D6B06E21BCA5573F16D1355EECCFD4884082213BB75A91A668; UpperCasedChecksum:491558C03CB8E28A713BF8F5408145E481114AF2E5B9164301B4F1751BD1D857; SizeAsReceived:6766; Count:41
x-tmn: [1yJGZYEmelc+/LfpCfo2he5czMpGC1K1YwfKKpeX8lz6zCeTC2pQK+PERQyEihhU]
x-ms-publictraffictype: Email
x-incomingheadercount: 41
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:BY2NAM01HT090;
x-ms-traffictypediagnostic: BY2NAM01HT090:
x-microsoft-antispam-message-info: lEbh57aa7QA8zqB5kW1JYuQupAKqGepqIlAsy1fKBdBo5E3M6Z8OJG1i1LAfxoGo
Content-Type: multipart/alternative; boundary="_000_BN6PR22MB0771AD2F5A785C1B08318D8B87580BN6PR22MB0771namp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 29ab15b8-a965-4b13-2c5e-08d6b2c26f74
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2019 14:42:28.2087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT090
Archived-At: <https://mailarchive.ietf.org/arch/msg/bcause/V8IDEEJucItnB49ReXOxR6HL-sk>
X-Mailman-Approved-At: Fri, 29 Mar 2019 05:18:07 -0700
Subject: [bcause] Short and long term goal
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: Wed, 27 Mar 2019 14:42:32 -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