Re: [Aeon] Next step, IETF 90?

[Reinaldo Penno <[e-mail]>]

Kudos to whoever did the update. Now the distinction is well articulated 
in a few short paragraphs.

I guess I can stop 'ranting'.


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:[e-mail]] *On Behalf Of *Tina TSOU
> *Sent:* Monday, July 21, 2014 9:16 PM
> *To:* [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *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:*[e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]]
> *Sent:* Monday, July 21, 2014 4:43 PM
> *To:* [e-mail] <mailto:[e-mail]>; Tina TSOU; 
> [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *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: ​[e-mail] <mailto:[e-mail]>;
>       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 [[e-mail]]
> *Verzonden:* maandag 21 juli 2014 20:15
> *Aan:* Karagiannis, G. (EWI); [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *CC:* [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *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, [e-mail] 
> <mailto:[e-mail]> 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 [[e-mail] <mailto:[e-mail]>]
>     *Verzonden:* maandag 21 juli 2014 19:42
>     *Aan:* Tina TSOU; Karagiannis, G. (EWI); [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     *CC:* [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>     *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:[e-mail]] *On Behalf Of *Tina
>         TSOU
>         *Sent:* Tuesday, July 15, 2014 5:22 AM
>         *To:* [e-mail] <mailto:[e-mail]>;
>         [e-mail] <mailto:[e-mail]>;
>         [e-mail] <mailto:[e-mail]>;
>         [e-mail] <mailto:[e-mail]>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>         *Subject:* Re: [Aeon] Next step, IETF 90?
>
>         Dear all,
>
>         Attached pls find a short version of slides mentioned below.
>
>         Thank you,
>
>         Tina
>
>         *From:*[e-mail] <mailto:[e-mail]>
>         [mailto:[e-mail]]
>         *Sent:* Friday, July 11, 2014 4:59 PM
>         *To:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; Tina TSOU; [e-mail]
>         <mailto:[e-mail]>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>         *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 [[e-mail]
>         <mailto:[e-mail]>]
>         *Verzonden:* vrijdag 11 juli 2014 10:20
>         *Aan:* Karagiannis, G. (EWI); [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *CC:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>         *Onderwerp:* RE: [Aeon] Next step, IETF 90?
>
>         Hi Georgios,
>
>         Please see my reply Inline [FP], thanks.
>
>         *From:*[e-mail] <mailto:[e-mail]>
>         [mailto:[e-mail]]
>         *Sent:* Friday, July 11, 2014 2:40 PM
>         *To:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>         *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 [[e-mail]
>         <mailto:[e-mail]>] namens Fan, Peng
>         [[e-mail] <mailto:[e-mail]>]
>         *Verzonden:* woensdag 9 juli 2014 14:49
>         *Aan:* 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI);
>         [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *CC:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>         *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:[e-mail]]
>         *Sent:* Wednesday, July 09, 2014 1:05 AM
>         *To:* [e-mail] <mailto:[e-mail]>;
>         [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>; [e-mail]
>         <mailto:[e-mail]>
>         *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: *"[e-mail]
>         <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>
>         *Date: *Thursday, July 3, 2014 at 12:25 AM
>         *To: *"[e-mail]
>         <mailto:[e-mail]>"
>         <[e-mail]
>         <mailto:[e-mail]>>, "[e-mail]
>         <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc: *"[e-mail]
>         <mailto:[e-mail]>"
>         <[e-mail]
>         <mailto:[e-mail]>>, "[e-mail]
>         <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>, "[e-mail]
>         <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>, "[e-mail]
>         <mailto:[e-mail]>" <[e-mail]
>         <mailto:[e-mail]>>
>         *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 [[e-mail]
>             <mailto:[e-mail]>] namens Tina TSOU
>             [[e-mail]
>             <mailto:[e-mail]>]
>             *Verzonden:* donderdag 3 juli 2014 6:08
>             *Aan:* Reinaldo Penno
>             *CC:* Szilveszter Nadas; [e-mail]
>             <mailto:[e-mail]>; Fan, Peng; [e-mail]
>             <mailto:[e-mail]>
>             *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:[e-mail]]
>             *Sent:* Thursday, July 03, 2014 1:06 AM
>             *To:* Tina TSOU
>             *Cc:* Fan, Peng; Szilveszter Nadas; [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>
>             *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
>             <[e-mail]
>             <mailto:[e-mail]>> 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:[e-mail]] *On Behalf
>             Of *Tina TSOU
>             *Sent:* Monday, June 30, 2014 5:51 PM
>             *To:* [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>; [e-mail]
>             <mailto:[e-mail]>
>             *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"
>             <[e-mail] <mailto:[e-mail]>>
>             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:[e-mail]] *On Behalf
>                 Of *Szilveszter Nadas
>                 *Sent:* Monday, June 30, 2014 9:21 PM
>                 *To:* [e-mail] <mailto:[e-mail]>
>                 *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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/aeon
>