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

From: Tina TSOU <[email-masked]>
Date: Wed, 2 Jul 2014 14:06:33 +0000

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:[email-masked]] On Behalf Of Tina TSOU
Sent: Monday, June 30, 2014 5:51 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 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.

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).

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" <[email-masked]<mailto:[email-masked]>> 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:[email-masked]] On Behalf Of Szilveszter Nadas
Sent: Monday, June 30, 2014 9:21 PM
To: [email-masked]<mailto:[email-masked]>
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

---

From: Michael Welzl <[email-masked]>
Date: Wed, 2 Jul 2014 19:32:13 +0200

> I believe the more fragmented these initiatives are, more confusion to IESG. The paragraphs above would be enough confusion to anyone. 
> 
> 

+1. There should be one clear vision that is shared by a large group of people.

Cheers,
Michael

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 2 Jul 2014 10:05:58 -0700

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 <[email-masked]>
wrote:

> *From:* Openv6 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tina TSOU
> *Sent:* Monday, June 30, 2014 5:51 PM
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [Openv6] Is there a draft charter for APONF?
>
>
>
> Dear all,
>
>
>
> *APONF (Application-based Policy for Network Functions) charter*
>
>
>
> Today network operators are challenged to create an abstract view of their
> network infrastructure and help service 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
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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).
>
>
>
> 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
>
>
>
> 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:
>
> 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
>
>
>
> On Jul 2, 2014, at 9:17 PM, "Fan, Peng" <[email-masked]> 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.
>
>
>
> *From:* Aeon [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Szilveszter Nadas
> *Sent:* Monday, June 30, 2014 9:21 PM
> *To:* [email-masked]
> *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?
>
>
>
> _______________________________________________
> Aeon mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aeon
>
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 3 Jul 2014 04:08:14 +0000

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:[email-masked]]
Sent: Thursday, July 03, 2014 1:06 AM
To: Tina TSOU
Cc: Fan, Peng; Szilveszter Nadas; [email-masked]; [email-masked]
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. "

"

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 <[email-masked]<mailto:[email-masked]>> wrote:
Dear Peng, Szilveszter, et al,

Dear all,

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

_______________________________________________
Aeon mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aeon

---

From: <[email-masked]>
Date: Thu, 3 Jul 2014 07:25:14 +0000

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:

Best regards,

Georgios

________________________________
Van: Openv6 [[email-masked]] namens Tina TSOU [[email-masked]]
Verzonden: donderdag 3 juli 2014 6:08
Aan: Reinaldo Penno
CC: Szilveszter Nadas; [email-masked]; Fan, Peng; [email-masked]
Onderwerp: Re: [Openv6] [Aeon] Next step, IETF 90?

Good catch!

Thank you,
Tina

"

Dear all,

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 8 Jul 2014 17:05:04 +0000

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 3, 2014 at 12:25 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Aeon] Next step, IETF 90?

Hi all.

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.

In that case, I have a few suggestions regarding the charter. Please see inline.

Best regards,

Georgios

________________________________
Van: Openv6 [[email-masked]<mailto:[email-masked]>] namens Tina TSOU [[email-masked]<mailto:[email-masked]>]
Verzonden: donderdag 3 juli 2014 6:08
Aan: Reinaldo Penno
CC: Szilveszter Nadas; [email-masked]<mailto:[email-masked]>; Fan, Peng; [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [Openv6] [Aeon] Next step, IETF 90?

Good catch!

Thank you,
Tina

From: Reinaldo Penno [mailto:[email-masked]]
Sent: Thursday, July 03, 2014 1:06 AM
To: Tina TSOU
Cc: Fan, Peng; Szilveszter Nadas; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Aeon] Next step, IETF 90?

"

