[Openv6] possible use of APONF in realising google's view on application based policy

<karagian@cs.utwente.nl> Thu, 19 June 2014 06:40 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 4751C1A031D for <openv6@ietfa.amsl.com>; Wed, 18 Jun 2014 23:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 raYNcgOLoP2r for <openv6@ietfa.amsl.com>; Wed, 18 Jun 2014 23:40:30 -0700 (PDT)
Received: from out46-ams.mf.surf.net (out46-ams.mf.surf.net [145.0.1.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB9D1A0323 for <Openv6@ietf.org>; Wed, 18 Jun 2014 23:40:29 -0700 (PDT)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5J6eQc0024295 for <Openv6@ietf.org>; Thu, 19 Jun 2014 08:40:26 +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; Thu, 19 Jun 2014 08:40:34 +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; Thu, 19 Jun 2014 08:40:26 +0200
From: karagian@cs.utwente.nl
To: Openv6@ietf.org
Thread-Topic: possible use of APONF in realising google's view on application based policy
Thread-Index: AQHPi4csFoZGJCg+1EqdBuzTtWYNQg==
Date: Thu, 19 Jun 2014 06:40:25 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434@EXMBX23.ad.utwente.nl>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [86.91.134.3]
Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434EXMBX23adutwent_"
MIME-Version: 1.0
X-Bayes-Prob: 0.0001 (Score 0, 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: 0vMg6EqrO - 27eacff1a419 - 20140619 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/GZjIgODdhlI1j-mRGCFIP0ylkyw
Subject: [Openv6] possible use of APONF in realising google's view on application based policy
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: Thu, 19 Jun 2014 06:40:33 -0000

Dear all,



In this email I will try to clarify the scope of APONF by using an example.



This example is based on how the view of google on application based policy could be realised in the context of IETF.



The main goal of application based policy according to google is:



"Google’s goal here is to create an abstracted view of the network, so that you’re programming the abstraction, rather than manipulating individual devices. That way, you can write software that programs an arbitrary network.", cited from:



http://www.sdncentral.com/news/google-open-source-help-policy-based-sdn/2014/06/



This vision can be realised within the IETF as follows:



The abstract view of the network can be realised by using the Service Function Path (SFP), specified by the IETF SFC WG.



In adition to this, a way is needed to provide the SFP network view to application developers, such that the application developer can use this SFP during the development, but also runtime phases, such that the application can utilize the network configuration and resources in the most optimum way.



Note that a Service Function Path (SFP) is being specified in the IETF SFC WG.



What APONF can do is the following (scope of APONF):



o) monitor and verify the freshness of the Service Function Path (SFP)



o) distribute the SFP to network management applications (OSS applications). Note that a network management application are Operational Support System (OSS) applications
that help a communications service provider to monitor, control, analyze and manage a communication network.



o) any modifications done by network management applications on an SFP are communicated to the network management system



o) The network management system needs to use the updated SFP and implement the possible configuration changes! This action is out of the APONF scope.



Comments are very much appreciated!

Best regards,
Georgios Karagiannis