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

["Fan, Peng" <[e-mail]>]

Hi Georgios,

 

Please see my reply Inline [FP], thanks.

 

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

 

Hi Peng,

 

Thank you very much!

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

 

AECON works on interfaces and mapping between the configuration intent
coming from end user applications <=> network configuation & network
topology known to the network management application systems (e.g. OSS)

 

APONF works on interfaces and mapping between network configuation & network
topology (known to the network management application systems (e.g.OSS)) <=>
network management policies, i.e., device configuration Models.

[FP] I believe Charles and I have stated in the previous emails that AECON
is NOT about network configuration, so is not going to satisfy end user
applications' configuration intent (if they have such intent). Charles gave
some clarification in the thread of commenting APONF problem statement draft
on openv6 mailing list and I hope that would help APONF architecture
evolvement.

 

Regarding your suggestion on replacing that term "application" from the name
of the APONF activity,

you are right, but we prefer to do this after we get the Okay from the IESG
that we are on the right track!

 

Regarding the AECON-APONF discussion meeting that has been proposed by Eliot
and Ted, 

maybe it will be good to prepare and have some slides. 

 

>From APONF side we will prepare few slides that describe APONF

Moreover, Tina is preparing a presentation that shows the differences
between AECON and APONF.

It will be great if you could have a presentation that describes AECON.

[FP] We will, as scheduled.

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

[FP] You are welcome to send me slides from your side prior to the meeting.

 

Best regards,

Peng

 

 

Best regards,

Georgios

  _____  

Van: Aeon [[e-mail]] namens Fan, Peng [[e-mail]]
Verzonden: woensdag 9 juli 2014 14:49
Aan: 'Charles Eckel (eckelcu)'; Karagiannis, G. (EWI);
[e-mail]; [e-mail]
CC: [e-mail]; [e-mail]; [e-mail]
Onderwerp: Re: [Aeon] Next step, IETF 90?

Hi Tina, Georgios,

 

First, I agree with Charles on the comments on both difference between AECON
and APONF and charter of APONF. AECON aims to be a quite lightweight method
focusing on information exchange, and neither application nor network is
entitled to make any change to each other, which has not changed ever since
the very beginning of this proposal. AECON is not quite related with
"configuring" the network.

 

Speaking of the difference between the two proposals you gave in this
thread, I recall the saying I received a month ago when I first knew about
APONF: "APONF is about specialized applications *managing* the network, not
general applications using it", and I have to say that I would rather use
that version if I had to choose one from the two.

 

So it is really important that we figure out clearly what we want to do in
the respective proposals. I see that drafts and charter of APONF has been
evolving, and I guess the APONF concept and boundary is developing too. My
understanding is that perhaps you are working on some kind of north-bound
application (specialized application) in an SDN like architecture, and
targeting on network management and configuration (I also saw the target
area was changed to OPS), and if that is true is it possible to specify it
in the charter and limit the scope as e.g. north-bound network management
method? The wording "application" is somewhat misleading especially to
people not familiar with our proposals as it is not generally used to say
"specialized application".

 

Before we have a clear picture of the proposal, I would not try to place
AECON into an APONF architecture. Maybe AECON can be used to help APONF
work, but that depends on how APONF is working. As for now, I would regard
it as an effective and straightforward way to convince people that there is
no overlap or connection between the two proposals.

 

Best regards,

Peng

 

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

 

Hi Tina and Georgios,

 

I mostly agree with your statements differentiating APONF and AECON.
However, there are a few things that I think create confusion. Please see
inline.

 

From: "[e-mail]" <[e-mail]>
Date: Thursday, July 3, 2014 at 12:25 AM
To: "[e-mail]" <[e-mail]>,
"[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>,
"[e-mail]" <[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Aeon] Next step, IETF 90?

 

Hi all.

 

The use of SCF/SFP in the charter is to show that APONF will use any
guidelines/modeling language that will be proposed by the SCF WG on
creating/modifying SCF/SFPs service templates.

 

Regarding AECON and APONF, I agree with Tina:

 

AECON works on interfaces and mapping between the configuration intent
coming from end user applications <=> network configuation & network
topology known to the network management application systems (e.g. OSS)

 

AECON is about communication between end user applications and the network;
however, it is NOT about network configuration. With AECON, end user
applications (NOT network management applications) describe their flows to
the network without any knowledge of the configuration of the network, nor
any authority to change that configuration. Network entities provide
feedback to the end user application regarding network conditions and
anticipated handling of the application's flows. Network configuration
information is NOT shared with the applications. Network configuration and
network management are outside of the scope of AECON.

 

 