Dear all,

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.

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.

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

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Fan, Peng" <[email-masked]>
Date: Wed, 9 Jul 2014 20:49:43 +0800

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:[email-masked]] 
Sent: Wednesday, July 09, 2014 1:05 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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: "[email-masked]" <[email-masked]>
Date: Thursday, July 3, 2014 at 12:25 AM
To: "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
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.

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 [[email-masked]] namens Tina TSOU
[[email-masked]]
Verzonden: donderdag 3 juli 2014 6:08
Aan: Reinaldo Penno
CC: Szilveszter Nadas; [email-masked]; Fan, Peng; [email-masked]
Onderwerp: Re: [Openv6] [Aeon] Next step, IETF 90?

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. 

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

"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:

 

I believe the more fragmented these initiatives are, more confusion to IESG.
The paragraphs above would be enough confusion to anyone. 

 

From: Openv6 [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Monday, June 30, 2014 5:51 PM
To: [email-masked]; [email-masked]; [email-masked]
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.

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.

o) enable the streaming transfer of bulk-variable/data of the up to date SFP

o) map the SFP based network configuration and network topology models into
specific device level configuration models.

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

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

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:

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

Milestones:

I-D 'Mapping SFP based models into specific device level configuration
models' as an Informational RFC.

 

Thank you,

Tina

-----------

Thank you,

Tina

Hi all,

We will update the information as soon as possible. Thank you all for making
this list fruitful.

Best regards,

Peng

To: [email-masked]

Hi All,

Best Regards,

Szilveszter

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 06:39:51 +0000

Hi Peng,

Thank you very much!

>From what I understood, I think that we are in agreement that:

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. Moreover, it will be great if you could provide comments, input to the slides that are prepared by Tina on the AECON-APONF differences.

Best regards,
Georgios
________________________________
Van: Aeon [[email-masked]] namens Fan, Peng [[email-masked]]
Verzonden: woensdag 9 juli 2014 14:49
Aan: 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI); [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
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

Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Fan, Peng" <[email-masked]>
Date: Fri, 11 Jul 2014 16:20:15 +0800

Hi Georgios,

Please see my reply Inline [FP], thanks.

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 11, 2014 2:40 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Aeon] Next step, IETF 90?

Hi Peng,

Thank you very much!

