IETF Logo Mail Archive

[Anima] ANI Objectives-//RE: Calling new works and discussion

"Liubing (Leo)" <leo.liubing@huawei.com> Fri, 22 September 2017 08:44 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB81329B5; Fri, 22 Sep 2017 01:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 aug8N2CNkOZ5; Fri, 22 Sep 2017 01:44:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FBB132025; Fri, 22 Sep 2017 01:44:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPC06330; Fri, 22 Sep 2017 08:44:20 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 22 Sep 2017 09:44:19 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 22 Sep 2017 16:44:14 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Anima WG <anima@ietf.org>
CC: "anima-chairs@ietf.org" <anima-chairs@ietf.org>
Thread-Topic: ANI Objectives-//RE: Calling new works and discussion
Thread-Index: AdMzedrkJiBUYPFDRmSMErv9P4fgDg==
Date: Fri, 22 Sep 2017 08:44:14 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7B@nkgeml514-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.191.175]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C302AC7Bnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59C4CD65.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9b9805d7a65237d529b70f515a5e7702
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/6ggEfhcWQ7PHuUkPeNh1cGHumYc>
Subject: [Anima] ANI Objectives-//RE: Calling new works and discussion
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Sep 2017 08:44:26 -0000

Hi Dear all,

To response to the Chairs' calling, I'd like to firstly mention an existing work, draft-carpenter-anima-ani-objectives, which belongs to the first category as Sheng defined below:
> Leveraging the Current ANI (GRASP, ACP & BRISK)

It is very specific technical details (just like "option names" in other protocols) related to all ANI components (BRSKI, ACP and GRASP), but necessary for interoperability.
We used to have some discussion about whether to define these objectives in each ANI component. But there is two problems as I see:

1.      This draft defines an additional value for GRASP message syntax to indicate transport-protocol. So far it is actually used for BRSKI to indicate IP-in-IP encapsulation. However, from definition perspective, this value is generic than BRSKI-specific, so I'm not very sure it is proper to defined it in BRSKI.

2.      Technically, it is ok to define each GRASP-objective in each ANI document, but would it be a bit scattered?

In any case, I think the ANI objective content should reach consensus and be published as soon as possible.
Then, the problem again: shall we make it as a standalone draft, or incorporate them into each ANI draft?

Best regards,
Bing



From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Wednesday, September 20, 2017 5:39 PM
To: Anima WG <anima@ietf.org>
Cc: anima-chairs@ietf.org
Subject: [Anima] Calling new works and discussion

Hi, all ANIMA,

As we are sending more documents to IESG for publication, the group has delivered most of our original milestones without boiling the ocean. We are now in a little bit more confidence to explore slightly wider area of autonomic networking. We are now calling new works/work proposals. We would like to start to discuss new potential works and whether they are doable, whether they are worth to solve by ANIMA WG, whether ANIMA is the right WG for it, etc.

The below is three rough categories that may be interested by the group.


-        Leveraging the Current ANI (GRASP, ACP & BRISK)

-        ANI extension & other reusable components for AN

-        Autonomic Service Agents over ANI and other reusable components

Thanks and regards,

Sheng

v2.23.0 | Report a Bug | By Email