[Openv6] APONF next steps and Doodle poll for bar BOF during IETF 90

<karagian@cs.utwente.nl> Thu, 12 June 2014 14:35 UTC

Return-Path: <karagian@cs.utwente.nl>
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 D55A91B2A68 for <openv6@ietfa.amsl.com>; Thu, 12 Jun 2014 07:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 sJdDebIQDe1T for <openv6@ietfa.amsl.com>; Thu, 12 Jun 2014 07:35:53 -0700 (PDT)
Received: from out41-ams.mf.surf.net (out41-ams.mf.surf.net [145.0.1.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC4E1A012D for <openv6@ietf.org>; Thu, 12 Jun 2014 07:35:52 -0700 (PDT)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5CEZmB5028827; Thu, 12 Jun 2014 16:35:48 +0200
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 12 Jun 2014 16:35:51 +0200
Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 16:35:48 +0200
From: <karagian@cs.utwente.nl>
To: <openv6@ietf.org>
Thread-Topic: APONF next steps and Doodle poll for bar BOF during IETF 90
Thread-Index: AQHPhkuHmQMfsgFnMUawpwiUc/5DpA==
Date: Thu, 12 Jun 2014 14:35:46 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F4F47C9E5@EXMBX23.ad.utwente.nl>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [86.91.134.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN)
X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6
X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default)
X-Canit-Stats-ID: 0vMdqzMT9 - f050db76cfc6 - 20140612 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/XZ8OpaCXFtESDKsBE_-HZf4ROY0
Cc: sob@harvard.edu
Subject: [Openv6] APONF next steps and Doodle poll for bar BOF during IETF 90
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 14:35:56 -0000

Hi all,

Unfortunately,  is our APONF BOF request not approved for IETF 90. 
However, we received very positive and constructive feedback from the IESG and IAB via Spencer Dowkins (AD).

Currently we are studying carefully the feedback and will come back to you with a list of actions soon.

In addition to that, we would like to inform you that we are willing to organize a bar BOF during the IETF 90 in Toronto, in order to discuss and possibly solve any issues related to the next  steps that we have to take in order to satisfy the IESG and IAB recommendations.

In order to find a suitable day and time during the IETF 90, we created a Doodle poll, see below:

http://doodle.com/hbtkqvirfyqqteiz

Can you please fill in your availability dates as soon as possible and before the 1st of July 2014?

Kind regards,
Scott Bradner & Georgios Karagiannis


________________________________________
Van: Openv6 [openv6-bounces@ietf.org] namens Spencer Dawkins [spencerdawkins.ietf@gmail.com]
Verzonden: donderdag 12 juni 2014 5:59
Aan: openv6@ietf.org
CC: tsv-ads@tools.ietf.org; Ted Lemon
Onderwerp: [Openv6] Feedback on APONF BOF request

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

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