Re: [Aeon] Next step, IETF 90?

Reinaldo Penno <rapenno@gmail.com> Mon, 21 July 2014 18:15 UTC

Return-Path: <rapenno@gmail.com>
X-Original-To: aeon@ietfa.amsl.com
Delivered-To: aeon@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E48D1A02F6; Mon, 21 Jul 2014 11:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level:
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=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_9_22u0MH1m; Mon, 21 Jul 2014 11:15:36 -0700 (PDT)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CF01A0336; Mon, 21 Jul 2014 11:15:36 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id q107so5846904qgd.12 for <multiple recipients>; Mon, 21 Jul 2014 11:15:35 -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 :references:in-reply-to:content-type; bh=rtsdu2V8eQ/eJYRfxpqVflKkvl992b1xSkRA0QDYJ3c=; b=N1abiEDD1MICLq+5nM2yMjrQ7yHYYbtOQhSIjH0xnFl+KAfjmKBdvJygt+AVO0n5ff qUPtGFr6U4XzGKLCnV+Cljs0Zh1ALhMBMebGAsh4rsfK+PsdFlItI2VN2XfFWYyqlpIk cCMZRHxfhntNTWplyuhtMRirlR9mkNiT3cjnF+T3mcbVrlXj55lv9HcifXu774JNffL2 YMmJgwackYdVuT/sQwe6g+BocEMLOTBpCVDhTQhX8T4rzMIlDRqbIuEvfKA9iAJH/c4a XMQ/RJg+KkI2/G7gVmQ3LaQq45AU0BXLVnm+puCBl4zQ5zBNWpb1NUfjOBiU5PwbD4Gl VV8w==
X-Received: by 10.224.163.83 with SMTP id z19mr46718306qax.68.1405966535164; Mon, 21 Jul 2014 11:15:35 -0700 (PDT)
Received: from [10.82.208.178] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id d7sm26949987qae.29.2014.07.21.11.15.32 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 11:15:33 -0700 (PDT)
Message-ID: <53CD58C9.80000@gmail.com>
Date: Mon, 21 Jul 2014 14:15:37 -0400
From: Reinaldo Penno <rapenno@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: karagian@cs.utwente.nl, Tina.Tsou.Zouting@huawei.com, fanpeng@chinamobile.com, eckelcu@cisco.com
References: <EA4C43BE752A194597B002779DF69BAE23B3DD5C@ESESSMB303.ericsson.se> <00bb01cf95f7$e9ef2b60$bdcd8220$@chinamobile.com> <33687996-B978-4CC8-891C-0917907EC089@huawei.com> <CAKEbE1ZXgxd+ANkrjFeEi5pYTOMcf-tVHmNuKBSK65pzRi=3Kg@mail.gmail.com> <C0E0A32284495243BDE0AC8A066631A8183D6C82@szxeml557-mbs.china.huawei.com> <FF1A9612A94D5C4A81ED7DE1039AB80F4F496A68@EXMBX23.ad.utwente.nl> <CFE16C01.2D462%eckelcu@cisco.com>, <00e701cf9b74$41ddf2d0$c599d870$@chinamobile.com> <FF1A9612A94D5C4A81ED7DE1039AB80F5D5729AF@EXMBX23.ad.utwente.nl>, <005401cf9ce0$f1e9c330$d5bd4990$@chinamobile.com> <FF1A9612A94D5C4A81ED7DE1039AB80F5D572B35@EXMBX23.ad.utwente.nl> <C0E0A32284495243BDE0AC8A066631A81840C2A4@szxeml557-mbs.china.huawei.com> <C0E0A32284495243BDE0AC8A066631A818429453@szxeml557-mbs.china.huawei.com>, <53CD5108.6050203@gmail.com> <FF1A9612A94D5C4A81ED7DE1039AB80F5D57A577@EXMBX24.ad.utwente.nl>
In-Reply-To: <FF1A9612A94D5C4A81ED7DE1039AB80F5D57A577@EXMBX24.ad.utwente.nl>
Content-Type: multipart/alternative; boundary="------------030804040105010401030706"
Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/6mmYYffotaJyn5iygYC5GCI8O5Q
Cc: Szilveszter.Nadas@ericsson.com, aeon@ietf.org, Openv6@ietf.org
Subject: Re: [Aeon] Next step, IETF 90?
X-BeenThere: aeon@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Enabled Open Networking \(AEON\)" <aeon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aeon>, <mailto:aeon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aeon/>
List-Post: <mailto:aeon@ietf.org>
List-Help: <mailto:aeon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aeon>, <mailto:aeon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 18:15:43 -0000

