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

"Liushucheng (Will)" <liushucheng@huawei.com> Sat, 28 June 2014 12:53 UTC

Return-Path: <liushucheng@huawei.com>
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 1433D1A0153 for <openv6@ietfa.amsl.com>; Sat, 28 Jun 2014 05:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 ADHpxfVOWVjx for <openv6@ietfa.amsl.com>; Sat, 28 Jun 2014 05:53:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D861A0151 for <Openv6@ietf.org>; Sat, 28 Jun 2014 05:53:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJJ00560; Sat, 28 Jun 2014 12:53:44 +0000 (GMT)
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 28 Jun 2014 13:53:43 +0100
Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.118]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Sat, 28 Jun 2014 20:53:36 +0800
From: "Liushucheng (Will)" <liushucheng@huawei.com>
To: "karagian@cs.utwente.nl" <karagian@cs.utwente.nl>, "Openv6@ietf.org" <Openv6@ietf.org>
Thread-Topic: possible use of APONF in realising google's view on application based policy
Thread-Index: AQHPi4csFoZGJCg+1EqdBuzTtWYNQpuGg/4g
Date: Sat, 28 Jun 2014 12:53:35 +0000
Message-ID: <C9B5F12337F6F841B35C404CF0554ACB5FF1F141@SZXEMA509-MBS.china.huawei.com>
References: <FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434@EXMBX23.ad.utwente.nl>
In-Reply-To: <FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434@EXMBX23.ad.utwente.nl>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.78.79]
Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF1F141SZXEMA509MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/d2BJmfsKjHrrnzy-Y_AvXha7zxY
Subject: Re: [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: Sat, 28 Jun 2014 12:53:50 -0000

Dear Georgios,

I agree that this may be a strong use case to show how a service provider to make good use of APONF, specially on the words "abstracted view of the network, so that you're programming the abstraction", which IMHO means to abstract the common parts and models from the existing complex and  diversiform network devices and architectures. During our survey in last year for the Openv6 work, we found that the network devices and architectures vary from each other in different countries. This may be a headache especially to those big global network service companies like google, as they may need to change their programming strategy according to the particular scenarios.

And you're right. The points you listed are out of scope of SFC WG, and should be covered in IETF.

I think a detailed use case draft describing the google case may be very helpful to clarify the scope as well as to enhance the significance of APONF.

Regards,
Will

From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Thursday, June 19, 2014 2:40 PM
To: Openv6@ietf.org
Subject: [Openv6] possible use of APONF in realising google's view on application based policy


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