APONF works on interfaces and mapping between network configuation & network
topology (known to the network management application systems (e.g.OSS)) <=>
network management policies, i.e., device configuration Models.

 

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

 

 

Best regards,

Georgios

 

 


  _____  


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

Dear Reinaldo, Michael et al,

 

Good catch!

 

I just pulled things together into a charter, while talking to the
proponents, below was what I understood.

 

Regarding SFC/SFP in the charter, the original idea was to make use of this
concept to describe network topology and traffic path. However, this
obviously brought confusion. What APONF needs is, for example, a distributed
data center application (traffic engineering between data centers) may need
the network topology and traffic path, so it can require the APONF to
re-configure the related network nodes of the path to achieve its goal. 

Perhaps another version of charter is needed to clarify this.

 

AECON works on interfaces and mapping between the configuration intent
coming from end user applications <=> network configuation & network
topology known to the network management application systems (e.g. OSS)

 

APONF works on interfaces and mapping between network configuation & network
topology (known to the network management application systems (e.g.OSS)) <=>
network management policies, i.e., device configuration Models.

 

 

Thank you,

Tina

 

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

 

To the untrained eye there is a lot of overlap unless I'm not reading
correctly.

"b) Specify a new NSLP (NSIS Signaling Layer Protocol), similar to the
NAT/Firewall NSLP and QoS NSLP that can be applied and support the APONF use
cases. "

" 

o) specify extensions to the IETF NSIS protocol to distribute the SFP based
network configuration and network topology models between network management
applications (e.g., OSS applications) and e.g., the network management
system, the routing controlling system or other controlling systems. The
IETF Next Steps in Signaling (NSIS) protocol may be extended in two ways to
support this interface:

a) Extend NSIS GIST to be used for off-path support"

 

 

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

SFC WG has both data plane and control plane work in the charter. Nothing
preclude to have modeling of services policies as one of the charter items
in AEON 

 

On Wed, Jul 2, 2014 at 7:06 AM, Tina TSOU <[e-mail]>
wrote:

Dear Peng, Szilveszter, et al,

 

There is a connection between AECON and APONF, but no overlapping. 

 

See below the current APONF draft charter.

 

From: Openv6 [mailto:[e-mail]] On Behalf Of Tina TSOU
Sent: Monday, June 30, 2014 5:51 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Openv6] Is there a draft charter for APONF?

 

Dear all,

 

Based on everybody's feedback, here comes the 3rd version of the charter.

 

Hope it is more precise and concrete for you to comment on.

 

------------------------------------

APONF (Application-based Policy for Network Functions) charter

 

Target Area: Operations and Management Area

 

Description of Working Group:

 

Today network operators are challenged to create an abstract view of their
network infrastructure and help service developers on using and programming
this 

 

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

 

abstraction rather than  manipulating individual devices. An abstract view
of a network infrastructure can be realized using  a network configuration
model, that provides a declarative configuration and a network topology
model that describes a multi-layer network. Network management applications
are Operational Support System (OSS) like applications that help a
communication service provider to monitor, control, analyze and manage a
communication network.

In this context, network management applications can be used to provide the
required configuration and application programming interfaces to such
service developers. Subsequently, a network management application can use
the application based demands and possibly update its associated network
configuration and/or network topology model. Examples of network management
applications that can modify the network configuration and/or network
topology models are for example, virtual network function services,
Distributed Data Center Application, IPv6 transitions, streaming and IoT
applications, need to change the network infrastructure configuration.

The updated network configuration and network topology model needs to be
communicated to e.g., the network management system, the routing controlling
system or other controlling systems, to map the network configuration and
network topology models into specific device level configuration models.

 

Currently, there are no IETF standard mechanisms or modeling languages that
can directly be applied to model the network configuration nor the network
topology. IETF has however, created the IETF SFC WG to document a new
approach to service delivery and operation, where one of its goals is to
realize an abstract view of a network by using a service graph denoted as
the Service Function Path (SFP). This will enable the development of
suitable models for network configuration and network topology.

Furthermore, there are currently no IETF solutions that can be used to
provide the necessary configuration interfaces to service developers to
program the abstract view of a network infrastructure. Currently, the
Application Enabled Collaborative Network (AECON) activity can provide these
necessary solutions.

 