Are you working on the wire protocol? it is not clear from proposal. If 
there is no on the wire protocol, then IETF is not place for such work.

On 7/21/14, 2:09 PM, karagian@cs.utwente.nl wrote:
>
> Hi Reinaldo,
>
> Please note that APONF is not used to directly control network 
> devices. So APONF is not talking to network devices, while AECON does!
>
> Best regards,
>
> Georgios
>
> ------------------------------------------------------------------------
> *Van:* Reinaldo Penno [rapenno@gmail.com]
> *Verzonden:* maandag 21 juli 2014 19:42
> *Aan:* Tina TSOU; Karagiannis, G. (EWI); fanpeng@chinamobile.com; 
> eckelcu@cisco.com
> *CC:* Szilveszter.Nadas@ericsson.com; aeon@ietf.org; Openv6@ietf.org
> *Onderwerp:* Re: [Aeon] Next step, IETF 90?
>
> These two proposals are exactly the same. No amount of make-up can 
> hide this fact. There is no way to distinguish them unless you are in 
> denial.
>
> Let me give some examples: Opendaylight can use REST to control 
> network devices. Endpoints also use REST to control network devices.
>
> Opendaylight uses notification to find more about the network and 
> topology. Endpoints also use notifications (REST has SSE and PCP has 
> unsolicited notifications and so on and so forth).
>
> Opendaylight installs network policies (which can be *anything*, it is 
> a very loose term), Endpoints can also install policies.
>
> Both want to achieve exactly the same thing and a name change 
> (endpoint vs. nms or whatever) will not make any difference since 
> protocols, encoding are all the same.  I can clearly see why the IESG 
> was right in not allowing these to go forward and will probably give 
> the same verdict
>
> thanks,
>
>
> On 7/21/14, 1:01 PM, Tina TSOU wrote:
>>
>> Dear all,
>>
>> Attached is the current -01 version of update on AECON and APONF slides.
>>
>> I noticed 3 meetings lined up from Monday to Wednesday.
>>
>> Monday:
>>
>> 8:30pm-10:30pm, Room Quebec (open to everyone)
>>
>> APONF Bar BoF
>>
>> Tuesday:
>>
>> 12:00pm, Room York
>>
>> AECON and APONF proposals discussions (_invitation only_)
>>
>> Wednesday:
>>
>> 11:45am-12:45pm, Room TBD (open to everyone)
>>
>> AECON Bar BoF
>>
>> Thank you,
>>
>> Tina
>>
>> *From:*Aeon [mailto:aeon-bounces@ietf.org] *On Behalf Of *Tina TSOU
>> *Sent:* Tuesday, July 15, 2014 5:22 AM
>> *To:* karagian@cs.utwente.nl; fanpeng@chinamobile.com; 
>> eckelcu@cisco.com; rapenno@gmail.com
>> *Cc:* Szilveszter.Nadas@ericsson.com; aeon@ietf.org; Openv6@ietf.org
>> *Subject:* Re: [Aeon] Next step, IETF 90?
>>
>> Dear all,
>>
>> Attached pls find a short version of slides mentioned below.
>>
>> Thank you,
>>
>> Tina
>>
>> *From:*karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl> 
>> [mailto:karagian@cs.utwente.nl]
>> *Sent:* Friday, July 11, 2014 4:59 PM
>> *To:* fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>; 
>> eckelcu@cisco.com <mailto:eckelcu@cisco.com>; Tina TSOU; 
>> rapenno@gmail.com <mailto:rapenno@gmail.com>
>> *Cc:* Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>; aeon@ietf.org 
>> <mailto:aeon@ietf.org>; Openv6@ietf.org <mailto:Openv6@ietf.org>
>> *Subject:* RE: [Aeon] Next step, IETF 90?
>>
>> Hi Peng,
>>
>> Thanks for informing me about the comments of Charles. I have replied 
>> to his comments in a previous email!
>>
>> According to the comments of Charles, see also my reply to his email, 
>> IMHO the main differencs between APONF and AECON are:
>>
>> => AECON works on interfaces and mapping between application flow 
>> descriptions provided by end user applications <=> netwok entities, 
>> that provide feedback to the end user application regarding network 
>> conditions and anticipated handling of the application's flows.
>>
>> => in the context of AECON application flow descriptions are provided 
>> by end user applications, without that the end user application have 
>> knowledge of any network attributes
>>
>> => APONF works on interfaces and mapping between network service 
>> graphs that include attributes such as topology, flow treatment 
>> policies, IPv6 transition policies) (known to the network management 
>> application systems (e.g.OSS)) <=> network management policies, i.e., 
>> device configuration Models.
>>
>> => in the context of APONF:  end user application developers can use 
>> information that will be provided
>>
>> by network management applications, such as netwrok service graph 
>> attributes in order to optimally design their end user applications.
>>
>> AECON will not support this, but AECON can help here on the 
>> definition of the flow treatment policies required by end user 
>> applications
>>
>> Best regards,
>>
>> Georgios
>>
>> ------------------------------------------------------------------------
>>
>> *Van:*Fan, Peng [fanpeng@chinamobile.com]
>> *Verzonden:* vrijdag 11 juli 2014 10:20
>> *Aan:* Karagiannis, G. (EWI); eckelcu@cisco.com 
>> <mailto:eckelcu@cisco.com>; Tina.Tsou.Zouting@huawei.com 
>> <mailto:Tina.Tsou.Zouting@huawei.com>; rapenno@gmail.com 
>> <mailto:rapenno@gmail.com>
>> *CC:* Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>; aeon@ietf.org 
>> <mailto:aeon@ietf.org>; Openv6@ietf.org <mailto:Openv6@ietf.org>
>> *Onderwerp:* RE: [Aeon] Next step, IETF 90?
>>
>> Hi Georgios,
>>
>> Please see my reply Inline [FP], thanks.
>>
>> *From:*karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl> 
>> [mailto:karagian@cs.utwente.nl]
>> *Sent:* Friday, July 11, 2014 2:40 PM
>> *To:* fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>; 
>> eckelcu@cisco.com <mailto:eckelcu@cisco.com>; 
>> Tina.Tsou.Zouting@huawei.com <mailto:Tina.Tsou.Zouting@huawei.com>; 
>> rapenno@gmail.com <mailto:rapenno@gmail.com>
>> *Cc:* Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>; aeon@ietf.org 
>> <mailto:aeon@ietf.org>; Openv6@ietf.org <mailto:Openv6@ietf.org>
>> *Subject:* RE: [Aeon] Next step, IETF 90?
>>
>> Hi Peng,
>>
>> Thank you very much!
>>
>> From what I understood, I think that we are in agreement that:
>>
>> AECON works on interfaces and mapping between the configuration 
>> intent coming from end user applications <=> network configuation & 
>> network topology known to the network management application systems 
>> (e.g. OSS)
>>
>> APONF works on interfaces and mapping between network configuation & 
>> network topology (known to the network management application systems 
>> (e.g.OSS)) <=> network management policies, i.e., device 
>> configuration Models.
>>
>> */[FP] I believe Charles and I have stated in the previous emails 
>> that AECON is NOT about network configuration, so is not going to 
>> satisfy end user applications’ configuration intent (if they have 
>> such intent). Charles gave some clarification in the thread of 
>> commenting APONF problem statement draft on openv6 mailing list and I 
>> hope that would help APONF architecture evolvement./*
>>
>> Regarding your suggestion on replacing that term "application" from 
>> the name of the APONF activity,
>>
>> you are right, but we prefer to do this after we get the Okay from 
>> the IESG that we are on the right track!
>>
>> Regarding the AECON-APONF discussion meeting that has been proposed 
>> by Eliot and Ted,
>>
>> maybe it will be good to prepare and have some slides.
>>
>> From APONF side we will prepare few slides that describe APONF
>>
>> Moreover, Tina is preparing a presentation that shows the differences 
>> between AECON and APONF.
>>
>> It will be great if you could have a presentation that describes AECON.
>>
>> */[FP] We will, as scheduled./*
>>
>> Moreover, it will be great if you could provide comments, input to 
>> the slides that are prepared by Tina on the AECON-APONF differences.
>>
>> */[FP] You are welcome to send me slides from your side prior to the 
>> meeting./*
>>
>> */Best regards,/*
>>
>> */Peng/*
>>
>> Best regards,
>>
>> Georgios
>>
>> ------------------------------------------------------------------------
>>
>> *Van:*Aeon [aeon-bounces@ietf.org] namens Fan, Peng 
>> [fanpeng@chinamobile.com]
>> *Verzonden:* woensdag 9 juli 2014 14:49
>> *Aan:* 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI); 
>> Tina.Tsou.Zouting@huawei.com <mailto:Tina.Tsou.Zouting@huawei.com>; 
>> rapenno@gmail.com <mailto:rapenno@gmail.com>
>> *CC:* Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>; aeon@ietf.org 
>> <mailto:aeon@ietf.org>; Openv6@ietf.org <mailto:Openv6@ietf.org>
>> *Onderwerp:* Re: [Aeon] Next step, IETF 90?
>>
>> Hi Tina, Georgios,
>>
>> First, I agree with Charles on the comments on both difference 
>> between AECON and APONF and charter of APONF. AECON aims to be a 
>> quite lightweight method focusing on information exchange, and 
>> neither application nor network is entitled to make any change to 
>> each other, which has not changed ever since the very beginning of 
>> this proposal. AECON is not quite related with “configuring” the network.
>>
>> Speaking of the difference between the two proposals you gave in this 
>> thread, I recall the saying I received a month ago when I first knew 
>> about APONF: “APONF is about specialized applications *managing* the 
>> network, not general applications using it”, and I have to say that I 
>> would rather use that version if I had to choose one from the two.
>>
>> So it is really important that we figure out clearly what we want to 
>> do in the respective proposals. I see that drafts and charter of 
>> APONF has been evolving, and I guess the APONF concept and boundary 
>> is developing too. My understanding is that perhaps you are working 
>> on some kind of north-bound application (specialized application) in 
>> an SDN like architecture, and targeting on network management and 
>> configuration (I also saw the target area was changed to OPS), and if 
>> that is true is it possible to specify it in the charter and limit 
>> the scope as e.g. north-bound network management method? The wording 
>> “application” is somewhat misleading especially to people not 
>> familiar with our proposals as it is not generally used to say 
>> “specialized application”.
>>
>> Before we have a clear picture of the proposal, I would not try to 
>> place AECON into an APONF architecture. Maybe AECON can be used to 
>> help APONF work, but that depends on how APONF is working. As for 
>> now, I would regard it as an effective and straightforward way to 
>> convince people that there is no overlap or connection between the 
>> two proposals.
>>
>> Best regards,
>>
>> Peng
>>
>> *From:*Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
>> *Sent:* Wednesday, July 09, 2014 1:05 AM
>> *To:* karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl>; 
>> Tina.Tsou.Zouting@huawei.com <mailto:Tina.Tsou.Zouting@huawei.com>; 
>> rapenno@gmail.com <mailto:rapenno@gmail.com>
>> *Cc:* Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>; aeon@ietf.org 
>> <mailto:aeon@ietf.org>; fanpeng@chinamobile.com 
>> <mailto:fanpeng@chinamobile.com>; Openv6@ietf.org 
>> <mailto:Openv6@ietf.org>
>> *Subject:* Re: [Aeon] Next step, IETF 90?
>>
>> Hi Tina and Georgios,
>>
>> I mostly agree with your statements differentiating APONF and AECON. 
>> However, there are a few things that I think create confusion. Please 
>> see inline.
>>
>> *From: *"karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl>" 
>> <karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl>>
>> *Date: *Thursday, July 3, 2014 at 12:25 AM
>> *To: *"Tina.Tsou.Zouting@huawei.com 
>> <mailto:Tina.Tsou.Zouting@huawei.com>" <Tina.Tsou.Zouting@huawei.com 
>> <mailto:Tina.Tsou.Zouting@huawei.com>>, "rapenno@gmail.com 
>> <mailto:rapenno@gmail.com>" <rapenno@gmail.com 
>> <mailto:rapenno@gmail.com>>
>> *Cc: *"Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>" 
>> <Szilveszter.Nadas@ericsson.com 
>> <mailto:Szilveszter.Nadas@ericsson.com>>, "aeon@ietf.org 
>> <mailto:aeon@ietf.org>" <aeon@ietf.org <mailto:aeon@ietf.org>>, 
>> "fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>" 
>> <fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>>, 
>> "Openv6@ietf.org <mailto:Openv6@ietf.org>" <Openv6@ietf.org 
>> <mailto:Openv6@ietf.org>>
>> *Subject: *Re: [Aeon] Next step, IETF 90?
>>
>>     Hi all.
>>
>>     The use of SCF/SFP in the charter is to show that APONF will use
>>     any guidelines/modeling language that will be proposed by the SCF
>>     WG on creating/modifying SCF/SFPs service templates.
>>
>>     Regarding AECON and APONF, I agree with Tina:
>>
>>     AECON works on interfaces and mapping between the configuration
>>     intent coming from end user applications <=> network configuation
>>     & network topology known to the network management application
>>     systems (e.g. OSS)
>>
>> AECON is about communication between end user applications and the 
>> network; however, it is NOT about network configuration. With AECON, 
>> end user applications (NOT network management applications) describe 
>> their flows to the network without any knowledge of the configuration 
>> of the network, nor any authority to change that configuration. 
>> Network entities provide feedback to the end user application 
>> regarding network conditions and anticipated handling of the 
>> application's flows. Network configuration information is NOT shared 
>> with the applications. Network configuration and network management 
>> are outside of the scope of AECON.
>>
>>     APONF works on interfaces and mapping between network
>>     configuation & network topology (known to the network management
>>     application systems (e.g.OSS)) <=> network management policies,
>>     i.e., device configuration Models.
>>
>> In that case, I have a few suggestions regarding the charter. Please 
>> see inline.
>>
>>     Best regards,
>>
>>     Georgios
>>
>>     ------------------------------------------------------------------------
>>
>>     *Van:*Openv6 [openv6-bounces@ietf.org
>>     <mailto:openv6-bounces@ietf.org>] namens Tina TSOU
>>     [Tina.Tsou.Zouting@huawei.com <mailto:Tina.Tsou.Zouting@huawei.com>]
>>     *Verzonden:* donderdag 3 juli 2014 6:08
>>     *Aan:* Reinaldo Penno
>>     *CC:* Szilveszter Nadas; aeon@ietf.org <mailto:aeon@ietf.org>;
>>     Fan, Peng; Openv6@ietf.org <mailto:Openv6@ietf.org>
>>     *Onderwerp:* Re: [Openv6] [Aeon] Next step, IETF 90?
>>
>>     Dear Reinaldo, Michael et al,
>>
>>     Good catch!
>>
>>     I just pulled things together into a charter, while talking to
>>     the proponents, below was what I understood.
>>
>>     Regarding SFC/SFP in the charter, the original idea was to make
>>     use of this concept to describe network topology and traffic
>>     path. However, this obviously brought confusion. What APONF needs
>>     is, for example, a distributed data center application (traffic
>>     engineering between data centers) may need the network topology
>>     and traffic path, so it can require the APONF to re-configure the
>>     related network nodes of the path to achieve its goal.
>>
>>     Perhaps another version of charter is needed to clarify this.
>>
>>     AECON works on interfaces and mapping between the configuration
>>     intent coming from end user applications <=> network configuation
>>     & network topology known to the network management application
>>     systems (e.g. OSS)
>>
>>     APONF works on interfaces and mapping between network
>>     configuation & network topology (known to the network management
>>     application systems (e.g.OSS)) <=> network management policies,
>>     i.e., device configuration Models.
>>
>>     Thank you,
>>
>>     Tina
>>
>>     *From:*Reinaldo Penno [mailto:rapenno@gmail.com]
>>     *Sent:* Thursday, July 03, 2014 1:06 AM
>>     *To:* Tina TSOU
>>     *Cc:* Fan, Peng; Szilveszter Nadas; aeon@ietf.org
>>     <mailto:aeon@ietf.org>; Openv6@ietf.org <mailto:Openv6@ietf.org>
>>     *Subject:* Re: [Aeon] Next step, IETF 90?
>>
>>     To the untrained eye there is a lot of overlap unless I'm not
>>     reading correctly.
>>
>>     "b) Specify a new NSLP (NSIS Signaling Layer Protocol), similar
>>     to the NAT/Firewall NSLP and QoS NSLP that can be applied and
>>     support the APONF use cases. "
>>
>>     "
>>
>>     o) specify extensions to the IETF NSIS protocol to distribute the
>>     SFP based network configuration and network topology models
>>     between network management applications (e.g., OSS applications)
>>     and e.g., the network management system, the routing controlling
>>     system or other controlling systems. The IETF Next Steps in
>>     Signaling (NSIS) protocol may be extended in two ways to support
>>     this interface:
>>
>>     a) Extend NSIS GIST to be used for off-path support"
>>
>>     I believe the more fragmented these initiatives are, more
>>     confusion to IESG. The paragraphs above would be enough confusion
>>     to anyone.
>>
>>     SFC WG has both data plane and control plane work in the charter.
>>     Nothing preclude to have modeling of services policies as one of
>>     the charter items in AEON
>>
>>     On Wed, Jul 2, 2014 at 7:06 AM, Tina TSOU
>>     <Tina.Tsou.Zouting@huawei.com
>>     <mailto:Tina.Tsou.Zouting@huawei.com>> wrote:
>>
>>     Dear Peng, Szilveszter, et al,
>>
>>     There is a connection between AECON and APONF, but no overlapping.
>>
>>     See below the current APONF draft charter.
>>
>>     *From:* Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of
>>     *Tina TSOU
>>     *Sent:* Monday, June 30, 2014 5:51 PM
>>     *To:* karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl>;
>>     jsaldana@unizar.es <mailto:jsaldana@unizar.es>; Openv6@ietf.org
>>     <mailto:Openv6@ietf.org>
>>     *Subject:* Re: [Openv6] Is there a draft charter for APONF?
>>
>>     Dear all,
>>
>>     Based on everybody’s feedback, here comes the 3^rd  version of
>>     the charter.
>>
>>     Hope it is more precise and concrete for you to comment on.
>>
>>     ------------------------------------
>>
>>     *APONF (Application-based Policy for Network Functions) charter*
>>
>>     Target Area: Operations and Management Area
>>
>>     Description of Working Group:
>>
>>     Today network operators are challenged to create an abstract view
>>     of their network infrastructure and help service developers on
>>     using and programming this
>>
>> I find the term “service developers” confusing. How about replacing 
>> this with “developers of network management applications”.
>>
>>     abstraction rather than manipulating individual devices. An
>>     abstract view of a network infrastructure can be realized using 
>>     a network configuration model, that provides a declarative
>>     configuration and a network topology model that describes a
>>     multi-layer network. Network management applications are
>>     Operational Support System (OSS) like applications that help a
>>     communication service provider to monitor, control, analyze and
>>     manage a communication network.
>>
>>     In this context, network management applications can be used to
>>     provide the required configuration and application programming
>>     interfaces to such service developers. Subsequently, a network
>>     management application can use the application based demands and
>>     possibly update its associated network configuration and/or
>>     network topology model. Examples of network management
>>     applications that can modify the network configuration and/or
>>     network topology models are for example, virtual network function
>>     services, Distributed Data Center Application, IPv6 transitions,
>>     streaming and IoT applications, need to change the network
>>     infrastructure configuration.
>>
>>     The updated network configuration and network topology model
>>     needs to be communicated to e.g., the network management system,
>>     the routing controlling system or other controlling systems, to
>>     map the network configuration and network topology models into
>>     specific device level configuration models.
>>
>>     Currently, there are no IETF standard mechanisms or modeling
>>     languages that can directly be applied to model the network
>>     configuration nor the network topology. IETF has however, created
>>     the IETF SFC WG to document a new approach to service delivery
>>     and operation, where one of its goals is to realize an abstract
>>     view of a network by using a service graph denoted as the Service
>>     Function Path (SFP). This will enable the development of suitable
>>     models for network configuration and network topology.
>>
>>     Furthermore, there are currently no IETF solutions that can be
>>     used to provide the necessary configuration interfaces to service
>>     developers to program the abstract view of a network
>>     infrastructure. Currently, the Application Enabled Collaborative
>>     Network (AECON) activity can provide these necessary solutions.
>>
>> Same comment as above about developers. More importantly, I do not 
>> see AECON providing a solution for programming network 
>> infrastructure. This seems more in the realm of SDN and/or SFC.
>>
>>     Moreover, there are no IETF solutions that can directly be used
>>     to (1) enable the streaming transfer of bulk-variable/data of
>>     network configuration and network topology models between network
>>     management application systems and e.g., the network management
>>     system, the routing controlling system or other controlling
>>     systems, and (2) map the network configuration and network
>>     topology models into specific device level configuration models.
>>     The APONF activity can provide a solution to this challenge.
>>
>>     The main goal of APONF is to:
>>
>>     o) enable the streaming transfer of bulk-variable/data of the up
>>     to date SFP based network configuration and network topology
>>     models between network management application systems and e.g.,
>>     the network management system, the routing controlling system or
>>     other controlling systems, by using and extending the IETF Next
>>     Steps in Signaling Protocol (NSIS).
>>
>>     o) map the SFP based network configuration and network topology
>>     models into specific device level configuration models.
>>
>>     The APONF requirements/objectives are:
>>
>>     o) monitor and verify the freshness of the SFP based network
>>     configuration and network topology models
>>
>>     o) extend the IETF NSIS protocol to securely and efficiently
>>     distribute the SFP based network configuration and network
>>     topology models between network management applications (e.g.,
>>     OSS applications) and e.g., the network management system, the
>>     routing controlling system or other controlling systems
>>
>>     o) use application based demands generated by network management
>>     applications to map the SFP based network configuration and
>>     network topology models into specific device level configuration
>>     models. Such application based demands are:
>>
>>     a) Encapsulating, de-encapsulating packets associated with a flow
>>     into a tunnel (for example, VPN service, IPv6 transition service
>>     need to manage the network function to do that):
>>
>>     b) blocking, or dropping packets associated with a flow in (the
>>     edge of) the network element when the network security service is
>>     aware of the attack (for example, SAVI service, Anti-DoS service
>>     need to manage the network function to do that).
>>
>> In my mind, (a) and (b) are not configuration. Rather, they are 
>> actions based on configuration. AECON could come into play here by 
>> providing a description of a flow that is used to determine how best 
>> to handle that flow. The various options for handling the flow are 
>> based on network configuration, which is outside the scope of the 
>> AECON, whereas the identification of the flow such that it the most 
>> appropriate handling option is selected is within the scope for AECON.
>>
>> Cheers,
>>
>> Charles
>>
>>     c) configure and dynamically reconfigure data centers to the
>>     steer and reroute traffic associated with a specific flow
>>
>>     d) configure and dynamically reconfigure data centers to  change
>>     priorities of different types of traffic associated with a
>>     specific flow
>>
>>     e) Logging the traffic associated with a flow for network
>>     security service, optimization of the traffic in network for IETF
>>     ALTO service
>>
>>     f) other actions defined by the administrator
>>
>>     o) specify the Authentication Authorization and Accounting (AAA)
>>     method
>>
>>     Work items related to APONF include:
>>
>>     o) specify the problem statement and use cases
>>
>>     o) specify the APONF architecture
>>
>>     o) specify extensions to the IETF NSIS protocol to distribute the
>>     SFP based network configuration and network topology models
>>     between network management applications (e.g., OSS applications)
>>     and e.g., the network management system, the routing controlling
>>     system or other controlling systems. The IETF Next Steps in
>>     Signaling (NSIS) protocol may be extended in two ways to support
>>     this interface:
>>
>>     a) Extend NSIS GIST to be used for off-path support
>>
>>     b) Specify a new NSLP (NSIS Signaling Layer Protocol), similar to
>>     the NAT/Firewall NSLP and QoS NSLP that can be applied and
>>     support the APONF use cases.
>>
>>     o) map the SFP based network configuration and network topology
>>     models into specific device level configuration models
>>
>>     o) specify the AAA method.
>>
>>     Milestones:
>>
>>     I-D 'Problem Statement and Use Cases' as an Informational RFC.
>>
>>     I-D 'APONF Architecture' as an Informational RFC.
>>
>>     I-D 'Mapping SFP based models into specific device level
>>     configuration models' as an Informational RFC.
>>
>>     I-D 'APONF based NSIS Protocol Specification' Standards Track RFC.
>>
>>     --------------------------------------
>>
>>     Thank you,
>>
>>     Tina
>>
>>     -----------
>>
>>     Thank you,
>>
>>     Tina
>>
>>
>>     On Jul 2, 2014, at 9:17 PM, "Fan, Peng" <fanpeng@chinamobile.com
>>     <mailto:fanpeng@chinamobile.com>> wrote:
>>
>>         Hi all,
>>
>>         As you may noticed there is not a BOF this time at IETF90. We
>>         will be presenting on Tuesday during the IETF week to the
>>         IESG and IAB to address concerns and questions in regard to
>>         AECON and APONF, and have a barBOF/side meeting sometime
>>         after that.
>>
>>         We will update the information as soon as possible. Thank you
>>         all for making this list fruitful.
>>
>>         Best regards,
>>
>>         Peng
>>
>>         *From:*Aeon [mailto:aeon-bounces@ietf.org] *On Behalf Of
>>         *Szilveszter Nadas
>>         *Sent:* Monday, June 30, 2014 9:21 PM
>>         *To:* aeon@ietf.org <mailto:aeon@ietf.org>
>>         *Subject:* [Aeon] Next step, IETF 90?
>>
>>         Hi All,
>>
>>         I have seen that the BoF was not approved for IETF 90. Did
>>         you receive a more detailed explanation of the reasons?
>>
>>         What is the next step? Will there be a Bar BoF at Toronto?
>>
>>         Best Regards,
>>
>>         Szilveszter
>>
>>
>>     _______________________________________________
>>     Aeon mailing list
>>     Aeon@ietf.org <mailto:Aeon@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/aeon
>>
>