Subject: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments)

From: <[email-masked]>
Date: Sat, 7 Jun 2014 18:01:23 +0000

Hi all,

Please note that a request for a BOF associated with Openv6 has been requested for IETF 90.

The name of this BOF is:

APONF (Application-based Policy for Network Functions).

The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies.

For more details on APONF, please see:
http://trac.tools.ietf.org/bof/trac/#

Please note that in association with this BOF two Internet drafts have been (up to now) submitted .
These drafts are:

APONF problem statement:
http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt

APONF architecture:
http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt

Your comments on the APONF BOF, and on the Internet drafts listed above are very much appreciated!

Best regards,
Georgios Karagiannis

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2014 08:39:27 +1200

Hi,

Can you explain the specific relationship between this BOF and IPv6?
As far as I can see, it is 100% independent of the IP version (and that
is a good thing).

By the way, the topic of autonomic configuration by negotiation
between various network elements, which could include the elements
involved in the APONF scenarios, is the subject of another BOF
proposal, which also has no specific dependency on IPv6:
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal
APONF might be an additional use case for UCAN.

Regards
   Brian Carpenter

On 08/06/2014 06:01, [email-masked] wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openv6

---

From: <[email-masked]>
Date: Sun, 8 Jun 2014 07:46:14 +0000

Hi Brian,

Thanks for your comments!

Regarding the relation to openv6, please note that APONF can be used to support an operator on deploying and configuring (and dynamically reconfiguring) different IPv4/IPv6 transition solutions depending on the applied scenarios and the expected user experience.

Regarding the relation of APONF to UCAN, to my understanding, the UCAN BOF intends to expose several use cases that are focusing on Autonomic Networking (AN), i.e., self management.
APONF is focusing not focusing on solving AN issues. Please note that the dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter) are not associated with self-management.

Best regards,
Georgios

________________________________________
Van: Brian E Carpenter [[email-masked]]
Verzonden: zaterdag 7 juni 2014 22:39
Aan: Karagiannis, G. (EWI)
CC: [email-masked]
Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments)

Hi,

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2014 08:36:48 +1200

Hi Georgios,

> Regarding the relation to openv6, please note that APONF can be used to support an operator on deploying and configuring (and dynamically reconfiguring) different IPv4/IPv6 transition solutions dep…

Yes, that would be one application but I am still confused. I have seen no
other traffic on the openv6 list, so what are we doing here? Why isn't
this discussion on an APONF list, and where is the actual discussion
of openv6?

> APONF is focusing not focusing on solving AN issues. Please note that the dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter) are not associated with self-management.

Actually, any scenario that currently relies on a policy/management
function and some kind of automation is a possible use case for
autonomic networking. I don't see any of the actions involved in
APONF as being out of scope for AN. Application-based policy intent
would be considered as an input to the AN mechanisms, and the topics
that you have listed as "network management and traffic policies"
are exactly the type of objectives we would consider as targets
for autonomic negotiation between network elements.

The "the application-based policy protocol(s), mechanisms and models"
that you mention might be exactly what is needed to communicate
between applications and the AN policy mechanism.

If both BOFs are approved, we need to discuss in Toronto!

Regards,
   Brian

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Tue, 10 Jun 2014 03:03:13 +0000

Hi Brian,

Best Regards,
Cathy

> -----Original Message-----
> From: Openv6 [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Tuesday, June 10, 2014 4:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions):
> new BOF for IETF 90 (requesting comments)
> 
> Hi Georgios,
> 
> > Regarding the relation to openv6, please note that APONF can be used to
> support an operator on deploying and configuring (and dynamically
> reconfiguring) different IPv4/IPv6 transition solutions depending on the applied
> scenarios and the expected user experience.
> 
> Yes, that would be one application but I am still confused. I have seen no other
> traffic on the openv6 list, so what are we doing here? Why isn't this discussion
> on an APONF list, and where is the actual discussion of openv6?

Openv6 is one use case of APONF. We already had two side meetings of openv6 in both IETF 88 and IETF 89. 
So we hope to use the expertise in this list to discuss APONF first. 

> 
> > Regarding the relation of APONF to UCAN, to my understanding, the UCAN
> BOF intends to expose several use cases that are focusing on Autonomic
> Networking (AN), i.e., self management.
> > APONF is focusing not focusing on solving AN issues. Please note that the
> dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter) are
> not associated with self-management.
> 
> Actually, any scenario that currently relies on a policy/management function
> and some kind of automation is a possible use case for autonomic networking. I
> don't see any of the actions involved in APONF as being out of scope for AN.
> Application-based policy intent would be considered as an input to the AN
> mechanisms, and the topics that you have listed as "network management and
> traffic policies"
> are exactly the type of objectives we would consider as targets for autonomic
> negotiation between network elements.
> 
> that you mention might be exactly what is needed to communicate between
> applications and the AN policy mechanism.
APONF focuses on auto-mapping application's demand on network to the policy that can be understood by network. The applications could be the following ones, e.g., Traffic Engineering, Anti-DDoS, IPv6 transition, etc. These applications are not in the scope of Autonomic Network. One of APONF's objective is to define a set of models for such applications. These models may be used for AN or any other policy based use cases.  

> > Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network
> > Functions): new BOF for IETF 90 (requesting comments)
> >
> > Hi,
> >
> > As far as I can see, it is 100% independent of the IP version (and
> > that is a good thing).
> >
> >> The main goal of APONF is to specify the application-based policy protocol(s),
> mechanisms and models required by transport applications to easily, accurately,
> and efficiently select and use the available communication network capabilities,
> i.e., network management and/or traffic policies.
> >>

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 05:16:05 +0000