[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, 

>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 [[email-masked]] namens Fan, Peng [[email-masked]]
Verzonden: woensdag 9 juli 2014 14:49
Aan: 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI);
[email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Onderwerp: Re: [Aeon] Next step, IETF 90?

Hi Tina, Georgios,

Best regards,

Peng

Hi Tina and Georgios,

Hi all.

 

 

Best regards,

Georgios

  _____  

Good catch!

 

Thank you,

Tina

" 

 

Dear all,

 

Cheers,

Charles

Milestones:

 

Thank you,

Tina

-----------

Thank you,

Tina

Hi all,

Best regards,

Peng

Hi All,

Best Regards,

Szilveszter

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 15:49:49 +0000

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:

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.

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

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

Issue_2:

=========
=>In APONF description:

Comment_Charles:

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.

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.

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

Issue 3:

=========
In APONF description:

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.

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

Issue_4

==========

In APONF description:

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

Best regards,

Georgios

________________________________
Van: Charles Eckel (eckelcu) [[email-masked]]
Verzonden: dinsdag 8 juli 2014 19:05
Aan: Karagiannis, G. (EWI); [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Onderwerp: Re: [Aeon] Next step, IETF 90?

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 15:58:43 +0000

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

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 [[email-masked]]
Verzonden: vrijdag 11 juli 2014 10:20
Aan: Karagiannis, G. (EWI); [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Onderwerp: RE: [Aeon] Next step, IETF 90?

Hi Georgios,

To: [email-masked]; [email-masked]; [email-masked]; [email-masked]

Hi Peng,

Thank you very much!

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.

Moreover, it will be great if you could provide comments, input to the slides that are prepared by Tina on the AECON-APONF differences.

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 16:26:25 +0000

Hi all,

To be informed!

Best regards,

Georgios

________________________________
Van: Karagiannis, G. (EWI)
Verzonden: vrijdag 11 juli 2014 17:49
Aan: Charles Eckel (eckelcu); [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Onderwerp: RE: [Aeon] Next step, IETF 90?

Hi Charles,

Issue 1:

=========

In email sent by Tina:

Issue_2:

=========
=>In APONF description:

Comment_Charles:

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

Issue 3:

=========
In APONF description:

Comment Georgios:

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

Issue_4

==========

In APONF description:

Best regards,

Georgios

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 16:27:42 +0000

Hi all,

To be informed!

Best regards,

Georgios

Hi Charles,

Issue 1:

=========

In email sent by Tina:

Issue_2:

=========
=>In APONF description:

Comment_Charles:

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

Issue 3:

=========
In APONF description:

Comment Georgios:

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

Issue_4

==========

In APONF description:

Best regards,

Georgios

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 16:31:55 +0000

Hi all,

To be informed!

Best regards,

Georgios

________________________________
Van: Aeon [[email-masked]] namens [email-masked] [[email-masked]]
Verzonden: vrijdag 11 juli 2014 17:58
Aan: [email-masked]; [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Onderwerp: Re: [Aeon] Next step, IETF 90?

Hi Peng,

Best regards,

Georgios

Hi Georgios,

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Tina TSOU <[email-masked]>
Date: Mon, 14 Jul 2014 21:22:18 +0000

Dear all,

Attached pls find a short version of slides mentioned below.

Thank you,
Tina

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 11, 2014 4:59 PM
To: [email-masked]; [email-masked]; Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Aeon] Next step, IETF 90?

Hi Peng,

Best regards,

Georgios

________________________________
Van: Fan, Peng [[email-masked]]
Verzonden: vrijdag 11 juli 2014 10:20
Aan: Karagiannis, G. (EWI); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Onderwerp: RE: [Aeon] Next step, IETF 90?
Hi Georgios,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, July 11, 2014 2:40 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Aeon] Next step, IETF 90?

Hi Peng,

Thank you very much!

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.

Best regards,
Peng

Best regards,
Georgios
________________________________
Van: Aeon [[email-masked]] namens Fan, Peng [[email-masked]]
Verzonden: woensdag 9 juli 2014 14:49
Aan: 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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".

Best regards,
Peng

From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Wednesday, July 09, 2014 1:05 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Aeon] Next step, IETF 90?

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

I find the term "service developers" confusing. How about replacing this with "developers of network management applications".

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 15 Jul 2014 16:09:04 +0000

Hi Georgios,

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

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 11, 2014 at 8:49 AM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>, Tina Tsou <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Aeon] Next step, IETF 90?

Hi Charles,

Issue 1:

=========

In email sent by Tina:

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.”

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

Issue_2:

=========
=>In APONF description:

Comment_Charles:

Okay.

Correct.

Correct.

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:

Comment Georgios:

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:

Exactly.

Cheers,
Charles

Best regards,

Georgios

________________________________
Van: Charles Eckel (eckelcu) [[email-masked]<mailto:[email-masked]>]
Verzonden: dinsdag 8 juli 2014 19:05
Aan: Karagiannis, G. (EWI); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [Aeon] Next step, IETF 90?

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 15 Jul 2014 16:12:17 +0000

Hi Georgios,

Please see one comment inline.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 11, 2014 at 8:58 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charles Eckel <[email-masked]<mailto:[email-masked]>>, Tina Tsou <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Aeon] Next step, IETF 90?

Hi Peng,

Sorry for being repetitive, but just to be clear, AECON flow description help identify the traffic such that existing policies can be applied appropriately. But AECON does NOT help with the definition of the policies themselves.

Cheers,
Charles

Best regards,

Georgios

Van: Fan, Peng [[email-masked]<mailto:[email-masked]>]

Hi Georgios,

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios
Van: Aeon [[email-masked]<mailto:[email-masked]>] namens Fan, Peng [[email-masked]<mailto:[email-masked]>]

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 08:25:46 +0000

Hi Charles,

Thajnk you very much!

Can you please let us know whether we can mention based on your commentsin the presentation that focusses on the APONF and AECON differences the following:

o) AECON focusses on 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.”

o) AECON focus on identification and treatment of application flows to get better user experience for the end user applications.

o) 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

Best regards,

Georgios

Verzonden: dinsdag 15 juli 2014 18:09

