[Openv6] Feedback on APONF BOF request

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Thu, 12 June 2014 03:59 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 151641B29BA for <openv6@ietfa.amsl.com>; Wed, 11 Jun 2014 20:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 f-0AtpiFbov6 for <openv6@ietfa.amsl.com>; Wed, 11 Jun 2014 20:59:08 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5CF1B29B2 for <openv6@ietf.org>; Wed, 11 Jun 2014 20:59:08 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id i57so561911yha.15 for <openv6@ietf.org>; Wed, 11 Jun 2014 20:59:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=oCGy05dh/5MYvMKYpzdgcC1jHiABr5UTh8FM3/miqKk=; b=t232jUaWO7I1ykjqdo2ECx39/MJXuNy5ZCHCOIU27TdyKwAziEdsX4un6w9MDex+jD j9Si9Znmoxs+mWHeWZFVyM22YfdzGoNsry3torBivmIrYPvIMOitv9NjOV741CyYRMdj v0dFmoOsGFup7/7H+wO1NLTk7c4xTVruI8tFmspRrGsPjK9E4mjToPsRjG2pKt7Mstob iRgsMGk/WGuiXC1QjIEabdDwZIVhEN6dZf/PWNfWblezdDU5WAL+wH4rb7BI8kpEkGv4 5t6iDx1ZBOSN2Kz6wvC8W+pokRbLFSHwm0tc+JI+VnSdZjoxjDgZV2S4ooC7bhewF5XH 0VvA==
X-Received: by 10.236.204.33 with SMTP id g21mr11844184yho.92.1402545547625; Wed, 11 Jun 2014 20:59:07 -0700 (PDT)
Received: from [10.71.14.162] ([64.197.173.10]) by mx.google.com with ESMTPSA id a26sm21115626yho.0.2014.06.11.20.59.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 20:59:07 -0700 (PDT)
Message-ID: <53992588.9030109@gmail.com>
Date: Wed, 11 Jun 2014 22:59:04 -0500
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: openv6@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/Y-lNkIRIaCQ_ss-OEScIGaW0Pos
Cc: "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: [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 03:59:11 -0000

Dear APONF BOF requesters,

As the responsible AD for the APONF BOF request, I wanted to report back 
to you that the IESG and IAB reviewed the APONF BOF request, and decided 
that APONF wasn't ready for a BOF at IETF 90 in Toronto.

I can tell you that both the IESG and IAB members on the call took the 
request very seriously. I'm thinking we talked about APONF for close to 
half an hour and returned to it a couple of times during the call.

I have some suggestions for you, if you plan to continue to work on this 
proposal. I'll try to provide them in priority order.

Here are the points I noted during the discussion:

- 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.

- It would be good to perform a gap analysis on NSIS, and explain why 
NSIS can't be used to do what APONF wants to do.

- 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).

- 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.

- It's possible that distributed data center applications would be 
willing and able to take advantage of APONF, but the proposal would need 
to focus on those applications (rather than add them to an existing set 
of applications under consideration).

- More generally, the proposal was considered to be "too large for a 
single working group", so anything else you could remove would be helpful.

- 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.

I can also tell you that we talked about other "dynamically discovering 
and changing the configuration of parts of the Internet to support 
specified services at multiple layers using standard interfaces" 
proposals on the call, including AECON, ACTN, TIME, VFNCONF. (APONF got 
points because it was the only proposal that was aware of all the other 
proposals). The same concerns were raised again and again. Some members 
of the IAB were talking about whether an IAB workshop to resolve the 
questions that we asked about each specific proposal in a more general 
way. It would be helpful to talk to Brian Trammel (IAB) about this, in 
Toronto.

It's also worth noting that Jari would like to find some way to make 
progress on at least some of these proposals. We recommended an IETF 90 
side meeting of BOF proponents from as many of these proposals as makes 
sense, to look for commonalities and differences. I believe Ted is 
planning to meet with AECON requesters; if part of the conversation is 
making the difference between AECON and APONF more clear, perhaps 
talking to Ted about that meeting would be helpful.

I hope this is helpful, and best wishes if you move forward with this 
proposal.

Spencer