Re: [Openv6] Feedback on APONF BOF request

Linda Dunbar <linda.dunbar@huawei.com> Thu, 12 June 2014 16:43 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B17A1B2AA3 for <openv6@ietfa.amsl.com>; Thu, 12 Jun 2014 09:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 KXng8p6bB9n9 for <openv6@ietfa.amsl.com>; Thu, 12 Jun 2014 09:43:04 -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 C72EA1A0880 for <openv6@ietf.org>; Thu, 12 Jun 2014 09:43:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII95341; Thu, 12 Jun 2014 16:43:01 +0000 (GMT)
Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 17:43:01 +0100
Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 09:42:56 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, "openv6@ietf.org" <openv6@ietf.org>
Thread-Topic: [Openv6] Feedback on APONF BOF request
Thread-Index: AQHPhfLE3bIACOzwtkuUed8dGZhhDpttrB6g
Date: Thu, 12 Jun 2014 16:42:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D341E4@dfweml701-chm.china.huawei.com>
References: <53992588.9030109@gmail.com>
In-Reply-To: <53992588.9030109@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.147.229]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/3LRem6Egkh3UamXn7P-_FzPvaAw
Cc: "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [Openv6] Feedback on APONF BOF request
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jun 2014 16:43:09 -0000

Spencer, 

Thank you very much for the feedback. 
My comments to the IESG feedback are inserted below:

-----Original Message-----
From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Spencer Dawkins


- First and most important, we had the sense that something like APONF has been done in the past - specifically, NSIS. So the technical feasibility isn't in question. NSIS was completed, including interoperability testing at IETF meetings, so we know it's possible to do something like this.

[Linda] Some of the deliverables by AEON is truly covered by NSIS charter, (e.g. "middle box traversal protocol" by NSIS is what AEON try to do). But APONF is quite different. I have to say that we need a better and more accurate name than "APONF" to describe the initiative of APONF. 

- NSIS didn't get deployed after it was completed, because most application developers weren't interested in providing information to the network ("best effort was good enough"). The concern was that if only a small percentage of applications provide this information, it will cost more for carriers to deploy it (and modify back office systems to bill for it) than carriers can make selling the service. It would be good to explain why the situation is different in 2014 (and it may be different).

[Linda] The interface addressed by APONF will be very useful by IoT, sensor network, network services that using virtualized network functions to offer flexible services. Again, I agree, the use cases need to be more focused. 


- Most people speaking on the call thought it would be more likely that network management applications would provide information to the network, so you might consider limiting the scope of the proposal to network management applications, rather than including end user applications as the proposal does now.

[Linda] It might not be NMS, but maybe some controllers. Application to Network (controller) interface is much more realistic than Application to network elements interface. 

- Erik Nordmark asked where the trust boundaries were (is this entirely within an administrative domain, or interdomain? Does the network trust the application? Is the application controlling what the network does, or providing hints that the network would take into account, along with other inputs?). That would be helpful to explain in a bit more detail.
[Linda] absolutely. The security will be a big part of this initiative. 


Linda

_______________________________________________
Openv6 mailing list
Openv6@ietf.org
https://www.ietf.org/mailman/listinfo/openv6