Hi Georgios,

Hi Charles,

Issue 1:

=========

In email sent by Tina:

Issue_2:

=========
=>In APONF description:

Comment_Charles:

Okay.

Correct.

Correct.

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

Issue 3:

=========
In APONF description:

Comment Georgios:

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

Issue_4

==========

In APONF description:

Exactly.

Cheers,
Charles

Best regards,

Georgios

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 09:02:04 +0000

Dear all,

To be informed!

Best regards,

Georgios

Verzonden: woensdag 16 juli 2014 10:25

Hi Charles,

Thajnk you very much!

Best regards,

Georgios

Hi Georgios,

Hi Charles,

Issue 1:

=========

In email sent by Tina:

Issue_2:

=========
=>In APONF description:

Comment_Charles:

Okay.

Correct.

Correct.

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

Issue 3:

=========
In APONF description:

Comment Georgios:

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

Issue_4

==========

In APONF description:

Exactly.

Cheers,
Charles

Best regards,

Georgios

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 16 Jul 2014 15:01:25 +0000

Hi Georgios,

Please see inline.

Date: Wednesday, July 16, 2014 at 1:25 AM

Hi Charles,

Thajnk you very much!

This is fine.

This is okay, but would be better to say:
o) AECON focus is identification and treatment of application flows for efficient use of network resources to improve user experience.

I assume you mean “without the end user application having knowledge of any network attributes.” This is not necessarily true, as the end user application may have gained knowledge of network attributes from a variety of ways, including previous AECON exchanges.
I think it is best to drop the 3rd bullet.

Cheers,
Charles

Best regards,

Georgios

Hi Georgios,

Hi Charles,

Issue 1:

=========

In email sent by Tina:

Issue_2:

=========
=>In APONF description:

Comment_Charles:

Okay.

Correct.

Correct.

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

Issue 3:

=========
In APONF description:

Comment Georgios:

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

Issue_4

==========

In APONF description:

Exactly.

Cheers,
Charles

Best regards,

Georgios

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 18:44:23 +0000

Dear all,

To be informed!

Best regards,

Georgios

Verzonden: woensdag 16 juli 2014 17:01

Hi Georgios,

Please see inline.

Hi Charles,

Thajnk you very much!

This is fine.

Cheers,
Charles

Best regards,

Georgios

Hi Georgios,

Hi Charles,

Issue 1:

=========

In email sent by Tina:

Issue_2:

=========
=>In APONF description:

Comment_Charles:

Okay.

Correct.

Correct.

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

Issue 3:

=========
In APONF description:

Comment Georgios:

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

Issue_4

==========

In APONF description:

Exactly.

Cheers,
Charles

Best regards,

Georgios

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Tina TSOU <[email-masked]>
Date: Mon, 21 Jul 2014 17:01:01 +0000

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:[email-masked]] On Behalf Of Tina TSOU
Sent: Tuesday, July 15, 2014 5:22 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Aeon] Next step, IETF 90?

Dear all,

