[Openv6] APONF and its relationship to AECON and SFC

[Tom Taylor <[e-mail]>]

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