Re: [Openv6] APONF and its relationship to AECON and SFC
<karagian@cs.utwente.nl> Tue, 15 July 2014 19:13 UTC
Return-Path: <karagian@cs.utwente.nl>
X-Original-To: openv6@ietfa.amsl.com
Delivered-To: openv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23451B2919 for <openv6@ietfa.amsl.com>; Tue, 15 Jul 2014 12:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqXnvMYnunwB for <openv6@ietfa.amsl.com>; Tue, 15 Jul 2014 12:13:05 -0700 (PDT)
Received: from out28-ams.mf.surf.net (out28-ams.mf.surf.net [145.0.1.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20C41B2900 for <openv6@ietf.org>; Tue, 15 Jul 2014 12:13:04 -0700 (PDT)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s6FJD1Sc021150; Tue, 15 Jul 2014 21:13:01 +0200
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 15 Jul 2014 21:13:02 +0200
Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 21:13:00 +0200
From: karagian@cs.utwente.nl
To: tom.taylor.stds@gmail.com, openv6@ietf.org
Thread-Topic: [Openv6] APONF and its relationship to AECON and SFC
Thread-Index: AQHPnodfz8eYkK+NY0COn7dvNE/zdpuhhD1m
Date: Tue, 15 Jul 2014 19:12:59 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F5D5736B9@EXMBX23.ad.utwente.nl>
References: <53C262EB.1050207@gmail.com>
In-Reply-To: <53C262EB.1050207@gmail.com>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [94.69.231.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Bayes-Prob: 0.9999 (Score 4.7, tokens from: utwente-out:default, base:default, @@RPTN)
X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6
X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default)
X-Canit-Stats-ID: 0uMqHd1oG - 0134b38acdf9 - 20140715
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/cLaRFcqlsLuy1MdlNeGtuYdd068
Subject: Re: [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: Tue, 15 Jul 2014 19:13:09 -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
> 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.
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:
> (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:
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.
> <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
> 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>
> (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.
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
> ====================
> 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 |
> | |
> -------------------
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:
> 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.
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 [openv6-bounces@ietf.org] namens Tom Taylor [tom.taylor.stds@gmail.com]
Verzonden: zondag 13 juli 2014 12:43
Aan: openv6@ietf.org
Onderwerp: [Openv6] APONF and its relationship to AECON and SFC
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
_______________________________________________
Openv6 mailing list
Openv6@ietf.org
https://www.ietf.org/mailman/listinfo/openv6