Same comment as above about developers. More importantly, I do not see AECON
providing a solution for programming network infrastructure. This seems more
in the realm of SDN and/or SFC.

 

 

Moreover, there are no IETF solutions that can directly be used to (1)
enable the streaming transfer of bulk-variable/data of network configuration
and network topology models between network management application systems
and e.g., the network management system, the routing controlling system or
other controlling systems, and (2) map the network configuration and network
topology models into specific device level configuration models. The APONF
activity can provide a solution to this challenge.

 

The main goal of APONF is to:

o) enable the streaming transfer of bulk-variable/data of the up to date SFP
based network configuration and network topology models between network
management application systems and e.g., the network management system, the
routing controlling system or other controlling systems, by using and
extending the IETF Next Steps in Signaling Protocol (NSIS).

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

 

The APONF requirements/objectives are:

 

o) monitor and verify the freshness of the SFP based network configuration
and network topology models

 

o) extend the IETF NSIS protocol to securely and efficiently distribute the
SFP based network configuration and network topology models between network
management applications (e.g., OSS applications) and e.g., the network
management system, the routing controlling system or other controlling
systems

 

o) use application based demands generated by network management
applications to map the SFP based network configuration and network topology
models into specific device level configuration models. Such application
based demands are:

 

a) Encapsulating, de-encapsulating packets associated with a flow into a
tunnel (for example, VPN service, IPv6 transition service need to manage the
network function to do that):

 

b) blocking, or dropping packets associated with a flow in (the edge of) the
network element when the network security service is aware of the attack
(for example, SAVI service, Anti-DoS service need to manage the network
function to do that).

 

In my mind, (a) and (b) are not configuration. Rather, they are actions
based on configuration. AECON could come into play here by providing a
description of a flow that is used to determine how best to handle that
flow. The various options for handling the flow are based on network
configuration, which is outside the scope of the AECON, whereas the
identification of the flow such that it the most appropriate handling option
is selected is within the scope for AECON.

 

Cheers,

Charles

 

 

c) configure and dynamically reconfigure data centers to the steer and
reroute traffic associated with a specific flow

 

d) configure and dynamically reconfigure data centers to  change priorities
of different types of traffic associated with a specific flow

 

e) Logging the traffic associated with a flow for network security service,
optimization of the traffic in network for IETF ALTO service

 

f) other actions defined by the administrator

 

o) specify the Authentication Authorization and Accounting (AAA) method

 

Work items related to APONF include:

o) specify the problem statement and use cases

 

o) specify the APONF architecture

 

o) specify extensions to the IETF NSIS protocol to distribute the SFP based
network configuration and network topology models between network management
applications (e.g., OSS applications) and e.g., the network management
system, the routing controlling system or other controlling systems. The
IETF Next Steps in Signaling (NSIS) protocol may be extended in two ways to
support this interface:

a) Extend NSIS GIST to be used for off-path support

 

b) Specify a new NSLP (NSIS Signaling Layer Protocol), similar to the
NAT/Firewall NSLP and QoS NSLP that can be applied and support the APONF use
cases. 

 

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

 

o) specify the AAA method.

 

Milestones:

 

I-D 'Problem Statement and Use Cases' as an Informational RFC.

 

I-D 'APONF Architecture' as an Informational RFC.

 

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

 

I-D 'APONF based NSIS Protocol Specification' Standards Track RFC.

--------------------------------------

 

 

Thank you,

Tina

-----------

 

Thank you,

Tina


On Jul 2, 2014, at 9:17 PM, "Fan, Peng" <[e-mail]> wrote:

Hi all,

 

As you may noticed there is not a BOF this time at IETF90. We will be
presenting on Tuesday during the IETF week to the IESG and IAB to address
concerns and questions in regard to AECON and APONF, and have a barBOF/side
meeting sometime after that.

 

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

 

Best regards,

Peng

 

From: Aeon [mailto:[e-mail]] On Behalf Of Szilveszter Nadas
Sent: Monday, June 30, 2014 9:21 PM
To: [e-mail]
Subject: [Aeon] Next step, IETF 90?

 

Hi All,

 

I have seen that the BoF was not approved for IETF 90. Did you receive a
more detailed explanation of the reasons? 

 

What is the next step? Will there be a Bar BoF at Toronto?

 

Best Regards,

Szilveszter


_______________________________________________
Aeon mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/aeon