Re: [Aeon] Next step, IETF 90?
Reinaldo Penno <rapenno@gmail.com> Tue, 22 July 2014 16:19 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 5AC851A01F2; Tue, 22 Jul 2014 09:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 1yrHdfIbvvpt; Tue, 22 Jul 2014 09:19:03 -0700 (PDT)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A421A012D; Tue, 22 Jul 2014 09:19:02 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id v10so6920134qac.33 for <multiple recipients>; Tue, 22 Jul 2014 09:19:01 -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=4VDC+5ucoVBZaa8wuzImxSsI6pZoqJxk7ntaRDWdisg=; b=yEr9Snv+RGEPDNw0taI+gKA8fz2gb7mse9u7EPaRKCzu4HYCnPQWMabhMOqIBJk5jl +m66ip1IY007MtURqlfHC9Z4JzcUT/UOFsgF9kz5N9m3VIS0yoTaRKYG3ZgZDR6ERYwv jFeT8pyv5THrrd4FPLGOQlg3y6f9O4NEKIE85ldhcS/0ehzzVImo3V1HH5+tnTs9RicM bqkfPWpnEpJqw10twcHTN93u0v9CdZg8fhnFW2cfcCiTX7eas+7Cg95nbCM/BskGec14 5TQMgpDffjfXXKSewL9Vx0cucGwwY0wi6NIxJimleiH6jfKVTfddu//63qUxZ2ljGqqG P3jA==
X-Received: by 10.224.89.10 with SMTP id c10mr10918669qam.51.1406045941711; Tue, 22 Jul 2014 09:19:01 -0700 (PDT)
Received: from [10.82.217.50] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id s16sm1065384qay.23.2014.07.22.09.18.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 09:19:00 -0700 (PDT)
Message-ID: <53CE8EF0.2040508@gmail.com>
Date: Tue, 22 Jul 2014 12:18:56 -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: Tina TSOU <Tina.Tsou.Zouting@huawei.com>, "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>, "fanpeng@chinamobile.com" <fanpeng@chinamobile.com>, "eckelcu@cisco.com" <eckelcu@cisco.com>
References: <EA4C43BE752A194597B002779DF69BAE23B3DD5C@ESESSMB303.ericsson.se> <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>, <53CD58C9.80000@gmail.com> <FF1A9612A94D5C4A81ED7DE1039AB80F5D57B621@EXMBX24.ad.utwente.nl> <C0E0A32284495243BDE0AC8A066631A81842C91E@szxeml557-mbs.china.huawei.com> <C0E0A32284495243BDE0AC8A066631A818430123@szxeml557-mbs.china.huawei.com>
In-Reply-To: <C0E0A32284495243BDE0AC8A066631A818430123@szxeml557-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------030705070207060609090601"
Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/8LlyBemk7cUtiAfSTpQAly2fWhw
Cc: "Szilveszter.Nadas@ericsson.com" <Szilveszter.Nadas@ericsson.com>, "aeon@ietf.org" <aeon@ietf.org>, "Openv6@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: Tue, 22 Jul 2014 16:19:11 -0000
Maybe you should put in some slide the difference between APONF and I2RS because there are I2RS draft covering exactly what are on the slide notes. On 7/22/14, 12:02 PM, Tina TSOU wrote: > > Dear all, > > Attached please find today’s meeting slides -03 version. > > Thank you, > > Tina > > *From:*Aeon [mailto:aeon-bounces@ietf.org] *On Behalf Of *Tina TSOU > *Sent:* Monday, July 21, 2014 9:16 PM > *To:* karagian@cs.utwente.nl; rapenno@gmail.com; > fanpeng@chinamobile.com; eckelcu@cisco.com > *Cc:* Szilveszter.Nadas@ericsson.com; aeon@ietf.org; Openv6@ietf.org > *Subject:* Re: [Aeon] Next step, IETF 90? > > Dear all, > > I enclose the “AECON and APONF” slides -02 version for your reference. > > It has been reviewed by proponents of both AECON and APONF. > > Thank you, > > Tina > > *From:*karagian@cs.utwente.nl <mailto:karagian@cs.utwente.nl> > [mailto:karagian@cs.utwente.nl] > *Sent:* Monday, July 21, 2014 4:43 PM > *To:* rapenno@gmail.com <mailto:rapenno@gmail.com>; Tina TSOU; > fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>; > eckelcu@cisco.com <mailto:eckelcu@cisco.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 Reinaldo, > > Not sure if I understand your remark! > > APONF is obviously working on an IETF based protocol that provides the > interface between network managent application systems, like OSS > systems, to network management and controling systems (the decision > points). > > The main goal and a short description of APONF is provided in the text > below! > > Regarding my previous email, please note that I wanted to emphasize > that APONF is not providing an interface from/to user plane network > elements (where the network managent policy is enforced). This is out > of the scope of APONF. > > Please note that I do not know which APONF documents have you read! > > The latest versions of the APONF documents can be found below: > > > APONF¶ > <http://trac.tools.ietf.org/bof/trac/#APONFNotApprovedforIETF90> > > * Long name and abbreviation: APONF (Application-based Policy for > Network Functions) > * Description, including whether the BoF is intended to form a WG or > not (Intended to form a WG) > > Today network operators are challenged to create an abstract view of > their network infrastructure and help application developers on using > and programming this abstraction rather than manipulating individual > devices. An abstract view of a network infrastructure can be realized > using a network service graph that describes the network service > attributes, e.g., topology, flow treatment policy, Distributed Data > Center policy, IPv6 transition policy, associated with a network > management application. 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 application developers. > Subsequently, a network management application can use the application > based demands and possibly update its associated network service graph. > > The main goal of APONF is to (1) enable the streaming transfer of > bulk-variable/data of the up to date network service graphs between > network management application systems and the network management and > controlling systems, by using and extending an existing IETF specified > signaling protocol, (2) map the attributes of the network service > graph into specific network management policies, i.e., device level > configuration models. > > /Work items related to APONF include:/ > > * specify the problem statement and use cases > > * produce an analysis identifying the gaps between existing signaling > > protocols and the APONF requirements and use cases. > > * specify the APONF architecture > > * specify extensions to an existing IETF signaling protocol to > distribute network service graphs between network management > applications (e.g., OSS applications) and network management > systems, the routing controlling system or other controlling > systems. A possible candidate signaling protocol could be the IETF > NSIS protocol framework. > > * specify mechanisms that can dynamically map the network service > graphs into specific device level configuration models > > * specify the AAA method. > > /The following items are out of the APONF scope:/ > > * the generation of the abstract view of the network infrastructure > using an network service graph > > * the necessary configuration interfaces to service developers to > program the abstract view of a network infrastructure. > > * definition of the used network service graphs > > * the specification of the network management policies and their > associated device configuration models > > /Milestones:/ > > * I-D 'Problem Statement and Use Cases' as an Informational RFC. > > * I-D 'APONF Gap Analysis as an Informational RFC. > > * I-D 'APONF Architecture' as an Informational RFC. > > * I-D 'Mapping network service graphs into specific device level > configuration models' as an Informational RFC. > > * I-D 'APONF Protocol Specification' Standards Track RFC. > > * The responsible Area Director (AD): Spencer Dawkins > * BoF Chairs: Scott Bradner, Georgios Karagiannis > * Number of people expected to attend: 100 > * Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours > * Conflicts to avoid (whole Areas and/or WGs): Transport Area, intarea > * Does it require WebEX? If so, why?: no > * Does it require Meetecho? If so, why?: no > * Links to the mailing list, draft charter if any, relevant > Internet-Drafts, etc. > > o Mailing list: openv6@ietf.org <mailto:openv6@ietf.org>; > o Mailing List Info Page: > https://www.ietf.org/mailman/listinfo/openv6; > o Draft charter: > http://www.ietf.org/mail-archive/web/openv6/current/msg00118.html > o Relevant drafts: > > 1)Problem Statement: > > * > http://tools.ietf.org/html/draft-karagiannis-aponf-problem-statement-03 > > 2)Architecture: > > * http://tools.ietf.org/html/draft-zhou-aponf-architecture-03 > > 3) Use case drafts: > > * http://www.ietf.org/id/draft-cheng-aponf-ddc-use-cases-00.txt > * > http://www.ietf.org/id/draft-liu-aponf-using-abstract-view-use-case-00.txt > > * http://www.ietf.org/id/draft-sun-aponf-openv6-use-cases-00.txt > * http://www.ietf.org/id/draft-huang-aponf-use-cases-01.txt > * http://www.ietf.org/id/draft-bi-aponf-sdsavi-00.txt > > 4) Gap analysis: > > * http://www.ietf.org/id/draft-tremblay-aponf-gap-analysis-00.txt > > Best regards, > > Georgios > > ------------------------------------------------------------------------ > > *Van:*Reinaldo Penno [rapenno@gmail.com] > *Verzonden:* maandag 21 juli 2014 20:15 > *Aan:* Karagiannis, G. (EWI); Tina.Tsou.Zouting@huawei.com > <mailto:Tina.Tsou.Zouting@huawei.com>; fanpeng@chinamobile.com > <mailto:fanpeng@chinamobile.com>; eckelcu@cisco.com > <mailto:eckelcu@cisco.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? > > 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 > <mailto: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 <mailto:rapenno@gmail.com>] > *Verzonden:* maandag 21 juli 2014 19:42 > *Aan:* Tina TSOU; Karagiannis, G. (EWI); fanpeng@chinamobile.com > <mailto:fanpeng@chinamobile.com>; eckelcu@cisco.com > <mailto:eckelcu@cisco.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? > > 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 <mailto:karagian@cs.utwente.nl>; > fanpeng@chinamobile.com <mailto:fanpeng@chinamobile.com>; > eckelcu@cisco.com <mailto:eckelcu@cisco.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? > > 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 > <mailto: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 > <mailto:aeon-bounces@ietf.org>] namens Fan, Peng > [fanpeng@chinamobile.com <mailto: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 >
- [Aeon] Next step, IETF 90? Szilveszter Nadas
- Re: [Aeon] Next step, IETF 90? Fan, Peng
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? Reinaldo Penno
- Re: [Aeon] Next step, IETF 90? Michael Welzl
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] Next step, IETF 90? Charles Eckel (eckelcu)
- Re: [Aeon] Next step, IETF 90? Fan, Peng
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] Next step, IETF 90? Fan, Peng
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? Charles Eckel (eckelcu)
- Re: [Aeon] Next step, IETF 90? Charles Eckel (eckelcu)
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] Next step, IETF 90? Charles Eckel (eckelcu)
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? Reinaldo Penno
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] Next step, IETF 90? Charles Eckel (eckelcu)
- Re: [Aeon] Next step, IETF 90? Reinaldo Penno
- Re: [Aeon] Next step, IETF 90? Reinaldo Penno
- Re: [Aeon] Next step, IETF 90? karagian
- Re: [Aeon] [Openv6] Next step, IETF 90? Jun Bi
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? Reinaldo Penno
- Re: [Aeon] Next step, IETF 90? Tina TSOU
- Re: [Aeon] Next step, IETF 90? Reinaldo Penno
- Re: [Aeon] Next step, IETF 90? karagian