Subject: [Openv6] APONF and its relationship to AECON and SFC

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Jul 2014 06:43:55 -0400

Having reviewed AECON and SFC documentation, I reread the APONF problem 
statement to more clearly understand exactly what that document is 
proposing. This note starts by laying out my understanding of APONF, and 
then showing its relationship to the other two initiatives. At an 
appropriate time I could follow up this note with proposed changes in 
text for the problem statement, but I imagine it would be a while before 
we get down to that sort of detail. At this point, the APONF proposal 
appears to me to be one for a new management protocol to add to COPS, 
SNMP, and NETCONF. I wouldn't mind having my think straightened out if 
that is not the case.

USE CASE EXPECTATIONS
=====================

First, a review of what the APONF use case documents expect of APONF. In 
summary, the use cases expect the following:

(1) Collection of current configuration and policy from network devices. 
The most demanding statement of this requirement is provided in the SAVI 
use case, draft-bi-aponf-sdsavi-00.txt:

<quote>

3.1.  Element View Collection

    From the interfaces provided by APONF, the SAVI solution at first
    collects the related elements.  An incomplete list contains: the
    address assignment mechanisms and their priorities, the topologies,
    the roles of network devices(e.g., host, DHCP server/relay,
    switches), the address transition mechanisms, the supported local/
    cross-network mobility mechanisms, the tunnel/encapsulation/
    decapsulate configuration and mechanisms, the address authentication
    mechanisms, etc.

</quote>

(2) Identification of the devices affected by a specific service 
instance being processed by a specific management application.

(3) Conveyance of information generated by individual management 
applications to the affected devices. This information can vary in scope 
from link-related parameters for algorithms running on the network 
devices, through per-subscriber and per-flow policy.

A HIGH LEVEL PICTURE
====================

The high-level picture of APONF operation is much simplified from my 
previous view.

                            O
                           /|\
                           /_\
              ----------------------------------
              |      Network management        |
              |        application             |
              | (SAVI, OpenV6, inter-DC, etc.) |
              |       APONF mapping?           |
              ----------------------------------
                            |
                 /\       APONF
              Network   transport    Policy &
                data        |      configuration
                            |        updates
                            |           \/
                            |
                   -------------------
                   | Network devices |
                   |                 |
                   -------------------

RELATIONSHIP TO AECON
=====================

I think previous discussion has established that there is no necessary 
relationship between APONF and AECON. Possibly APONF could be used to 
place policy on devices relating to specific AECON code points.

RELATIONSHIP TO SFC
===================

SFC has the potential to be as central to packet processing within an 
individual domain as digit translation was to call processing in circuit 
switches. The Service Function Chain potentially includes encapsulation, 
decapsulation, and IP header modification, which in turn require 
resubmission to the SF Forwarding Function to determine the next step in 
the processing chain.