Thank you,
Tina

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Tina TSOU; [email-masked]<mailto:[email-masked]>

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 21 Jul 2014 13:42:32 -0400

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:
> AECON and APONF proposals discussions (_invitation only_)
>
> Wednesday:
>
> *From:*Aeon [mailto:[email-masked]] *On Behalf Of *Tina TSOU
> *Sent:* Tuesday, July 15, 2014 5:22 AM
> *To:* [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [Aeon] Next step, IETF 90?
>
> Dear all,
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *Sent:* Friday, July 11, 2014 4:59 PM
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; Tina TSOU; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Aeon] Next step, IETF 90?
>
> Hi Peng,
>
> 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.
>
> 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 [[email-masked]]
> *Verzonden:* vrijdag 11 juli 2014 10:20
> *Aan:* Karagiannis, G. (EWI); [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *CC:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Onderwerp:* RE: [Aeon] Next step, IETF 90?
>
> Hi Georgios,
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]
> *Sent:* Friday, July 11, 2014 2:40 PM
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [Aeon] Next step, IETF 90?
>
> Hi Peng,
>
> Thank you very much!
>
> 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./*
>
> */[FP] We will, as scheduled./*
>
> */[FP] You are welcome to send me slides from your side prior to the 
> meeting./*
>
> */Best regards,/*
>
> */Peng/*
>
> Best regards,
>
> Georgios
>
> ------------------------------------------------------------------------
>
> *Van:*Aeon [[email-masked]] namens Fan, Peng 
> [[email-masked]]
> *Verzonden:* woensdag 9 juli 2014 14:49
> *Aan:* 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI); 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *CC:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *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.
>
> 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:[email-masked]]
> *Sent:* Wednesday, July 09, 2014 1:05 AM
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Aeon] Next step, IETF 90?
>
> Hi Tina and Georgios,
>
> However, there are a few things that I think create confusion. Please 
> see inline.
>
> *From: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> *Date: *Thursday, July 3, 2014 at 12:25 AM
> *To: *"[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *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.
>
>     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.
>
>     ------------------------------------------------------------------------
>
>     *Van:*Openv6 [[email-masked]
>     <mailto:[email-masked]>] namens Tina TSOU
>     [[email-masked] <mailto:[email-masked]>]
>     *Verzonden:* donderdag 3 juli 2014 6:08
>     *Aan:* Reinaldo Penno
>     *CC:* Szilveszter Nadas; [email-masked] <mailto:[email-masked]>;
>     Fan, Peng; [email-masked] <mailto:[email-masked]>
>     *Onderwerp:* Re: [Openv6] [Aeon] Next step, IETF 90?
>
>     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.
>
>     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:[email-masked]]
>     *Sent:* Thursday, July 03, 2014 1:06 AM
>     *To:* Tina TSOU
>     *Cc:* Fan, Peng; Szilveszter Nadas; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Aeon] Next step, IETF 90?
>
>     "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:
>
>     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
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     *From:* Openv6 [mailto:[email-masked]] *On Behalf Of
>     *Tina TSOU
>     *To:* [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     Based on everybody's feedback, here comes the 3^rd  version of the
>     charter.
>
>     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
>     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.
>
>     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.
>
>     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
>
>     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
>
>     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:
>
>     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
>
>     I-D 'Mapping SFP based models into specific device level
>     configuration models' as an Informational RFC.
>
>         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.
>
>         *From:*Aeon [mailto:[email-masked]] *On Behalf Of
>         *Szilveszter Nadas
>         *To:* [email-masked] <mailto:[email-masked]>
>         I have seen that the BoF was not approved for IETF 90. Did you
>         receive a more detailed explanation of the reasons?
>
>     [email-masked] <mailto:[email-masked]>

---

From: Tina TSOU <[email-masked]>
Date: Mon, 21 Jul 2014 17:55:28 +0000

Dear Reinaldo et al,

The -01 version tries to reflect Charles' comments on the mailing list, as the proponents of these two proposals say they are different.

Your view also makes sense at some point from Opendaylight's aspect.

Any other opinions?

Thank you,
Tina

On Jul 21, 2014, at 1:42 PM, "Reinaldo Penno" <[email-masked]<mailto:[email-masked]>> wrote:

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,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 18:09:58 +0000

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 [[email-masked]]
Verzonden: maandag 21 juli 2014 19:42
Aan: Tina TSOU; Karagiannis, G. (EWI); [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
Onderwerp: Re: [Aeon] Next step, IETF 90?

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 21 Jul 2014 18:11:05 +0000

Hi Reinaldo,
Please see inline.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 21, 2014 at 10:42 AM
To: Tina Tsou <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charles Eckel <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Aeon] Next step, IETF 90?

Perhaps some network devices will allow themselves to be controlled by end user application applications, but that is not the model proposed by AECON. Rather, AECON separates:

  1.  the communication of the flow characteristics from
  2.  the policy decisions and actions made by network devices based on that communication

AECON is about the first, not the second.

Cheers,
Charles

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Hi Peng,

Best regards,

Georgios

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 21 Jul 2014 14:15:37 -0400

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, [email-masked] 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 [[email-masked]]
> *Verzonden:* maandag 21 juli 2014 19:42
> *Aan:* Tina TSOU; Karagiannis, G. (EWI); [email-masked]; 
> [email-masked]
> *CC:* [email-masked]; [email-masked]; [email-masked]
> 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 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,
>
>
>> 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
>>
>> intent coming from end user applications <=> network configuation & 
>> network topology known to the network management application systems 
>> (e.g. OSS)
>>
>> (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./*
>>
>> Moreover, it will be great if you could provide comments, input to 
>> the slides that are prepared by Tina on the AECON-APONF differences.
>>
>> 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.
>>
>> about APONF: “APONF is about specialized applications *managing* the 
>> network, not general applications using it”, and I have to say that I 
>> 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 
>> 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”.
>>
>> 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
>>
>>     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.
>>
>>     I just pulled things together into a charter, while talking to
>>     the proponents, below was what I understood.
>>
>>     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
>>     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
>>
>>     "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. "
>>
>>     "
>>
>>     Based on everybody’s feedback, here comes the 3^rd  version of
>>     the charter.
>>
>> I find the term “service developers” confusing. How about replacing 
>> this with “developers of network management applications”.
>>
>>     abstract view of a network infrastructure can be realized using 
>>     a network configuration model, that provides a declarative
>>     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
>>     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
>> 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
>>     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
>>
>>     c) configure and dynamically reconfigure data centers to the
>>     steer and reroute 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
>>
>>     the NAT/Firewall NSLP and QoS NSLP that can be applied and
>>     support the APONF use cases.
>>
>>         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.
>>
>>         I have seen that the BoF was not approved for IETF 90. Did
>>         you receive a more detailed explanation of the reasons?
>>

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 21 Jul 2014 14:18:12 -0400

I just responded to the other comment but (2) does not seem to be IETF 
work. IETF is about on the wire protocol interoperability, what happens 
inside a device probably has a good venue in some other SDO.

On 7/21/14, 2:11 PM, Charles Eckel (eckelcu) wrote:
> Perhaps some network devices will allow themselves to be controlled by 
> end user application applications, but that is not the model proposed 
> by AECON. Rather, AECON separates:
>

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 20:42:41 +0000

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.

  *   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.
     *   Mailing list: ​[email-masked]<mailto:[email-masked]>;
     *   Mailing List Info Page: ​https://www.ietf.org/mailman/listinfo/openv6<https://www.ietf.org/mailman/listinfo/openv6>;
     *   Draft charter: ​http://www.ietf.org/mail-archive/web/openv6/current/msg00118.html<http://www.ietf.org/mail-archive/web/openv6/current/msg00118.html>
     *   Relevant drafts:

1)Problem Statement:

  *   ​http://tools.ietf.org/html/draft-karagiannis-aponf-problem-statement-03<http://tools.ietf.org/html/draft-karagiannis-aponf-problem-statement-03>

2)Architecture:

  *   ​http://tools.ietf.org/html/draft-zhou-aponf-architecture-03<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-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-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-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-huang-aponf-use-cases-01.txt>
  *   ​http://www.ietf.org/id/draft-bi-aponf-sdsavi-00.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<http://www.ietf.org/id/draft-tremblay-aponf-gap-analysis-00.txt>

Best regards,

Georgios

________________________________
Van: Reinaldo Penno [[email-masked]]
Verzonden: maandag 21 juli 2014 20:15
Aan: Karagiannis, G. (EWI); [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]
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, [email-masked]<mailto:[email-masked]> wrote:

Hi Reinaldo,

Best regards,

Georgios

________________________________
Van: Reinaldo Penno [[email-masked]<mailto:[email-masked]>]
Verzonden: maandag 21 juli 2014 19:42
Aan: Tina TSOU; Karagiannis, G. (EWI); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Onderwerp: Re: [Aeon] Next step, IETF 90?

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 21 Jul 2014 16:49:11 -0400

Hi, all,

Just spent some time to read all messages in this thread. 

My personal conclusions are:

1 AECON and APNOF are not the same, as pointed by Tina's ppt and messages
from others. Basically, I think AECON is for device's new interfaces on
flows characters for end user application ("The purpose of Application
Enabled Collaborative Network (AECON) is to enable communication between
applications and the network by active information exchange"." This exchange
provides network nodes with visibility of the application flow
characteristics. While ANONF is for the network operator's policies
enforcement.

2 For your question below, I don't think (2) means to specifies what to do
inside a device. By my understanding (might not be very precisely), APNOF
specifies an architecture, with new or excision to existing signaling
protocols to support it. So APONF does deal with interoperability between
network elements, therefore, I believe it fits for IETF's scope.

Thanks,

Jun Bi

PS. part of APNOF's goals might overlaps (in some degree) with Open Daylight
project. But ODP is just an open source organization, not a SDO, so IETF
might be a venue for standardization.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reinaldo Penno
Sent: Monday, July 21, 2014 2:18 PM
To: Charles Eckel (eckelcu); Tina TSOU; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Openv6] [Aeon] Next step, IETF 90?

I just responded to the other comment but (2) does not seem to be IETF work.
IETF is about on the wire protocol interoperability, what happens inside a
device probably has a good venue in some other SDO.  

Perhaps some network devices will allow themselves to be controlled by end
user application applications, but that is not the model proposed by AECON.
Rather, AECON separates:

1.	the communication of the flow characteristics from
2.	the policy decisions and actions made by network devices based on
that communication

---

From: Tina TSOU <[email-masked]>
Date: Tue, 22 Jul 2014 01:15:54 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 21, 2014 4:43 PM
To: [email-masked]; Tina TSOU; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Aeon] Next step, IETF 90?

Hi Reinaldo,

Milestones:

1)Problem Statement:

2)Architecture:

3) Use case drafts:

4) Gap analysis:

Best regards,

Georgios

Aan: Karagiannis, G. (EWI); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Reinaldo,

Best regards,

Georgios

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Tina TSOU <[email-masked]>
Date: Tue, 22 Jul 2014 16:02:17 +0000

Dear all,

Attached please find today’s meeting slides -03 version.

Thank you,
Tina

From: Aeon [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Monday, July 21, 2014 9:16 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Aeon] Next step, IETF 90?

Dear all,

Thank you,
Tina

To: [email-masked]<mailto:[email-masked]>; Tina TSOU; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Reinaldo,

Milestones:

1)Problem Statement:

2)Architecture:

3) Use case drafts:

4) Gap analysis:

Best regards,

Georgios

Hi Reinaldo,

Best regards,

Georgios

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 22 Jul 2014 12:08:10 -0400

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:
> *Sent:* Monday, July 21, 2014 9:16 PM
> *To:* [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> *Sent:* Monday, July 21, 2014 4:43 PM
> *To:* [email-masked] <mailto:[email-masked]>; Tina TSOU; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> 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).
>
> 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.
>
>         APONF¶
>         <http://trac.tools.ietf.org/bof/trac/#APONFNotApprovedforIETF90>
>
> 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 
> 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 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
>
> /The following items are out of the APONF scope:/
>
>   * the necessary configuration interfaces to service developers to
>     program the abstract view of a network infrastructure.
>
> /Milestones:/
>   * I-D 'Mapping network service graphs into specific device level
>       o Mailing list: ​[email-masked] <mailto:[email-masked]>;
>       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 [[email-masked]]
> *Verzonden:* maandag 21 juli 2014 20:15
> *Aan:* Karagiannis, G. (EWI); [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> 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.
>
>     *Van:*Reinaldo Penno [[email-masked] <mailto:[email-masked]>]
>     *Aan:* Tina TSOU; Karagiannis, G. (EWI); [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     hide this fact. There is no way to distinguish them unless you are
>     in denial.
>
>     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.
>
>     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,
>
>         [email-masked] <mailto:[email-masked]>;
>         *To:* [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         <mailto:[email-masked]>; Tina TSOU; [email-masked]
>         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
>         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.
>
>         *Van:*Fan, Peng [[email-masked]
>         <mailto:[email-masked]>]
>         *To:* [email-masked]
>         <mailto:[email-masked]>; [email-masked]
>         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)
>
>         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./*
>
>         you are right, but we prefer to do this after we get the Okay
>         from the IESG that we are on the right track!
>
>         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 [[email-masked]
>         <mailto:[email-masked]>] namens Fan, Peng
>         [[email-masked] <mailto:[email-masked]>]
>         [email-masked]
>         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
>
>         [email-masked]
>         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: *"[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>             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.
>
>             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
>             configuation & network topology (known to the network
>             management application systems (e.g.OSS)) <=> network
>             management policies, i.e., device configuration Models.
>
>             *CC:* Szilveszter Nadas; [email-masked]
>             <mailto:[email-masked]>; Fan, Peng; [email-masked]
>             <mailto:[email-masked]>
>             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.
>
>             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)
>
>             configuation & network topology (known to the network
>             management application systems (e.g.OSS)) <=> network
>             management policies, i.e., device configuration Models.
>
>             Thank you,
>
>             Tina
>
>             "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
>             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:
>
>             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
>
>             *From:* Openv6 [mailto:[email-masked]] *On Behalf
>             Of *Tina TSOU
>             *To:* [email-masked]
>             <mailto:[email-masked]>; [email-masked]
>             <mailto:[email-masked]>; [email-masked]
>             <mailto:[email-masked]>
>             Based on everybody’s feedback, here comes the 3^rd
>              version of the charter.
>
>             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
>             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
>             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
>             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
>             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
>
>             security service, optimization of the traffic in network
>             for IETF ALTO service
>
>             o) specify extensions to the IETF NSIS protocol to
>             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:
>
>             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
>
>             On Jul 2, 2014, at 9:17 PM, "Fan, Peng"
>             <[email-masked] <mailto:[email-masked]>>
>             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:[email-masked]] *On Behalf
>                 Of *Szilveszter Nadas
>                 I have seen that the BoF was not approved for IETF 90.
>                 Did you receive a more detailed explanation of the
>                 reasons?
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 22 Jul 2014 16:14:02 +0000

Dear Reinaldo et al,

Thank you for your feedback, it is based on the team discussion during yesterday’s APONF Bar BoF.

Thank you,
Tina

From: Reinaldo Penno [mailto:[email-masked]]
Sent: Tuesday, July 22, 2014 12:08 PM
To: Tina TSOU; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Aeon] Next step, IETF 90?

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

Thank you,
Tina

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear all,

Thank you,
Tina

Hi Reinaldo,

Milestones:

1)Problem Statement:

2)Architecture:

3) Use case drafts:

4) Gap analysis:

Best regards,

Georgios

Hi Reinaldo,

Best regards,

Georgios

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 22 Jul 2014 12:18:56 -0400

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:
>             models.

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 19:35:37 +0000

Hi Reinaldo,

Based on ietf-i2rs-architecture draft, I2RS provides the interface  to access (for read and write) the routing state and policy nformation on routers in the network.

So i2rs is focusing on the southbound interface.

APONF is focussing on the northbounnd interface.

Please see the attached slides!

Best regards,

Georgios

Verzonden: dinsdag 22 juli 2014 18:18

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.

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Reinaldo,

Milestones:

1)Problem Statement:

2)Architecture:

3) Use case drafts:

4) Gap analysis:

Best regards,

Georgios

Hi Reinaldo,

Best regards,

Georgios

thanks,

Monday:

Tuesday:
12:00pm, Room York

Wednesday:

Thank you,
Tina

Dear all,

Thank you,
Tina

Hi Peng,

Best regards,

Georgios

Hi Peng,

Thank you very much!

Best regards,
Peng

Best regards,
Georgios

Best regards,
Peng

Hi Tina and Georgios,

Hi all.

Best regards,

Georgios

Good catch!

Thank you,
Tina

"

Dear all,

Cheers,
Charles

Milestones:

Thank you,
Tina
-----------

Thank you,
Tina

Best regards,
Peng

Hi All,

Best Regards,
Szilveszter