Re: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework"

Haoyu Song <haoyu.song@futurewei.com> Wed, 23 October 2019 09:42 UTC

Return-Path: <haoyu.song@futurewei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF8B12007C; Wed, 23 Oct 2019 02:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=futurewei.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 2GFNw0sSqO2T; Wed, 23 Oct 2019 02:42:44 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710095.outbound.protection.outlook.com [40.107.71.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEC512013C; Wed, 23 Oct 2019 02:42:43 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VQJ3/AyEqVBv7rqh+IWxF3pyUgUX1mWQh79u8LFv20BfN4eWNDwTPkBWd/HHJZSOvh1IH28VTUTSuc8XWf5mUtofHZbz/YeX01ExdWtYKM8AfODKdsA+UA+BeZ9rwD5NB7jkmBxm/eyByIp2m1TXVDASEYvgL9yWiN+hE/S2cfFB7QlgfZ2Yd/MO5josbLHczaZrbNkq+9d0FzKmGBvsORIuYRrmKpZ5VGoY0CmH6jdXpU/VMOxu83qXq9G8dBOP+OMxt3Or1C1k8QQE2lM9ooYPKLomjs0p2MNVsc+PoNR8paiAvnn5JPbjHgozt8vUEwI9OTZHlB/uj/hgTYx13A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5zAyn2GCPBvrs2UErZrbPgUBQyeZW62jIGOkcEjrhmo=; b=aI03tUIR/3cqFGcE/wHb2a53xtH9bqIvceuqk3iBz8qzUk65/eIyEdTZPrYs1CJk6dKBrZkDw5Lt2AlxjIaBSfJond4kgNdetrds4O52wV/Yfbi6O02Ku8Ev5lWLCp3O8SkKiCilDSvCofcFTNEmggkzP1Cf+54Ap21AY5pnnbFH/nK05N+DxZqFQgVN6uuxYvoBADA9jSMlxgvmemwMGJCujiQuJHUBp8CwNrrpi4pcdahZJtnUFa1GL3sfkpq6EZLIZlJtMLM3DRg3Wk1nhXvLj6S3jSoQk+6nPkxg0JGlhCeMtHXwlbC2/67B6gh8GxQgnwoPVuDXkCLUXStEsg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5zAyn2GCPBvrs2UErZrbPgUBQyeZW62jIGOkcEjrhmo=; b=qLpQQzS/rirhg3Z3xBCnI3um1J2dfPkRPKXZfd9AWhBDSlOOKRo1Sml5hGudH+KHLjAwHXMqCCt5s+srvaep5D/orrrHDnlQSFvbo6rEFxR+25zvUkrMvRCv06oMp/Hn8gKfI0dvPbc6FMsZe2uILRKzTDXNHDaTABOQimvdWIk=
Received: from MN2PR13MB3582.namprd13.prod.outlook.com (10.255.239.156) by MN2PR13MB3550.namprd13.prod.outlook.com (10.255.86.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Wed, 23 Oct 2019 09:42:39 +0000
Received: from MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::6dcb:88a5:b3a9:e05c]) by MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::6dcb:88a5:b3a9:e05c%4]) with mapi id 15.20.2387.021; Wed, 23 Oct 2019 09:42:39 +0000
From: Haoyu Song <haoyu.song@futurewei.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
CC: "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Call for Adoption "draft-song-opsawg-ifit-framework"
Thread-Index: AdWIPU+fXC2Ur2/eToSt25eWIbGNawA7WsCAABXPfMA=
Date: Wed, 23 Oct 2019 09:42:39 +0000
Message-ID: <MN2PR13MB3582F5DE1E19E3E527F548BF9A6B0@MN2PR13MB3582.namprd13.prod.outlook.com>
References: <MN2PR13MB3582AA710325EACBD734848D9A690@MN2PR13MB3582.namprd13.prod.outlook.com> <46C6D387-72D9-4A90-9C07-5775B6A426D7@cisco.com>
In-Reply-To: <46C6D387-72D9-4A90-9C07-5775B6A426D7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=haoyu.song@futurewei.com;
x-originating-ip: [195.169.110.200]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9bd58ee7-4a7e-4fb0-3279-08d7579d57ea
x-ms-traffictypediagnostic: MN2PR13MB3550:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR13MB35508B76B14A3225C64305489A6B0@MN2PR13MB3550.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 019919A9E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(366004)(136003)(346002)(396003)(39850400004)(199004)(189003)(9326002)(7736002)(55016002)(6436002)(86362001)(6306002)(9686003)(54896002)(81166006)(25786009)(81156014)(66946007)(74316002)(236005)(229853002)(476003)(66066001)(33656002)(66476007)(66556008)(64756008)(66446008)(76116006)(6246003)(8676002)(53546011)(4326008)(44832011)(102836004)(6506007)(8936002)(76176011)(54906003)(316002)(26005)(5660300002)(52536014)(71190400001)(71200400001)(14444005)(7696005)(256004)(99286004)(486006)(6116002)(2906002)(3846002)(14454004)(446003)(6916009)(478600001)(966005)(11346002)(186003)(606006)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB3550; H:MN2PR13MB3582.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /moAUlqcFVHszSYhFpK52sBNspeKui3EA+W+BxO1lcQSb/UEqUP8CH5vf987uBSG+gFBJp1wbPNmwo9r7HyYt4vPxxu5mhOwNExxn5xnhICjlq2lK4V1wo06tifJWXrE2Tjlo9mhFN6jeFJ/MLrAWT3bgS0EcbcDbjR1aiGd5cteIh4f7up/HPtC0lyIQlzHeff/ToSjwkUVcfRF1cOg8lMV7jtLuV1hgHICCYBdOy9X7Z4+p/QGHtxjMyfCWaVpvNqc55vF0IFXlPnDDc879qtF+VLXWkdkc0UpFhvmX+J6JInLB9dyzu96QbT1OJRidEnoW5brbkoO/3UiKnX8TxJh5YlAITpvU9RLnxqkPM3OTmiTGlKKGZH9eLx67i7LCmDQEWN1RN5mDEFVeYbHbsuAyk4nP5pP0CYADBO1Ct2VgYuCsROASo3Svpmbn0M0PqcO+Wj8K0gtwJtTwPJbq6AQs5i6Dak6Tmta4rjD+7w=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3582F5DE1E19E3E527F548BF9A6B0MN2PR13MB3582namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bd58ee7-4a7e-4fb0-3279-08d7579d57ea
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 09:42:39.1323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DaBZQyKSANbFCb5vi96YcE79RF54vUMrI9gbkKavKX+QfygZKszu3MG7IFx4FJfBMps8RMD1kReclNQrwQn63Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3550
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Ll9wLdyBujaKsghFWDk_k0y1QUY>
Subject: Re: [OPSAWG] Call for Adoption "draft-song-opsawg-ifit-framework"
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2019 09:42:46 -0000