The SFC architecture (draft-merged-sfc-architecture-00, not yet a WG 
document) is illustrated in the following figure:

       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
       .  +--------------+                  +------------------~~~
       .  |   Service    |       SFC        |  Service  +---+   +---+
       .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
    +---->|   Function   |+---------------->|   Path    +---+   +---+
       .  +--------------+                  +------------------~~~
       . SFC-enabled Domain
       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A more detailed breakdown of the right-hand-side of this figure follows.

       +----------------+                        +----------------+
       |   SFC-aware    |                        |  SFC-unaware   |
       |Service Function|                        |Service Function|
       +-------+--------+                        +-------+--------+
               |                                         |
         SFC Encapsulation                       No SFC Encapsulation
               |                                         |
               |           SFC Encapsulation        +---------+
               +------------------+   +-------------|SFC Proxy|
                                   \ /              +---------+
                            +-------+--------+
                            |   SF Forwarder |
                            |      (SFF)     |
                            +-------+--------+
                                    |
                            SFC Encapsulation
                                    |
                            +-------+--------+
                            |  SFC Network   |
                            | Forwarder (NF) |
                            +----------------+
                                    |
                        ... SFC-enabled Domain ...
                                    |
                        Network Overlay Transport
                                    |
                                _,....._
                             ,-'        `-.
                            /              `.
                           |     Network    |
                           `.              /
                             `.__     __,-'
                                 `''''

APONF may complement SFC by providing the SFC Forwarder (SFF) with an 
up-to-date picture of available devices and their roles. The SFC charter 
leaves this point open:

<quote>

4. Control Plane Mechanisms: A document will be developed to describe
requirements for conveying information between control or management
elements and SFC implementation points. All protocol extension work
resulting from these requirements should be carried out in the
working group responsible for the protocol being modified in
coordination with this working group, but may be done in this working
group under a revised charter after agreement with all the relevant
WG chairs and responsible ADs.

</quote>

The first bullet of the APONF statement of requirements and objectives 
(Section 4) makes no sense as I read it:

<quote>

o) monitor and verify the freshness of the network service graph.

</quote>

A network service graph is information conveyed in the SFC 
Encapsulation, which is implanted by the Service Classification Function 
and updated by the Service Function or its proxy (see above). The 
relationship between network service graphs (AKA Service Function 
Chains) and classifying information is something that could be updated 
by an APONF management application, but I can't see that as changing 
(losing freshness) without management action.

Tom Taylor

---

From: <[email-masked]>
Date: Tue, 15 Jul 2014 19:12:59 +0000

Hi Tom,

Thank you very much for your comments!
Thank you very much for reading these documents. 
Please note that I am on holidays and I have very sporadic Internet access.
I am very sorry, but I think that the view that you have obtained 
on what APONF should be doing is not the right one. Actually the 
previous view that you provided in a figure in one of your previous emails is closer to the activities that APONF should be working on.
Actually, I have used the figure that you provided in one of your  previous emails and I have updated it to match the APONF scope.
The updated figure can  be seen below. Please note that I 
am willing to use this figure in a new version of the problem statement draft.

                       -------------------------
                       |  End user             |
                       | application developer |
                       -------------------------
                              |                              
                              |
                      (partially) AECON-developed interface
                      (partially) SFC-developed model
                       ------------------------
                       | Network management   |
                       |   application system |
                       ------------------------
                                |
                                |     APONF
                                |   transport
                                |
                                | (communicates up to date 
                                | attributes of extended 
                                | network 
                                | service graphs
                                |  
                                |
                       --------------------------
                       | Network management     |
                       | control systems        |
                       | (APONF is mapping      |
                       |  attributes of         |
                       | network service graphs |
                       | to specific network    | 
                       | management policies,   | 
                       | i.e., device level     |
                       | configuration models)  |
                        -------------------------
                                     |
                                     |
                                     |
                 +-------------------+------------------+
                 |                                      |
                 |                                      |
                 |                                      |
   +-------------v---------------+         +------------v-------------+
   |                             |         |                          |
   |                             |   ...   |                          |
   | Network Element             |         | Network Element          |
   +-----------------------------+         +--------------------------+
In addition to the above, please note that the current version of the problem statement draft does not contain a clear definition of what 
a network service graph is.
In the context of APONF, a network service graph provides an abstraction view of a network infrastructure, which also encomprises 
netwrok service attributes. The network service attributes are network management application dependend which may include the network topology used by a network management application, the used flow steering policy, the IPv6 transition policy, the Distributed Data Center application policy. These attributes can be extended based on the 
requirements imposed by the network management application.
For each network service instance, i.e., netwok management application 
instance, an unique network service graph needs to be generated and 
maintained.
> Having reviewed AECON and SFC documentation, I reread the APONF 
> problem statement to more clearly understand exactly what 
> that document is proposing. This note starts by laying out my 
> understanding of APONF, and then showing its relationship to 
> the  other two initiatives. At an 
> text for the problem statement, but I imagine it would be a while 
> before we get down to that sort of detail. At this point, the APONF 
> proposal appears to me to be one for a new management protocol to add 
> to COPS, SNMP, and NETCONF. I wouldn't mind having my think 
> straightened out if that is not the case.
Georgios: Please see my explanation above!
> USE CASE EXPECTATIONS
> =====================
> First, a review of what the APONF use case documents expect of
>  APONF. In summary, the use cases expect the following:
> The most demanding statement of this requirement is provided in 
> the SAVI use case, draft-bi-aponf-sdsavi-00.txt:
Georgios: Please note that there are more APONF use cases Internet drafts available.
Regarding the use case that you are refering in this email, please note that the collection of current configuration and policy from the network is an activity that is not considered to be in the scope of APONF. The above activity it is assumed to be done by existing (or new developed, somewhere else in IETF) network management and controling policies. The APONF solution will use this information in order to obtail an up to date network service graph.
> adress assignment mechanisms and their priorities, the 
> topologies, the roles of network devices(e.g., host, 
> DHCP server/relay, switches), the address transition mechanisms, 
> the supported local/ cross-network mobility mechanisms, the 
> tunnel/encapsulation/decapsulate configuration and mechanisms, the 
> address authentication mechanisms, etc.
</quote>
> applications to the affected devices. This information can vary in 
> scope  from link-related parameters for algorithms running on the 
> network devices, through per-subscriber and per-flow policy.
Georgios: Please note that the tasks (1), (2) and (3) that you mentioned above can be realised partially by APONF.  In addition 
to what APONF provides, also existing network management and controlling policies (or extended ones that will be developed in other IETF WGs), need to be used in order to realise these tasks. 
> A HIGH LEVEL PICTURE
Georgios: Sorry, this figure is not describing the APONF view. Please see figure above.

> RELATIONSHIP TO AECON
> =====================
> I think previous discussion has established that there is no 
> necessary relationship between APONF and AECON. Possibly APONF could 
> be used to place policy on devices relating to specific AECON code 
> points.

Georgios:
According to the previous deiscussions on the AECON mailing list, 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 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

> RELATIONSHIP TO SFC
> ===================
> SFC has the potential to be as central to packet processing within 
> an individual domain as digit translation was to call processing in 
> circuit switches. The Service Function Chain potentially includes 
> encapsulation, decapsulation, and IP header modification, which in 
> turn require resubmission to the SF Forwarding Function to 
> determine the next step in the processing chain.
> The SFC architecture (draft-merged-sfc-architecture-00, not yet a 
> WG document) is illustrated in the following figure:
> APONF may complement SFC by providing the SFC Forwarder (SFF) 
> with an up-to-date picture of available devices and their roles. 
> The SFC charter  leaves this point open:
> <quote>
> 4. Control Plane Mechanisms: A document will be developed to 
> describe requirements for conveying information between 
> control or management elements and SFC implementation points. 
> All protocol extension work resulting from these requirements 
> should be carried out in the working group responsible for the 
> protocol being modified in coordination with this working group, 
> but may be done in this working group under a revised charter
> after agreement with all the relevant WG chairs and responsible ADs.
> </quote>
> The first bullet of the APONF statement of requirements 
> and objectives  (Section 4) makes no sense as I read it:
> <quote>
> A network service graph is information conveyed in the 
> SFC Encapsulation, which is implanted by the Service Classification 
> Function  and updated by the Service Function or its proxy (see 
> above). The  relationship between network service graphs (AKA Service > Function  Chains) and classifying information is something that
> could be updated by an APONF management application, but I can't see > that as changing (losing freshness) without management action.

Georgios: Please note that a network service graph is something more than what the SFC/SFP provided by the SFC WG.
As I already mentioned above each network service graph is very much dependend to one network management application instance. 
For each network service instance, i.e., netwok management application 
instance, an unique network service graph needs to be generated and 
maintained.
In the context of APONF, a network service graph provides an abstraction view of a network infrastructure, which also encomprises 
netwrok service attributes. The network service attributes are network management application dependend which may include the network topology used by a network management application, the used flow steering policy, the IPv6 transition policy, the Distributed Data Center application policy. These attributes can be extended based on the 
requirements imposed by the network management application.
In the context of the SFC WG the SFC/SFP 
most of the network service attributes mentioned above are not supported. In particular, the SFC WG defines:
   Service Function Chain (SFC):  A service Function chain defines an
   ordered set of service functions that must be applied to packets
   and/or layer-2 frames selected as a result of classification.  The
   implied order may not be a linear progression as nodes may copy to
   more than one branch.  The term service chain is often used as 
   shorthand for service function chain.
   Service Function Path (SFP):  The instantiation of a service function
   chain in the network. Packets follow a service function path from
   a classifier through the required instances of service functions
   in the network.
The main goal of APONF, see alos the Figure that I have provided above, is to:
 o) 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 signaling protocol. that has been specified by the IETF.
 o) map the attributes of the network service graph into specific 
    network management policies, i.e., device level configuration models. 

Best regards,
Georgios
> Tom Taylor

________________________________________
Van: Openv6 [[email-masked]] namens Tom Taylor [[email-masked]]
Verzonden: zondag 13 juli 2014 12:43
Aan: [email-masked]
Onderwerp: [Openv6] APONF and its relationship to AECON and SFC

USE CASE EXPECTATIONS
=====================

<quote>

</quote>

A HIGH LEVEL PICTURE
====================

                            O
                           /|\
                           /_\

RELATIONSHIP TO AECON
=====================

RELATIONSHIP TO SFC
===================

<quote>

</quote>

<quote>

</quote>

Tom Taylor

_______________________________________________
Openv6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/openv6