[Openv6] APONF and its relationship to AECON and SFC

Tom Taylor <tom.taylor.stds@gmail.com> Sun, 13 July 2014 10:44 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 930171B2A4D for <openv6@ietfa.amsl.com>; Sun, 13 Jul 2014 03:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PbhP6UJok53e for <openv6@ietfa.amsl.com>; Sun, 13 Jul 2014 03:43:58 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E231B2A43 for <openv6@ietf.org>; Sun, 13 Jul 2014 03:43:58 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id at20so2394825iec.11 for <openv6@ietf.org>; Sun, 13 Jul 2014 03:43:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=yw4OYklPxbcBiG4kbdDDo+WEu2wLfIm9MDc2+SVwQJM=; b=n2WMNoMrPfChD0RO4OUYhpdAZriv5tIko7eGmPo4q3tXyT3QSVX5WdUHixt7J6Gs2e q5u109OaiCmypGCIaV0EnZSqJdWAcKh8lEHKWzRiRSb88mjpxR295gUUP9LQCOslLv+R aW9NTsFgr7PJjnNd2yFKuHgofv+mwiqrZ1RRjuVJkE5kBp0tJEbAMtprUWBK9IMJhuJv qAssg+kORDix9xyEvB3t9ga5cHpR6DUWIxTDKAEZQ+C2JdeBpbmMD7nP3trLdwE3pCg2 Q8jkaZa0l27241RP1wGc3jD+gNxpjdAhQ7YNTdkBHHr/pjdwh5G1vKIMwQAkIxBeRE0C dKuQ==
X-Received: by with SMTP id qo2mr4013295igb.12.1405248237546; Sun, 13 Jul 2014 03:43:57 -0700 (PDT)
Received: from [] (dsl-173-206-11-121.tor.primus.ca. []) by mx.google.com with ESMTPSA id hu10sm14106367igb.22.2014. for <openv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jul 2014 03:43:57 -0700 (PDT)
Message-ID: <53C262EB.1050207@gmail.com>
Date: Sun, 13 Jul 2014 06:43:55 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "openv6@ietf.org" <openv6@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/UUe55DQblVXKl-1r1w6nldmOd58
Subject: [Openv6] APONF and its relationship to AECON and SFC
X-BeenThere: openv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Openv6 discussion list <openv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openv6>, <mailto:openv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openv6/>
List-Post: <mailto:openv6@ietf.org>
List-Help: <mailto:openv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openv6>, <mailto:openv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jul 2014 10:44:00 -0000

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.


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:


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.


(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.


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

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


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.


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:


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.


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


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


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