Re: [Openv6] [Aeon] Next step, IETF 90?

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Tue, 15 July 2014 16:09 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7709A1B287F; Tue, 15 Jul 2014 09:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 TaRZGF6fOJCg; Tue, 15 Jul 2014 09:09:07 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CDB1A0A8D; Tue, 15 Jul 2014 09:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=88588; q=dns/txt; s=iport; t=1405440547; x=1406650147; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1EiIlBTd5Vp6w/JS+in2IQf45O9kL0yDq5xcyu445/g=; b=VVfyX6qJAKvri+64JGm0RNExO5fJQOIAYorNNfpVCoQGHdQhyQ8rg4lU 9LG5L2/VUFd4ycfx1136oLEr46mUCDCl8bkShT4KWFmAv1ts7en5+KPXC zuSqakq51EMsU+rMNw8IXnROXFBm1AObF3CgA2bI0LiY/AfkU8AP2dedT Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFAPtQxVOtJA2D/2dsb2JhbABZgkdHUlcEwWcBCYdDAYEQFnWEAwEBAQQBAQEXAVMLEAIBCBEBAgEBASEBBgchBgsUAwYIAgQBCQQFG4gTAxENwwANhwsTBIl+gyCBSxEBPgEHBgQGAQKEQQWFcJENghuCAI4JhhyDRGwBgQIFBBci
X-IronPort-AV: E=Sophos;i="5.01,666,1400025600"; d="scan'208,217";a="340253110"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 15 Jul 2014 16:09:05 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6FG94g9023948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 16:09:04 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 11:09:04 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>, "Tina.Tsou.Zouting@huawei.com" <Tina.Tsou.Zouting@huawei.com>, "rapenno@gmail.com" <rapenno@gmail.com>
Thread-Topic: [Aeon] Next step, IETF 90?
Thread-Index: Ac+UZitwzhnDUsdiSuWIYkG5NbmJTgBu6aoAAAG6t4AABkQcAAAXISAAAAbhUQABAQxsAACi57uAALst9oA=
Date: Tue, 15 Jul 2014 16:09:04 +0000
Message-ID: <CFEA99C7.2E195%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> <FF1A9612A94D5C4A81ED7DE1039AB80F5D572B20@EXMBX23.ad.utwente.nl>
In-Reply-To: <FF1A9612A94D5C4A81ED7DE1039AB80F5D572B20@EXMBX23.ad.utwente.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.90.7]
Content-Type: multipart/alternative; boundary="_000_CFEA99C72E195eckelcuciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/TRp016z2cOvOINgxk4XLgkFHXA4
Cc: "Szilveszter.Nadas@ericsson.com" <Szilveszter.Nadas@ericsson.com>, "aeon@ietf.org" <aeon@ietf.org>, "fanpeng@chinamobile.com" <fanpeng@chinamobile.com>, "Openv6@ietf.org" <Openv6@ietf.org>
Subject: Re: [Openv6] [Aeon] Next step, IETF 90?
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jul 2014 16:09:19 -0000

Hi Georgios,

Thanks for pulling together this summary. It helps clarify important differences between AECON and APONF. Please see additional comments inline.

From: "karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl>" <karagian@cs.utwente.nl<mailto:karagian@cs.utwente.nl>>
Date: Friday, July 11, 2014 at 8:49 AM
To: Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>, Tina Tsou <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 Charles,



Thanks for your comments!

Sorry, I have not seen your email before sending the previous email to the list!

I will try to provide some answers to your comments. Below I am marking the text that is included in the APONF description with "In APONF description". Your comments are marked with "Comment Charles" and mine are marked with "Comment Georgios". The first paragraph given below (Issue 1) was refering to the email that was sent by Tina.



Issue 1:

=========

In email sent by 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)



Comment Charles: 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.



Comment Georgios: Okay, based on your description, I will try to emphasize the main goal of AECON, please let me know if it is coirrect?:



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.

This is better, however, AECON is not defining an interface or API. It would be more clear and accurate to say,
“AECON is communication between end user applications and network entities. Applications describe their flows to the network, and the network provides feedback regarding anticipated handling of those flows.”




Moreover, please note that
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.

Based on the above description, AECON can help here on the definition of the flow treatment policies required by end user applications

No. AECON does NOT define flow treatment policies. Any such policies are outside the scope of AECON.


==========================

Issue_2:

=========
=>In APONF description:
Today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this



Comment_Charles:
I find the term “service developers” confusing. How about replacing this with “developers of network management applications”.



Comment Georgios: In the text we are refering to developers of end user applications, not developers of network management applications.



This is also one of the main diffrences between AECON and APONF. 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.

Okay.


The AECON will not support this.

Correct.


The interface between the network management applications and the end user application developers is out of the scope of APONF and from what I understood from Charles explanation is also out of the scope of AECON.

Correct.


We need to discuss whether and how the IETF can work on the above described interface (between end user application developers and network management applications).



Please note that AECON can play a signifficant role here, since the flow descirptions will aslo be needed by the network management applicatiuons, see above.

I agree that network management entities would generally be interested in the flow descriptions provided in the content of AECON.




===================



Issue 3:

=========
In APONF description:
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.



Comment Georgios:

Similar to my previous comment: This is also one of the main diffrences between AECON and APONF. 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.

The AECON will not support this.

The interface between the network management applications and the end user application developers is out of the scope of APONF and from what I understood from Charles explanation is also out of the scope of AECON.

We need to discuss whether and how the IETF can work on the above described interface (between end user application developers and network management applications).

Please note that AECON can play a signifficant role here, since the flow descirptions will aslo be needed by the network management applicatiuons, see above.

I agree with this last point; however, my objection in issue was in regard to, "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.”

AECON will not provide configuration interfaces, nor will it be used to program network infrastructure.




========================



Issue_4

==========



In APONF description:
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.

Comment Georgios: Agree, AECON can help here on providin the required flow descriptions!

Exactly.

Cheers,
Charles




Best regards,

Georgios



________________________________
Van: Charles Eckel (eckelcu) [eckelcu@cisco.com<mailto:eckelcu@cisco.com>]
Verzonden: dinsdag 8 juli 2014 19:05
Aan: 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>; fanpeng@chinamobile.com<mailto:fanpeng@chinamobile.com>; Openv6@ietf.org<mailto:Openv6@ietf.org>
Onderwerp: 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 3rd 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