Hi Joe,

Thank you for the detailed comments!

Let me try to explain the purpose of this draft better. Given the recent on-path data plane telemetry techniques and standard works, in this draft we discuss the deployment challenges and potential opportunities for applications. There is no such a document in IETF AFAIK and we feel it’s needed (also confirmed by some network operators who are interested in such techniques)

Most related standard proposals so far only defines the data plane protocol and lack considerations for a complete solution. To this end, we discuss various points that a solution should pay attention to and how these can be composed to support applications. Along with the discussion, we provide some examples and use cases to trigger new ideas.

We deliberately make iFIT an open framework and avoid introducing any new protocol and enforcing any specific approaches, because otherwise we are in danger to put unnecessary constraints on implementation approaches and hurt the possibility of innovation. While we mean to keep this document informational, we may consider to add more discussions on reference designs, operational experiences,  and best practices as you suggested.

Some points you raised below also deserves more detailed explanation, such as how to make an iFIT closed loop and how architecture and algorithm components can be composed to form such a loop. Perhaps a complete example can help to explain that. I’ll consider all this in future revisions.

In a sense, this document indeed aims to discuss the implementation, operational experiences, and best practices  of PBT, IOAM, and other similar techniques. We hope this document will trigger new drafts on management plane/control plane and innovative solutions.

Best regards,
Haoyu


From: Joe Clarke (jclarke) <jclarke@cisco.com>
Sent: Tuesday, October 22, 2019 3:48 PM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: opsawg-chairs@ietf.org; opsawg@ietf.org
Subject: Re: Call for Adoption "draft-song-opsawg-ifit-framework"

The comments below are from me as an individual contributor.

I have read the latest revision of this document.  I still do not have a clear idea of what it is solving, TBH.  It doesn’t define a new protocol, yet it makes claims about an architecture that implies a protocol between devices, a controller, and applications (see the figure in section 2).  In Section 3.2, iFIT is referenced as having an ability to cache or send accumulated data.  I don’t see how a framework can do this.  Nor do I see how a framework can dynamically load new data probes as mentioned in Section 3.3.  If this were a controller with an application architecture and specifications for component interoperability, perhaps, but I do not see that in this document.

In Section4, the document mentions a closed-loop for iFIT applications whereby applications can manage iFIT closed loops on top of a controller.  But again, I don’t see how.  Do the applications make API calls?  What calls do they make?  What makes it an “iFIT closed loop”?

Ultimately, the summary says that iFIT combines algorithmic and architectural schemes into the framework, but I don’t see where that is done in a specific, implementable way (e.g., in Section 3.1.2 you begin to describe how you can adaptively sample packets, but you talk about abstract signals to/from the controller).  Nor do I see how one would implement iFIT.  When I read the iFIT draft, I feel like I’m missing a normative chunk that explains how the various pieces of this framework are to interact in a well-specified manner.

It seems to me that perhaps a more useful document is one that focus on the implementation of PBT and/or IOAM, operational experiences, best practices, etc.

Joe


On Oct 21, 2019, at 14:34, Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:

Dear OPSAWG chairs,

The following draft has been extensively discussed and gone through six revisions. Network operators confirmed it is useful.
We believe the draft is mature enough to be adopted by the WG therefore we request the chairs to initiate the adoption call for this draft.
Thank you very much for the consideration!

https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7Cda0fc97e527c49ed97ff08d75741e18d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637073812783772433&sdata=rDJ4qcmsAD2IqXhKMGOh%2BEFnxFFdsxHHXGANBzcv0uI%3D&reserved=0>

Best regards,
Haoyu