Hi Brian,

In addition to what Cathy answered I would like to mention that yes, it will be good to meet in Toronto and discuss the issues that you mentioned!

Best regards,
Georgios

________________________________________
Van: Zhouqian (Cathy) [[email-masked]]
Verzonden: dinsdag 10 juni 2014 5:03
Aan: Brian E Carpenter; Karagiannis, G. (EWI)
CC: [email-masked]
Onderwerp: RE: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments)

Hi Brian,

Best Regards,
Cathy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jun 2014 08:49:13 +1200

Yes, we should discuss and hopefully attend both BOFs to improve
understanding.

I think the point where our ideas touch is one item in the
draft charter that was just circulated:

> * provide mechanisms that can accurately map and store the
> APONF groups/classes of application policies and models into
> existing network management and traffic policies.

This isn't easy, because existing NM and policy mechanisms are
basically a mess. Autonomic Networking would be a *new*
approach to the problem of getting appropriate configuration
into all network elements. There would be a new bullet:

 * provide mechanisms that can accurately map and store the
 APONF groups/classes of application policies and models into
 autonomic networking policy intent, so that autonomic networking
 mechanisms can implement the policies throughout the network.

Regards
   Brian Carpenter

---

From: Felix <[email-masked]>
Date: Wed, 11 Jun 2014 02:17:05 +0000

> Sent: Wednesday, June 11, 2014 4:49 AM
> Cc: Zhouqian (Cathy); [email-masked]
> I think the point where our ideas touch is one item in the draft charter that was
> just circulated:
> 
> > * provide mechanisms that can accurately map and store the APONF
> > groups/classes of application policies and models into existing
> > network management and traffic policies.
> 
> This isn't easy, because existing NM and policy mechanisms are basically a
> mess. Autonomic Networking would be a *new* approach to the problem of
> getting appropriate configuration into all network elements. There would be a
> new bullet:
> 
>  * provide mechanisms that can accurately map and store the  APONF
> groups/classes of application policies and models into  autonomic networking
> policy intent, so that autonomic networking  mechanisms can implement the
> policies throughout the network.
> 

I think that the application's demands on network are limited types. Each type of demands on network may be similar. And the demands on network are based on the capabilities that network can provide. Currently, the application can not directly let its demands be known by network. The applications must put their demands to the OSS/BSS or OSS/BSS-like component. After the demands are permitted by the operator, the demands can be enforced on network. The cycle is too long and instant demands can't be achieved.

If there is a mechanism and a set of models (e.g. Yang models) of the demands for the application to use the network capabilities instantly, the application can use the network capabilities easily and the deployment of new application/service will be accelerated. To let application easily use network capabilities and to let the acceleration of new application/service deployment, "mapping application's demands on network to the policy understood by network" and "a set of models (e.g. Yang models) for different types demands on network", may needed in IETF. So, after authorization, the application can use related network capabilities within the allowable range in an open way. This is useful for new application innovation and the openness of network capabilities to application.

> > In addition to what Cathy answered I would like to mention that yes, it will be
> good to meet in Toronto and discuss the issues that you mentioned!
> >
> > Best regards,
> > Georgios
> >
> >
> > Onderwerp: RE: [Openv6] APONF (Application-based Policy for Network
> >> reconfiguring) different IPv4/IPv6 transition solutions depending on
> >> the applied scenarios and the expected user experience.
> >>
> >> Yes, that would be one application but I am still confused. I have
> >> seen no other traffic on the openv6 list, so what are we doing here?
> >> Why isn't this discussion on an APONF list, and where is the actual
> discussion of openv6?
> >
> >> BOF intends to expose several use cases that are focusing on
> >> Autonomic Networking (AN), i.e., self management.
> >> dynamic (re)configuration issues mentioned in the APONF BOF
> >> (pre-charter) are not associated with self-management.
> >>
> >> autonomic networking. I don't see any of the actions involved in APONF as
> being out of scope for AN.
> >> Application-based policy intent would be considered as an input to
> >> the AN mechanisms, and the topics that you have listed as "network
> >> management and traffic policies"
> >> are exactly the type of objectives we would consider as targets for
> >> autonomic negotiation between network elements.
> >>
> > APONF focuses on auto-mapping application's demand on network to the
> policy that can be understood by network. The applications could be the
> following ones, e.g., Traffic Engineering, Anti-DDoS, IPv6 transition, etc. These
> applications are not in the scope of Autonomic Network. One of APONF's
> objective is to define a set of models for such applications. These models may
> be used for AN or any other policy based use cases.
> >
> >
> >>>> Please note that a request for a BOF associated with Openv6 has
> >>>> been
> >> requested for IETF 90.
> >>>> The name of this BOF is:
> >>>>
> >> mechanisms and models required by transport applications to easily,
> >> accurately, and efficiently select and use the available
> >> communication network capabilities, i.e., network management and/or
> traffic policies.
> >>>> Please note that in association with this BOF two Internet drafts
> >>>> have been
> >> (up to now) submitted .
> >>>> These drafts are:
> >>>>
> >>>> APONF problem statement:
> >>>> http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-
> >>>> 00
> >>>> .txt
> >>>>
> >>>> APONF architecture:
> >>>> Your comments on the APONF BOF, and on the Internet drafts listed
> >>>> above
> >> are very much appreciated!
> >>>> Best regards,
> >>>> Georgios Karagiannis
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> ---
> >>>>