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

[Reinaldo Penno <[e-mail]>]

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] <[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 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" <[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] <[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
>
>