From nobody Sat Jun 7 11:01:37 2014 Return-Path: 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 5A6991A0104 for ; Sat, 7 Jun 2014 11:01:36 -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 oVvzaf1dQJjn for ; Sat, 7 Jun 2014 11:01:34 -0700 (PDT) Received: from out47-ams.mf.surf.net (out47-ams.mf.surf.net [145.0.1.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3E11A0148 for ; Sat, 7 Jun 2014 11:01:33 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s57I1Ofp028400 for ; Sat, 7 Jun 2014 20:01:24 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 7 Jun 2014 20:01:31 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Sat, 7 Jun 2014 20:01:24 +0200 From: To: Thread-Topic: APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) Thread-Index: Ac+Cen59c8170usIQealtBkWdImy7A== Date: Sat, 7 Jun 2014 18:01:23 +0000 Message-ID: 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B090EXMBX23adutwent_" 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.48; 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: 0vMbu1ob1 - 680125b241c1 - 20140607 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/WL-M1Xn9y_hu_cw_bOxRZyAHEa0 Subject: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:01:36 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B090EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please note that a request for a BOF associated with Openv6 has been reques= ted for IETF 90. The name of this BOF is: APONF (Application-based Policy for Network Functions). The main goal of APONF is to specify the application-based policy protocol(= s), mechanisms and models required by transport applications to easily, acc= urately, and efficiently select and use the available communication network= capabilities, i.e., network management and/or traffic policies. For more details on APONF, please see: http://trac.tools.ietf.org/bof/trac/# Please note that in association with this BOF two Internet drafts have been= (up to now) submitted . These drafts are: APONF problem statement: http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt APONF architecture: http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt Your comments on the APONF BOF, and on the Internet drafts listed above are= very much appreciated! Best regards, Georgios Karagiannis --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B090EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Please note = that a request for a BOF associated with Openv6 has been requested for IETF= 90.

 <= /font>

The name of = this BOF is:

 <= /font>

APONF (Appli= cation-based Policy for Network Functions).

 <= /font>

The main goa= l of APONF is to specify the application-based policy protocol(s), mechanis= ms and models required by transport applications to easily, accurately, and efficiently select and use the available commun= ication network capabilities, i.e., network management and/or traffic polic= ies.

 <= /font>

For more det= ails on APONF, please see:

http://trac.tools.i= etf.org/bof/trac/#

 <= /font>

Please note = that in association with this BOF two Internet drafts have been (up to now)= submitted .

These drafts= are:

 <= /font>

APONF proble= m statement:

http://tools.ietf.org/id/draft-karagiannis-aponf-problem-s= tatement-00.txt

 <= /font>

APONF archit= ecture:

http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt

 <= /font>

Your comment= s on the APONF BOF, and on the Internet drafts listed above are very much a= ppreciated!

 <= /font>

Best regards= ,

Georgios Kar= agiannis

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B090EXMBX23adutwent_-- From nobody Sat Jun 7 13:39:42 2014 Return-Path: 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 30B591A0195 for ; Sat, 7 Jun 2014 13:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4FkzUw0WIMt for ; Sat, 7 Jun 2014 13:39:38 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1BF1A00A5 for ; Sat, 7 Jun 2014 13:39:38 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so3856121pbb.36 for ; Sat, 07 Jun 2014 13:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BJK5+ILmbV3mg+0k64cQ4ew0U+smiL0qmP5895GcJJs=; b=nBlZwpa4sBfuZu4eYxHb0CD/mQiUjaGNjSt935+JdA1GM8ziJ81XbsiKHsJr2RhG0F cs+IuLH8TJi41xdcXPG53SGoTErtlbPDFVz61IjK9es8kv+KcIeEZGQVNcpFFa+tCqdq 7MW8fmiifmk3td0JFGhg7BejyMr+x2eSR/q3IhysQSOf4BpgWYw3OvnfL4VmD9wrFloE 9barMjfca4tLQaeGx7i9hXlElhfMEKnGxNuKAcyiyZQIoHRO4a+vuFYOnm7NEHgqfDtc 008MMbHZkWXOC89aDGMdyEPJk5Law3bVzWDKFRyeZFIRKWrwM2xY9Waig+/CvBeWDy85 QkuA== X-Received: by 10.68.239.137 with SMTP id vs9mr15108285pbc.84.1402173571148; Sat, 07 Jun 2014 13:39:31 -0700 (PDT) Received: from [192.168.178.23] (128.199.69.111.dynamic.snap.net.nz. [111.69.199.128]) by mx.google.com with ESMTPSA id jd5sm52290610pbb.18.2014.06.07.13.39.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 13:39:30 -0700 (PDT) Message-ID: <5393787F.8040301@gmail.com> Date: Sun, 08 Jun 2014 08:39:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: karagian@cs.utwente.nl References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/A9HO-jjZ0ImCFnJB7xcal4pBob8 Cc: openv6@ietf.org Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 20:39:40 -0000 Hi, Can you explain the specific relationship between this BOF and IPv6? As far as I can see, it is 100% independent of the IP version (and that is a good thing). By the way, the topic of autonomic configuration by negotiation between various network elements, which could include the elements involved in the APONF scenarios, is the subject of another BOF proposal, which also has no specific dependency on IPv6: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal APONF might be an additional use case for UCAN. Regards Brian Carpenter On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: > Hi all, > > Please note that a request for a BOF associated with Openv6 has been requested for IETF 90. > > The name of this BOF is: > > APONF (Application-based Policy for Network Functions). > > The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies. > > For more details on APONF, please see: > http://trac.tools.ietf.org/bof/trac/# > > Please note that in association with this BOF two Internet drafts have been (up to now) submitted . > These drafts are: > > APONF problem statement: > http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt > > APONF architecture: > http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt > > Your comments on the APONF BOF, and on the Internet drafts listed above are very much appreciated! > > Best regards, > Georgios Karagiannis > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 From nobody Sun Jun 8 00:46:31 2014 Return-Path: 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 429BC1A02BD for ; Sun, 8 Jun 2014 00:46:29 -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 PVDbNjbkV93U for ; Sun, 8 Jun 2014 00:46:26 -0700 (PDT) Received: from out24-ams.mf.surf.net (out24-ams.mf.surf.net [145.0.1.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E651A0299 for ; Sun, 8 Jun 2014 00:46:25 -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 s587kFLx014584; Sun, 8 Jun 2014 09:46:15 +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; Sun, 8 Jun 2014 09:46:21 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Sun, 8 Jun 2014 09:46:15 +0200 From: To: Thread-Topic: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) Thread-Index: Ac+Cen59c8170usIQealtBkWdImy7AABVD2AABqX3RE= Date: Sun, 8 Jun 2014 07:46:14 +0000 Message-ID: References: , <5393787F.8040301@gmail.com> In-Reply-To: <5393787F.8040301@gmail.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 0uMbHKfla - f0c45950a465 - 20140608 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/wuOhA2USxaIdouMmUOF-DelHke4 Cc: openv6@ietf.org Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 07:46:29 -0000 Hi Brian, Thanks for your comments! Regarding the relation to openv6, please note that APONF can be used to sup= port an operator on deploying and configuring (and dynamically reconfigurin= g) different IPv4/IPv6 transition solutions depending on the applied scenar= ios and the expected user experience. Regarding the relation of APONF to UCAN, to my understanding, the UCAN BOF = intends to expose several use cases that are focusing on Autonomic Networki= ng (AN), i.e., self management. APONF is focusing not focusing on solving AN issues. Please note that the d= ynamic (re)configuration issues mentioned in the APONF BOF (pre-charter) ar= e not associated with self-management. Best regards, Georgios ________________________________________ Van: Brian E Carpenter [brian.e.carpenter@gmail.com] Verzonden: zaterdag 7 juni 2014 22:39 Aan: Karagiannis, G. (EWI) CC: openv6@ietf.org Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network Functio= ns): new BOF for IETF 90 (requesting comments) Hi, Can you explain the specific relationship between this BOF and IPv6? As far as I can see, it is 100% independent of the IP version (and that is a good thing). By the way, the topic of autonomic configuration by negotiation between various network elements, which could include the elements involved in the APONF scenarios, is the subject of another BOF proposal, which also has no specific dependency on IPv6: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal APONF might be an additional use case for UCAN. Regards Brian Carpenter On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: > Hi all, > > Please note that a request for a BOF associated with Openv6 has been requ= ested for IETF 90. > > The name of this BOF is: > > APONF (Application-based Policy for Network Functions). > > The main goal of APONF is to specify the application-based policy protoco= l(s), mechanisms and models required by transport applications to easily, a= ccurately, and efficiently select and use the available communication netwo= rk capabilities, i.e., network management and/or traffic policies. > > For more details on APONF, please see: > http://trac.tools.ietf.org/bof/trac/# > > Please note that in association with this BOF two Internet drafts have be= en (up to now) submitted . > These drafts are: > > APONF problem statement: > http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt > > APONF architecture: > http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt > > Your comments on the APONF BOF, and on the Internet drafts listed above a= re very much appreciated! > > Best regards, > Georgios Karagiannis > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6= From nobody Mon Jun 9 02:52:25 2014 Return-Path: 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 1377B1A0041 for ; Mon, 9 Jun 2014 02:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 eLYRdE7VwUUH for ; Mon, 9 Jun 2014 02:52:20 -0700 (PDT) Received: from tsinghua.edu.cn (smtp04.tsinghua.edu.cn [166.111.204.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09B1A0040 for ; Mon, 9 Jun 2014 02:52:19 -0700 (PDT) Received: from junbithinkpadx1 (unknown [59.66.24.237]) by app2 (Coremail) with SMTP id C8xvpgDXakTQg5VT6nM5AA--.7730S2; Mon, 09 Jun 2014 17:52:16 +0800 (CST) From: "Jun Bi" To: Date: Mon, 9 Jun 2014 17:52:15 +0800 Message-ID: <008801cf83c8$7e835db0$7b8a1910$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CF840B.8CA712E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+DyDrWr9AA7zGyTimQr2mNx13iOA== Content-Language: zh-cn X-CM-TRANSID: C8xvpgDXakTQg5VT6nM5AA--.7730S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYz7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2js IEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5 JVWrJwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVW8JVW5JwAqx4xG6xAIxV CFxsxG0wAv7VC0I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCa FVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8uwCF04k20xvY0x0EwI xGrwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF 1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6x IIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY 6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa 73UjIFyTuYvj7UU6E8UUUUU X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/HxohUdNFECEDCScpCQKWLSXqVw4 Subject: [Openv6] About problem-statement for APONF BoF X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 09:52:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0089_01CF840B.8CA712E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I remember in an early version, the problem related to SAVI (source address validation improvement) was included, But I found it was removed at this version. http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt Since the problem still exists, I suggest to include it. Best Regards, Jun Bi ------=_NextPart_000_0089_01CF840B.8CA712E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0089_01CF840B.8CA712E0-- From nobody Mon Jun 9 03:27:54 2014 Return-Path: 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 67BA11A0069 for ; Mon, 9 Jun 2014 03:27:53 -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 xdIk_iDP-XMg for ; Mon, 9 Jun 2014 03:27:50 -0700 (PDT) Received: from out49-ams.mf.surf.net (out49-ams.mf.surf.net [145.0.1.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA811A0062 for ; Mon, 9 Jun 2014 03:27:50 -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 s59ARlY6008935; Mon, 9 Jun 2014 12:27:48 +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; Mon, 9 Jun 2014 12:27:48 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Mon, 9 Jun 2014 12:27:48 +0200 From: To: , Thread-Topic: [Openv6] About problem-statement for APONF BoF Thread-Index: Ac+DyDrWr9AA7zGyTimQr2mNx13iOAABJU9D Date: Mon, 9 Jun 2014 10:27:46 +0000 Message-ID: References: <008801cf83c8$7e835db0$7b8a1910$@tsinghua.edu.cn> In-Reply-To: <008801cf83c8$7e835db0$7b8a1910$@tsinghua.edu.cn> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B7DFEXMBX23adutwent_" 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: 0vMcarMqy - cc56f0babc33 - 20140609 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/hzq-iE7-HH1omzYrQhhma762jf0 Subject: Re: [Openv6] About problem-statement for APONF BoF X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 10:27:53 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B7DFEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jun Bi, Thank you for the comment! Sorry for omitting this information regarding SAVI! Can you please propose the SAVI text that we can include in the problem sta= tement draft? Best regards, Georgios ________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens Jun Bi [junbi@tsinghua.edu.cn] Verzonden: maandag 9 juni 2014 11:52 Aan: openv6@ietf.org Onderwerp: [Openv6] About problem-statement for APONF BoF I remember in an early version, the problem related to SAVI (source address= validation improvement) was included, But I found it was removed at this version. http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt Since the problem still exists, I suggest to include it. Best Regards, Jun Bi --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B7DFEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jun Bi,

 

Thank you for the comment!

Sorry for omitting this information regarding SAVI!

 

Can you please propose the SAVI text that we can include in the problem = statement draft?

 

Best regards,

Georgios

 

Van: Openv6 [openv6-bounces@ietf.org] name= ns Jun Bi [junbi@tsinghua.edu.cn]
Verzonden: maandag 9 juni 2014 11:52
Aan: openv6@ietf.org
Onderwerp: [Openv6] About problem-statement for APONF BoF

I remember in an early version,= the problem related to SAVI (source address validation improvement) was in= cluded,

But I found it was removed at t= his version.

 

http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt<= /a>

 

Since the problem still exis= ts, I suggest to include it.

 

Best Regards,

Jun Bi

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47B7DFEXMBX23adutwent_-- From nobody Mon Jun 9 08:26:41 2014 Return-Path: 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 A78241A01C5 for ; Mon, 9 Jun 2014 08:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 yHmR3vfiZZy4 for ; Mon, 9 Jun 2014 08:26:33 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DA11A0189 for ; Mon, 9 Jun 2014 08:26:28 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s59FQK3p014934 for ; Mon, 9 Jun 2014 17:26:20 +0200 From: "Jose Saldana" To: Date: Mon, 9 Jun 2014 17:26:27 +0200 Message-ID: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01CF8407.F239B760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+D9qNFruvdoEliTFauT0nZdN8okw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/6izG84nrSI3PZ_8eaIkU1sVCQKQ Subject: [Openv6] Is there a draft charter for APONF? X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:26:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01CF8407.F239B760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac/wiki. Is there a draft charter somewhere? In case not, I would suggest to write a first version and send it to the list. It would be somewhat similar to the BoF summary, but it would also include the goals and milestones, deliverables of the potential WG, interactions with other WGs, etc. Best regards, Jose Saldana ------=_NextPart_000_00B9_01CF8407.F239B760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have read the BoF summary of APONF in http://trac.tools.ietf.= org/bof/trac/wiki.

 

Is there a draft = charter somewhere? In case not, I would suggest to write a first version = and send it to the list. It would be somewhat similar to the BoF summary, but it would also include the goals = and milestones, deliverables of the potential WG, interactions with = other WGs, etc.

 

Best = regards,

 

Jose Saldana

 

------=_NextPart_000_00B9_01CF8407.F239B760-- From nobody Mon Jun 9 08:31:50 2014 Return-Path: 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 5A1521A01CA for ; Mon, 9 Jun 2014 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 8uvq9g8OycUy for ; Mon, 9 Jun 2014 08:31:46 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75D11A0068 for ; Mon, 9 Jun 2014 08:31:45 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s59FVfBk024105 for ; Mon, 9 Jun 2014 17:31:41 +0200 From: "Jose Saldana" To: Date: Mon, 9 Jun 2014 17:31:44 +0200 Message-ID: <00c901cf83f7$eb70c230$c2524690$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01CF8408.AEFAA3A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+D9zs26jdZB9oZSHK+gQOstbPTzA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/yXtVXaif5qxgoA5qTcScH5ZA1us Subject: [Openv6] Another question: the name of the functionalities X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:31:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CA_01CF8408.AEFAA3A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Another question is how to name the set of functionalities you are considering in APONF: - In the first paragraph, they are called "traffic capabilities": " the communication network to apply the following different network management and/or traffic capabilities" - Later, they are called "traffic policies": "Examples of such network management and traffic policies that are considered by APONF are the following" I think that finding a good name grouping these actions is crucial: Manage dynamically network semantics Orchestrate dynamically virtualized functions Permit or Block or Redirect the traffic Log the traffic Copy the traffic Set the traffic Mark the traffic Are they traffic policies? Network actions? Network functionalities? Network capabilities? Traffic capabilities? Network management actions? What do you think? Jose Saldana ------=_NextPart_000_00CA_01CF8408.AEFAA3A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Another question is = how to name the set of functionalities you are considering in = APONF:

 

- In the first = paragraph, they are called “traffic capabilities”: = “ the communication network to apply the following different = network management and/or traffic capabilities”

 

- Later, they are = called “traffic policies”: “Examples of such network management and traffic policies that are = considered by APONF are the following”

 

 

I think that finding a = good name grouping these actions is crucial:

 

Manage dynamically = network semantics

Orchestrate = dynamically virtualized functions

Permit or Block or = Redirect the traffic

Log the traffic =

Copy the traffic =

Set the traffic =

Mark the = traffic

 

Are they traffic = policies? Network actions? Network functionalities? Network = capabilities? Traffic capabilities? Network management = actions?

 

 

What do you = think?

 

Jose Saldana

 

------=_NextPart_000_00CA_01CF8408.AEFAA3A0-- From nobody Mon Jun 9 09:39:19 2014 Return-Path: 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 33DEE1A0096 for ; Mon, 9 Jun 2014 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 N_ihVjMzQ_mP for ; Mon, 9 Jun 2014 09:39:15 -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 5450A1A00D4 for ; Mon, 9 Jun 2014 09:39:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFF82098; Mon, 09 Jun 2014 16:39:12 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 17:39:09 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 00:39:04 +0800 From: Felix To: Jose Saldana , "Openv6@ietf.org" Thread-Topic: [Openv6] Another question: the name of the functionalities Thread-Index: Ac+D9zs26jdZB9oZSHK+gQOstbPTzAACckcZ Date: Mon, 9 Jun 2014 16:39:04 +0000 Message-ID: <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> In-Reply-To: <00c901cf83f7$eb70c230$c2524690$@unizar.es> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.37.99] Content-Type: multipart/alternative; boundary="_000_4B29BA0800EE424E850D442A1A3D180340718BEASZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/5ng4tMqV0teQqrVg7-l_ZIiI7hk Subject: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:39:17 -0000 --_000_4B29BA0800EE424E850D442A1A3D180340718BEASZXEMA510MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQoNCg0KSSBwcmVmZXIgIk5ldHdvcmsgY2FwYWJpbGl0aWVzIiBmb3IgZ3JvdXBp bmcgdGhlc2UgYWN0aW9ucy4NCg0KDQoNCkJlc3QgcmVnYXJkcyENCg0KRmVsaXgNCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBPcGVudjYgW29wZW52 Ni1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEpvc2UgU2FsZGFuYSBbanNhbGRhbmFAdW5pemFyLmVz XQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjnI1SAyMzozMQ0KytW8/sjLOiBPcGVudjZAaWV0Zi5vcmcN Ctb3zOI6IFtPcGVudjZdIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9mIHRoZSBmdW5jdGlv bmFsaXRpZXMNCg0KSGksDQoNCkFub3RoZXIgcXVlc3Rpb24gaXMgaG93IHRvIG5hbWUgdGhlIHNl dCBvZiBmdW5jdGlvbmFsaXRpZXMgeW91IGFyZSBjb25zaWRlcmluZyBpbiBBUE9ORjoNCg0KLSBJ biB0aGUgZmlyc3QgcGFyYWdyYXBoLCB0aGV5IGFyZSBjYWxsZWQgobB0cmFmZmljIGNhcGFiaWxp dGllc6GxOiChsCB0aGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrIHRvIGFwcGx5IHRoZSBmb2xsb3dp bmcgZGlmZmVyZW50IG5ldHdvcmsgbWFuYWdlbWVudCBhbmQvb3IgdHJhZmZpYyBjYXBhYmlsaXRp ZXOhsQ0KDQotIExhdGVyLCB0aGV5IGFyZSBjYWxsZWQgobB0cmFmZmljIHBvbGljaWVzobE6IKGw RXhhbXBsZXMgb2Ygc3VjaCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIHRyYWZmaWMgcG9saWNpZXMg dGhhdCBhcmUgY29uc2lkZXJlZCBieSBBUE9ORiBhcmUgdGhlIGZvbGxvd2luZ6GxDQoNCg0KSSB0 aGluayB0aGF0IGZpbmRpbmcgYSBnb29kIG5hbWUgZ3JvdXBpbmcgdGhlc2UgYWN0aW9ucyBpcyBj cnVjaWFsOg0KDQpNYW5hZ2UgZHluYW1pY2FsbHkgbmV0d29yayBzZW1hbnRpY3MNCk9yY2hlc3Ry YXRlIGR5bmFtaWNhbGx5IHZpcnR1YWxpemVkIGZ1bmN0aW9ucw0KUGVybWl0IG9yIEJsb2NrIG9y IFJlZGlyZWN0IHRoZSB0cmFmZmljDQpMb2cgdGhlIHRyYWZmaWMNCkNvcHkgdGhlIHRyYWZmaWMN ClNldCB0aGUgdHJhZmZpYw0KTWFyayB0aGUgdHJhZmZpYw0KDQpBcmUgdGhleSB0cmFmZmljIHBv bGljaWVzPyBOZXR3b3JrIGFjdGlvbnM/IE5ldHdvcmsgZnVuY3Rpb25hbGl0aWVzPyBOZXR3b3Jr IGNhcGFiaWxpdGllcz8gVHJhZmZpYyBjYXBhYmlsaXRpZXM/IE5ldHdvcmsgbWFuYWdlbWVudCBh Y3Rpb25zPw0KDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpKb3NlIFNhbGRhbmENCg0K --_000_4B29BA0800EE424E850D442A1A3D180340718BEASZXEMA510MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I prefer "Network capabilities" for grouping these action= s.

 

Best regards!

Felix

 

 

=B7=A2=BC=FE=C8=CB: Openv6 [openv6-bounces= @ietf.org] =B4=FA=B1=ED Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Openv6@ietf.org
=D6=F7=CC=E2: [Openv6] Another question: the name of the functionali= ties

Hi,

 

Another question is how to name the set of fun= ctionalities you are considering in APONF:

 

- In the first paragraph, they are called =A1= =B0traffic capabilities=A1=B1: =A1=B0 the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

 

- Later, they are called =A1=B0traffic policie= s=A1=B1: =A1=B0Examples of such network management and traffic policies that are considered by APONF are the following=A1=B1<= /span>

 

 

I think that finding a good name grouping thes= e actions is crucial:

 

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic=

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 

Are they traffic policies? Network actions? Ne= twork functionalities? Network capabilities? Traffic capabilities? Network = management actions?

 

 

What do you think?

 

Jose Saldana

 

--_000_4B29BA0800EE424E850D442A1A3D180340718BEASZXEMA510MBXchi_-- From nobody Mon Jun 9 10:28:00 2014 Return-Path: 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 717D71A029B for ; Mon, 9 Jun 2014 10:27:57 -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 JMeHbMJL2esC for ; Mon, 9 Jun 2014 10:27:55 -0700 (PDT) Received: from out21-ams.mf.surf.net (out21-ams.mf.surf.net [145.0.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAEF1A00BD for ; Mon, 9 Jun 2014 10:27:54 -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 s59HRpTT031723; Mon, 9 Jun 2014 19:27:52 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 9 Jun 2014 19:27:52 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Mon, 9 Jun 2014 19:27:51 +0200 From: To: , Thread-Topic: [Openv6] Is there a draft charter for APONF? Thread-Index: Ac+D9qNFruvdoEliTFauT0nZdN8okwAEVOrr Date: Mon, 9 Jun 2014 17:27:51 +0000 Message-ID: References: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> In-Reply-To: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA59EXMBX23adutwent_" 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: 0uMchrQko - a06586fd2ce7 - 20140609 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/MFButzU8z5hpgSrb0F3uDyzMlKc Subject: Re: [Openv6] Is there a draft charter for APONF? X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:27:57 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA59EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jose, Thanks for the comments! Yes we are planning to create a APONF BOF charter soon! Best regards, Georgios ________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens Jose Saldana [jsaldana@unizar.= es] Verzonden: maandag 9 juni 2014 17:26 Aan: Openv6@ietf.org Onderwerp: [Openv6] Is there a draft charter for APONF? Hi, I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac= /wiki. Is there a draft charter somewhere? In case not, I would suggest to write a= first version and send it to the list. It would be somewhat similar to the= BoF summary, but it would also include the goals and milestones, deliverab= les of the potential WG, interactions with other WGs, etc. Best regards, Jose Saldana --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA59EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Van: Openv6 [open= v6-bounces@ietf.org] namens Jose Saldana [jsaldana@unizar.es]
Verzonden: maandag 9 juni 2014 17:26
Aan: Openv6@ietf.org
Onderwerp: [Openv6] Is there a draft charter for APONF?

Hi,

 

I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac/wiki.

 

Is there a draft charter somewhere? In case no= t, I would suggest to write a first version and send it to the list. It wou= ld be somewhat similar to the BoF summary, but it would also include the go= als and milestones, deliverables of the potential WG, interactions with oth= er WGs, etc.

 

Best regards,

 

Jose Saldana

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA59EXMBX23adutwent_-- From nobody Mon Jun 9 10:38:12 2014 Return-Path: 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 2DF681A00BD for ; Mon, 9 Jun 2014 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.351 X-Spam-Level: *** X-Spam-Status: No, score=3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 yHvEF7iG6eCK for ; Mon, 9 Jun 2014 10:38:09 -0700 (PDT) Received: from out42-ams.mf.surf.net (out42-ams.mf.surf.net [145.0.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AE81A01AC for ; Mon, 9 Jun 2014 10:38:08 -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 s59Hc6WE013412; Mon, 9 Jun 2014 19:38:06 +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; Mon, 9 Jun 2014 19:38:06 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Mon, 9 Jun 2014 19:38:06 +0200 From: To: , Thread-Topic: =?gb2312?B?W09wZW52Nl0gtPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9m?= =?gb2312?Q?_the_functionalities?= Thread-Index: AQHPhAFf83E1b7HQf0OHVP2zV0TTNptpCewz Date: Mon, 9 Jun 2014 17:38:05 +0000 Message-ID: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es>, <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA7BEXMBX23adutwent_" 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: 0vMchC6m4 - 3bd6190bc199 - 20140609 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/t-xb6M5_LY3URNC9JUxrUXXj-to Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:38:11 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA7BEXMBX23adutwent_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSm9zZSwNCg0KDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIQ0KSXQgaXMgc29tZWhvdyBk aWZmaWN1bHQgdG8gZmluZCB0aGUgcmlnaHQgbmFtZSBmb3IgYWxsIHRoZXNlIHRlcm1zLCBzaW5j ZSB0aGVzZSBjYXBhYmlsaXRpZXMgY2FuIGJlIG5ldHdvcmsgbWFuYWdlbWVudCBjYXBhYmlsaXRp ZXMsIHRyYWZmaWMgY29uZGl0aW9uaW5nIGNhcGFiaWxpdGllcywgdHJhZmZpYyByb3V0aW9uZyBj YXBhYmlsaXRpZXMsIGV0Yy4NCg0KDQoNCkkgYW0gbm90IHN1cmUgaWYgaXQgaXMgbmVlZGVkIHRv IGZpbmQganVzdCBvbmUgbmFtZSBmb3IgdGhlc2UgdGVybXMhDQoNCg0KDQpCZXN0IHJlZ2FyZHMs DQoNCkdlb3JnaW9zDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogT3BlbnY2IFtvcGVudjYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBKb3NlIFNhbGRh bmEgW2pzYWxkYW5hQHVuaXphci5lc10NCreiy83KsbzkOiAyMDE0xOo21MI5yNUgMjM6MzENCsrV vP7IyzogT3BlbnY2QGlldGYub3JnDQrW98ziOiBbT3BlbnY2XSBBbm90aGVyIHF1ZXN0aW9uOiB0 aGUgbmFtZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQoNCkhpLA0KDQpBbm90aGVyIHF1ZXN0aW9u IGlzIGhvdyB0byBuYW1lIHRoZSBzZXQgb2YgZnVuY3Rpb25hbGl0aWVzIHlvdSBhcmUgY29uc2lk ZXJpbmcgaW4gQVBPTkY6DQoNCi0gSW4gdGhlIGZpcnN0IHBhcmFncmFwaCwgdGhleSBhcmUgY2Fs bGVkIKGwdHJhZmZpYyBjYXBhYmlsaXRpZXOhsTogobAgdGhlIGNvbW11bmljYXRpb24gbmV0d29y ayB0byBhcHBseSB0aGUgZm9sbG93aW5nIGRpZmZlcmVudCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5k L29yIHRyYWZmaWMgY2FwYWJpbGl0aWVzobENCg0KLSBMYXRlciwgdGhleSBhcmUgY2FsbGVkIKGw dHJhZmZpYyBwb2xpY2llc6GxOiChsEV4YW1wbGVzIG9mIHN1Y2ggbmV0d29yayBtYW5hZ2VtZW50 IGFuZCB0cmFmZmljIHBvbGljaWVzIHRoYXQgYXJlIGNvbnNpZGVyZWQgYnkgQVBPTkYgYXJlIHRo ZSBmb2xsb3dpbmehsQ0KDQoNCkkgdGhpbmsgdGhhdCBmaW5kaW5nIGEgZ29vZCBuYW1lIGdyb3Vw aW5nIHRoZXNlIGFjdGlvbnMgaXMgY3J1Y2lhbDoNCg0KTWFuYWdlIGR5bmFtaWNhbGx5IG5ldHdv cmsgc2VtYW50aWNzDQpPcmNoZXN0cmF0ZSBkeW5hbWljYWxseSB2aXJ0dWFsaXplZCBmdW5jdGlv bnMNClBlcm1pdCBvciBCbG9jayBvciBSZWRpcmVjdCB0aGUgdHJhZmZpYw0KTG9nIHRoZSB0cmFm ZmljDQpDb3B5IHRoZSB0cmFmZmljDQpTZXQgdGhlIHRyYWZmaWMNCk1hcmsgdGhlIHRyYWZmaWMN Cg0KQXJlIHRoZXkgdHJhZmZpYyBwb2xpY2llcz8gTmV0d29yayBhY3Rpb25zPyBOZXR3b3JrIGZ1 bmN0aW9uYWxpdGllcz8gTmV0d29yayBjYXBhYmlsaXRpZXM/IFRyYWZmaWMgY2FwYWJpbGl0aWVz PyBOZXR3b3JrIG1hbmFnZW1lbnQgYWN0aW9ucz8NCg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0K Sm9zZSBTYWxkYW5hDQoNCg== --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA7BEXMBX23adutwent_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jose,

 

Thanks for the comments!
It is somehow difficult to find the right name for all these terms, since t= hese capabilities can be network management capabilities, traffic condition= ing capabilities, traffic routiong capabilities, etc.

 

I am not sure if it is needed to find just one name for these terms= !

 

Best regards,

Georgios

 

 

=B7=A2=BC=FE=C8=CB: Openv6 [openv6-bounces= @ietf.org] =B4=FA=B1=ED Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Openv6@ietf.org
=D6=F7=CC=E2: [Openv6] Another question: the name of the functionali= ties

Hi,

 

Another question is how to name the set of fun= ctionalities you are considering in APONF:

 

- In the first paragraph, they are called =A1= =B0traffic capabilities=A1=B1: =A1=B0 the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

 

- Later, they are called =A1=B0traffic policie= s=A1=B1: =A1=B0Examples of such network management and traffic policies that are considered by APONF are the following=A1=B1<= /span>

 

 

I think that finding a good name grouping thes= e actions is crucial:

 

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic=

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 

Are they traffic policies? Network actions? Ne= twork functionalities? Network capabilities? Traffic capabilities? Network = management actions?

 

 

What do you think?

 

Jose Saldana

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BA7BEXMBX23adutwent_-- From nobody Mon Jun 9 13:36:53 2014 Return-Path: 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 11A211A0322 for ; Mon, 9 Jun 2014 13:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAWxwbspNX7o for ; Mon, 9 Jun 2014 13:36:50 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1961A0318 for ; Mon, 9 Jun 2014 13:36:50 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so5317633pbb.5 for ; Mon, 09 Jun 2014 13:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zgkVy7b5WO67W4R5z2ICsZtX03ViRQvTyck2ee66+88=; b=FvFsUkuASv2mSPoa2LfLWL1NwNXmSnT1mNMtyk3s57Se6wHeDRJzUg56M+vIaSS3uD dcnv2N6eaCbVZrJTpiotNmQWxxhfFaMDwkwpzSEfBAYwb2RW6Pjtt70LtbwNcWSJ3iGd K+KApkhCOSq0wbB6fhpVIggVHSz2KsYZbPEutjgDRDa4AlRZ6bJyYHHgWmWr4AfKPNbG a72fmunEzN27FBW5SwzXkBw8XGrSWuTCa5yxdi4OsqOhZABhFAZpTN1YYA8Ak9HOBAy8 AItnCjrIJ4aqmtZ/RbBic28WDLda25jZLyo0EZ91S0eY+bFfZL0YybKgsbCUqkpxxmGr JGtQ== X-Received: by 10.66.139.168 with SMTP id qz8mr683317pab.3.1402346209815; Mon, 09 Jun 2014 13:36:49 -0700 (PDT) Received: from [192.168.178.23] (98.197.69.111.dynamic.snap.net.nz. [111.69.197.98]) by mx.google.com with ESMTPSA id gz11sm65622420pbd.1.2014.06.09.13.36.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 13:36:49 -0700 (PDT) Message-ID: <53961AE0.8040507@gmail.com> Date: Tue, 10 Jun 2014 08:36:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: karagian@cs.utwente.nl References: , <5393787F.8040301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/fsNw_AUlXFeve3wrdNZDbhiDzvs Cc: openv6@ietf.org Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:36:52 -0000 Hi Georgios, On 08/06/2014 19:46, karagian@cs.utwente.nl wrote: > Hi Brian, > > Thanks for your comments! > > Regarding the relation to openv6, please note that APONF can be used to support an operator on deploying and configuring (and dynamically reconfiguring) different IPv4/IPv6 transition solutions depending on the applied scenarios and the expected user experience. Yes, that would be one application but I am still confused. I have seen no other traffic on the openv6 list, so what are we doing here? Why isn't this discussion on an APONF list, and where is the actual discussion of openv6? > Regarding the relation of APONF to UCAN, to my understanding, the UCAN BOF intends to expose several use cases that are focusing on Autonomic Networking (AN), i.e., self management. > APONF is focusing not focusing on solving AN issues. Please note that the dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter) are not associated with self-management. Actually, any scenario that currently relies on a policy/management function and some kind of automation is a possible use case for autonomic networking. I don't see any of the actions involved in APONF as being out of scope for AN. Application-based policy intent would be considered as an input to the AN mechanisms, and the topics that you have listed as "network management and traffic policies" are exactly the type of objectives we would consider as targets for autonomic negotiation between network elements. The "the application-based policy protocol(s), mechanisms and models" that you mention might be exactly what is needed to communicate between applications and the AN policy mechanism. If both BOFs are approved, we need to discuss in Toronto! Regards, Brian > > Best regards, > Georgios > > > ________________________________________ > Van: Brian E Carpenter [brian.e.carpenter@gmail.com] > Verzonden: zaterdag 7 juni 2014 22:39 > Aan: Karagiannis, G. (EWI) > CC: openv6@ietf.org > Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) > > Hi, > > Can you explain the specific relationship between this BOF and IPv6? > As far as I can see, it is 100% independent of the IP version (and that > is a good thing). > > By the way, the topic of autonomic configuration by negotiation > between various network elements, which could include the elements > involved in the APONF scenarios, is the subject of another BOF > proposal, which also has no specific dependency on IPv6: > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal > APONF might be an additional use case for UCAN. > > Regards > Brian Carpenter > > On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: >> Hi all, >> >> Please note that a request for a BOF associated with Openv6 has been requested for IETF 90. >> >> The name of this BOF is: >> >> APONF (Application-based Policy for Network Functions). >> >> The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies. >> >> For more details on APONF, please see: >> http://trac.tools.ietf.org/bof/trac/# >> >> Please note that in association with this BOF two Internet drafts have been (up to now) submitted . >> These drafts are: >> >> APONF problem statement: >> http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt >> >> APONF architecture: >> http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt >> >> Your comments on the APONF BOF, and on the Internet drafts listed above are very much appreciated! >> >> Best regards, >> Georgios Karagiannis >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Openv6 mailing list >> Openv6@ietf.org >> https://www.ietf.org/mailman/listinfo/openv6 From nobody Mon Jun 9 20:03:24 2014 Return-Path: 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 E12741A037C for ; Mon, 9 Jun 2014 20:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 atepVgRAuqLM for ; Mon, 9 Jun 2014 20:03:22 -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 7ABBE1A0338 for ; Mon, 9 Jun 2014 20:03:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG10869; Tue, 10 Jun 2014 03:03:19 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 04:03:19 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.19]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 11:03:13 +0800 From: "Zhouqian (Cathy)" To: Brian E Carpenter , "karagian@cs.utwente.nl" Thread-Topic: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) Thread-Index: Ac+Cen59c8170usIQealtBkWdImy7P//pgyAgAC6TACAAmmgAP//GRqQ Date: Tue, 10 Jun 2014 03:03:13 +0000 Message-ID: References: , <5393787F.8040301@gmail.com> <53961AE0.8040507@gmail.com> In-Reply-To: <53961AE0.8040507@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/TDnf1rxAfbVvcGJYAsy2y_0WsWk Cc: "openv6@ietf.org" Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 03:03:24 -0000 Hi Brian, Best Regards, Cathy > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Tuesday, June 10, 2014 4:37 AM > To: karagian@cs.utwente.nl > Cc: openv6@ietf.org > Subject: Re: [Openv6] APONF (Application-based Policy for Network Functio= ns): > new BOF for IETF 90 (requesting comments) >=20 > Hi Georgios, >=20 > On 08/06/2014 19:46, karagian@cs.utwente.nl wrote: > > Hi Brian, > > > > Thanks for your comments! > > > > Regarding the relation to openv6, please note that APONF can be used to > support an operator on deploying and configuring (and dynamically > reconfiguring) different IPv4/IPv6 transition solutions depending on the = applied > scenarios and the expected user experience. >=20 > Yes, that would be one application but I am still confused. I have seen n= o other > traffic on the openv6 list, so what are we doing here? Why isn't this dis= cussion > on an APONF list, and where is the actual discussion of openv6? Openv6 is one use case of APONF. We already had two side meetings of openv6= in both IETF 88 and IETF 89.=20 So we hope to use the expertise in this list to discuss APONF first.=20 >=20 > > Regarding the relation of APONF to UCAN, to my understanding, the UCAN > BOF intends to expose several use cases that are focusing on Autonomic > Networking (AN), i.e., self management. > > APONF is focusing not focusing on solving AN issues. Please note that t= he > dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter)= are > not associated with self-management. >=20 > Actually, any scenario that currently relies on a policy/management funct= ion > and some kind of automation is a possible use case for autonomic networki= ng. I > don't see any of the actions involved in APONF as being out of scope for = AN. > Application-based policy intent would be considered as an input to the AN > mechanisms, and the topics that you have listed as "network management an= d > traffic policies" > are exactly the type of objectives we would consider as targets for auton= omic > negotiation between network elements. >=20 > The "the application-based policy protocol(s), mechanisms and models" > that you mention might be exactly what is needed to communicate between > applications and the AN policy mechanism. APONF focuses on auto-mapping application's demand on network to the policy= that can be understood by network. The applications could be the following= ones, e.g., Traffic Engineering, Anti-DDoS, IPv6 transition, etc. These ap= plications are not in the scope of Autonomic Network. One of APONF's object= ive is to define a set of models for such applications. These models may be= used for AN or any other policy based use cases. =20 =20 > If both BOFs are approved, we need to discuss in Toronto! >=20 > Regards, > Brian >=20 > > > > Best regards, > > Georgios > > > > > > ________________________________________ > > Van: Brian E Carpenter [brian.e.carpenter@gmail.com] > > Verzonden: zaterdag 7 juni 2014 22:39 > > Aan: Karagiannis, G. (EWI) > > CC: openv6@ietf.org > > Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network > > Functions): new BOF for IETF 90 (requesting comments) > > > > Hi, > > > > Can you explain the specific relationship between this BOF and IPv6? > > As far as I can see, it is 100% independent of the IP version (and > > that is a good thing). > > > > By the way, the topic of autonomic configuration by negotiation > > between various network elements, which could include the elements > > involved in the APONF scenarios, is the subject of another BOF > > proposal, which also has no specific dependency on IPv6: > > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal > > APONF might be an additional use case for UCAN. > > > > Regards > > Brian Carpenter > > > > On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: > >> Hi all, > >> > >> Please note that a request for a BOF associated with Openv6 has been > requested for IETF 90. > >> > >> The name of this BOF is: > >> > >> APONF (Application-based Policy for Network Functions). > >> > >> The main goal of APONF is to specify the application-based policy prot= ocol(s), > mechanisms and models required by transport applications to easily, accur= ately, > and efficiently select and use the available communication network capabi= lities, > i.e., network management and/or traffic policies. > >> > >> For more details on APONF, please see: > >> http://trac.tools.ietf.org/bof/trac/# > >> > >> Please note that in association with this BOF two Internet drafts have= been > (up to now) submitted . > >> These drafts are: > >> > >> APONF problem statement: > >> http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00 > >> .txt > >> > >> APONF architecture: > >> http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt > >> > >> Your comments on the APONF BOF, and on the Internet drafts listed abov= e > are very much appreciated! > >> > >> Best regards, > >> Georgios Karagiannis > >> > >> > >> > >> --------------------------------------------------------------------- > >> --- > >> > >> _______________________________________________ > >> Openv6 mailing list > >> Openv6@ietf.org > >> https://www.ietf.org/mailman/listinfo/openv6 >=20 > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 From nobody Mon Jun 9 20:50:26 2014 Return-Path: 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 D57531A038B for ; Mon, 9 Jun 2014 20:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 lgsKXuTvMF9W for ; Mon, 9 Jun 2014 20:40:50 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249DF1A036E for ; Mon, 9 Jun 2014 20:40:50 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id ft15so355155pdb.11 for ; Mon, 09 Jun 2014 20:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:mime-version:message-id:content-type; bh=r4sdU6WPi75cvR4nVRA0W9XRg59zssJjqo7y4mojae0=; b=KeQkuuOPXPtnR/ghQfV7jG0Hm4dEscoWVMF0ISPhwDGlMdtZLOVX6nIPPSmMgoR9U4 huxvzaWjNAIZGila1P+A+ujGx8jlyAOo/SHqnD5rjfBeqDosKJ1uxBVm50mE9xhmRp6d 0F/GEb2t3K/MPBz2NPOn7JBA2z68c/AT3Du0neJkrz3eH9omwUN+SoIM2VBpk7RJyI+5 wX7yVWIeWzvdlWkk+yWdSfNCrOgCZktE6zkUPK7tQT9he4f15UKkWKz3gdq4vWTDYTXZ 643sq6PW+Y/YN0bvgF3aaxpCg04MkCY1ZBpsW7LQqpVXzNZJ/2f0qSHFpeMaTgLXl2nL ugfg== X-Received: by 10.66.150.228 with SMTP id ul4mr2763288pab.16.1402371649726; Mon, 09 Jun 2014 20:40:49 -0700 (PDT) Received: from xiechf-ctbri-PC ([125.211.216.98]) by mx.google.com with ESMTPSA id y2sm5952309pas.45.2014.06.09.20.40.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jun 2014 20:40:49 -0700 (PDT) Date: Tue, 10 Jun 2014 11:40:49 +0800 From: xiechf01 To: openv6 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <201406101140259997043@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart744732221040_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/a18K60BWmpEFaTEqmJxC5tSmn0c X-Mailman-Approved-At: Mon, 09 Jun 2014 20:50:14 -0700 Subject: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 03:40:51 -0000 This is a multi-part message in MIME format. ------=_001_NextPart744732221040_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 DQpIaSwgZm9sa3MsDQoNCkkgc3VwcG9ydCB0byB0aGVzZSAyIGRyYWZ0cywgIGZvciB0aGV5IGNh biBoZWxwIHVwcGVyLWxheWVyIGFwcGxpY2F0aW9ucyB1dGlsaXplIHRoZSBjYXJyaWVyIG5ldHdv cmsgY2FwYWJpbGl0aWVzIG1vcmUgZWZmaWNpZW50bHkgYW5kIGVhc2lseS4gT25lIHN1Z2dlc3Rp b24sIG9uZSBwYXJ0IHRvIGRlc2NyaWJlIGEgdHlwaWNhbCB3b3JrZmxvdyBjYW4gYmUgYWRkZWQg dG8gdGhlIGN1cnJlbnQgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdC4NCg0KQ2hvbmdmZW5nQGNoaW5h dGVsZWNvbQ0KDQoNCg0KeGllY2hmMDE= ------=_001_NextPart744732221040_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
 
Hi, folks,
 
I support to these 2 drafts,  for they can help upper-= layer=20 applications utilize the carrier network capabilities more efficiently and= =20 easily. One suggestion, one part to describe a typical workflow can be add= ed to=20 the current the architecture draft.
 
Chongfeng@chinatelecom
xiechf01
------=_001_NextPart744732221040_=------ From nobody Mon Jun 9 22:16:26 2014 Return-Path: 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 6B7E91A03CB for ; Mon, 9 Jun 2014 22:16:19 -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 xP2GD662bEoW for ; Mon, 9 Jun 2014 22:16:16 -0700 (PDT) Received: from out47-ams.mf.surf.net (out47-ams.mf.surf.net [145.0.1.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593991A03C7 for ; Mon, 9 Jun 2014 22:16:16 -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 s5A5G6X6017311; Tue, 10 Jun 2014 07:16:06 +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, 10 Jun 2014 07:16:07 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 07:16:06 +0200 From: To: Thread-Topic: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) Thread-Index: Ac+Cen59c8170usIQealtBkWdImy7AABVD2AABqX3REASeWnAAANftWAAAjCb+4= Date: Tue, 10 Jun 2014 05:16:05 +0000 Message-ID: References: , <5393787F.8040301@gmail.com> <53961AE0.8040507@gmail.com>, In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 0vMctg66B - 517e69ee55da - 20140610 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/eH98iiUk8z-BFYDRUelHSdtgfFE Cc: cathy.zhou@huawei.com, openv6@ietf.org Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 05:16:19 -0000 Hi Brian, In addition to what Cathy answered I would like to mention that yes, it wil= l be good to meet in Toronto and discuss the issues that you mentioned! Best regards, Georgios ________________________________________ Van: Zhouqian (Cathy) [cathy.zhou@huawei.com] Verzonden: dinsdag 10 juni 2014 5:03 Aan: Brian E Carpenter; Karagiannis, G. (EWI) CC: openv6@ietf.org Onderwerp: RE: [Openv6] APONF (Application-based Policy for Network Functio= ns): new BOF for IETF 90 (requesting comments) Hi Brian, Best Regards, Cathy > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Tuesday, June 10, 2014 4:37 AM > To: karagian@cs.utwente.nl > Cc: openv6@ietf.org > Subject: Re: [Openv6] APONF (Application-based Policy for Network Functio= ns): > new BOF for IETF 90 (requesting comments) > > Hi Georgios, > > On 08/06/2014 19:46, karagian@cs.utwente.nl wrote: > > Hi Brian, > > > > Thanks for your comments! > > > > Regarding the relation to openv6, please note that APONF can be used to > support an operator on deploying and configuring (and dynamically > reconfiguring) different IPv4/IPv6 transition solutions depending on the = applied > scenarios and the expected user experience. > > Yes, that would be one application but I am still confused. I have seen n= o other > traffic on the openv6 list, so what are we doing here? Why isn't this dis= cussion > on an APONF list, and where is the actual discussion of openv6? Openv6 is one use case of APONF. We already had two side meetings of openv6= in both IETF 88 and IETF 89. So we hope to use the expertise in this list to discuss APONF first. > > > Regarding the relation of APONF to UCAN, to my understanding, the UCAN > BOF intends to expose several use cases that are focusing on Autonomic > Networking (AN), i.e., self management. > > APONF is focusing not focusing on solving AN issues. Please note that t= he > dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter)= are > not associated with self-management. > > Actually, any scenario that currently relies on a policy/management funct= ion > and some kind of automation is a possible use case for autonomic networki= ng. I > don't see any of the actions involved in APONF as being out of scope for = AN. > Application-based policy intent would be considered as an input to the AN > mechanisms, and the topics that you have listed as "network management an= d > traffic policies" > are exactly the type of objectives we would consider as targets for auton= omic > negotiation between network elements. > > The "the application-based policy protocol(s), mechanisms and models" > that you mention might be exactly what is needed to communicate between > applications and the AN policy mechanism. APONF focuses on auto-mapping application's demand on network to the policy= that can be understood by network. The applications could be the following= ones, e.g., Traffic Engineering, Anti-DDoS, IPv6 transition, etc. These ap= plications are not in the scope of Autonomic Network. One of APONF's object= ive is to define a set of models for such applications. These models may be= used for AN or any other policy based use cases. > If both BOFs are approved, we need to discuss in Toronto! > > Regards, > Brian > > > > > Best regards, > > Georgios > > > > > > ________________________________________ > > Van: Brian E Carpenter [brian.e.carpenter@gmail.com] > > Verzonden: zaterdag 7 juni 2014 22:39 > > Aan: Karagiannis, G. (EWI) > > CC: openv6@ietf.org > > Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network > > Functions): new BOF for IETF 90 (requesting comments) > > > > Hi, > > > > Can you explain the specific relationship between this BOF and IPv6? > > As far as I can see, it is 100% independent of the IP version (and > > that is a good thing). > > > > By the way, the topic of autonomic configuration by negotiation > > between various network elements, which could include the elements > > involved in the APONF scenarios, is the subject of another BOF > > proposal, which also has no specific dependency on IPv6: > > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal > > APONF might be an additional use case for UCAN. > > > > Regards > > Brian Carpenter > > > > On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: > >> Hi all, > >> > >> Please note that a request for a BOF associated with Openv6 has been > requested for IETF 90. > >> > >> The name of this BOF is: > >> > >> APONF (Application-based Policy for Network Functions). > >> > >> The main goal of APONF is to specify the application-based policy prot= ocol(s), > mechanisms and models required by transport applications to easily, accur= ately, > and efficiently select and use the available communication network capabi= lities, > i.e., network management and/or traffic policies. > >> > >> For more details on APONF, please see: > >> http://trac.tools.ietf.org/bof/trac/# > >> > >> Please note that in association with this BOF two Internet drafts have= been > (up to now) submitted . > >> These drafts are: > >> > >> APONF problem statement: > >> http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00 > >> .txt > >> > >> APONF architecture: > >> http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt > >> > >> Your comments on the APONF BOF, and on the Internet drafts listed abov= e > are very much appreciated! > >> > >> Best regards, > >> Georgios Karagiannis > >> > >> > >> > >> --------------------------------------------------------------------- > >> --- > >> > >> _______________________________________________ > >> Openv6 mailing list > >> Openv6@ietf.org > >> https://www.ietf.org/mailman/listinfo/openv6 > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6= From nobody Mon Jun 9 22:59:17 2014 Return-Path: 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 700C51A03E4 for ; Mon, 9 Jun 2014 22:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no 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 yebw5TX9g9mU for ; Mon, 9 Jun 2014 22:53:03 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8456C1A03DB for ; Mon, 9 Jun 2014 22:53:03 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id rp16so437894pbb.37 for ; Mon, 09 Jun 2014 22:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:mime-version:message-id:content-type; bh=xJuSbfhWcGDp3w/bWDJn5ejxOcAC66JBgPljJ9b3rwM=; b=fYQddDh+DjD3NwFWAeoVpfwDWuEs6HX64ODdAGkJx+/EKL2tndKETXiyIb7rFRpbtR eqQjHSD1StboqOtlM7CZod9/Rk5m2smHznKwcipOEt+OD5/VLRd/uPCh0SPqG89M2AUn lM96nxyz1+SCY6fxVJxGUXaNeWQrK4AW4xMS9AUbAIIxres/e7mnYTavAz816eHr29TZ WxZupesaurKnU38N93lMg0oSJlUbNLVGxAw24vwn4u0HA8e1cnDRIR6bG1BbxkZgc3Oh 7+gmK1wGDM6rOJm0kRNU+3xRUvQvcfluuMZG90bzXXI2tJdYp1Dd14OaQ5rsScSCOMKh 5kLw== X-Received: by 10.66.250.194 with SMTP id ze2mr3310796pac.28.1402379583201; Mon, 09 Jun 2014 22:53:03 -0700 (PDT) Received: from xiechf-ctbri-PC ([125.211.216.98]) by mx.google.com with ESMTPSA id qq5sm67298503pbb.24.2014.06.09.22.53.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jun 2014 22:53:02 -0700 (PDT) Date: Tue, 10 Jun 2014 13:53:03 +0800 From: xiechf01 To: openv6 X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <2014061013522916762911@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart856287738614_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/m49q1oXJUeAp-Wo3RTtdeMwu_L8 X-Mailman-Approved-At: Mon, 09 Jun 2014 22:59:16 -0700 Subject: [Openv6] openv6 X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 05:53:04 -0000 This is a multi-part message in MIME format. ------=_001_NextPart856287738614_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGUgMiBkb2N1bWVudHMgLCBhbmQgSSBob3BlIHRoZSB1c2Ug Y2FzZXMgbmVlZCB0byBiZSBtb3JlIGRldGFpbGVkLiBGb3IgZXhhbXBsZSwgd2UgaGF2ZSBvbmUg Y29uY3JldGUgZXhhbXBsZSBmcm9tIG91ciBuZWVkcywgY29uc2lkZXJpbmcgbXVsdGlwbGUgdHlw ZSBvZiB0cmFuc2l0aW9uIHNvbHV0aW9ucyBhbmQgc2NlbmFyaW9zIGluIHRoZSBtYXJrZXQsIG9w ZW52NiBjYW4gaGVscCBJU1AgdG8gZHluYW1pY2FsbHkgcHJvdmlkZSB0cmFuc2l0aW9uIHNlcnZp Y2VzIHRvIGJyb2FkYmFuZCB1c2VycyBiYXNlZCBvbiB0aGUgdHlwZXMgb2YgQ1BFcywgSW4gdGhp cyBjYXNlLCB0aGUgZmxvdy10YWJsZSBhbmQgYWRkcmVzcy9wb3J0LXNldCBjYW4gYmUgZG93bmxv YWRlZCB0byB0aGUgZWRnZSBlcXVpcG1lbnQgb2YgdGhlIG1ldHJvIG5ldHdvcmsgZm9yIHJhcGlk IHRyYW5zaXRpb24gc2VydmljaW5nIHByb3Zpc2lvbmluZy4NCg0KDQpBUE9ORiBwcm9ibGVtIHN0 YXRlbWVudDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1rYXJhZ2lhbm5pcy1hcG9u Zi1wcm9ibGVtLXN0YXRlbWVudC0wMC50eHQNCiANCkFQT05GIGFyY2hpdGVjdHVyZToNCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aG91LWFwb25mLWFyY2hpdGVjdHVyZS0wMC50eHQN Cg0KDQoNCkNob25nZmVuZyBYaWUNCg0KDQoNCg0KeGllY2hmMDE= ------=_001_NextPart856287738614_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

 

 

I have reviewed the 2 documents , and I hope the use cases need to be= more=20 detailed. For example, we have one concrete example from our needs, consid= ering=20 multiple type of transition solutions and scenarios in the market, openv6 = can=20 help ISP to dynamically provide transition services to broadband users bas= ed on=20 the types of CPEs, In this case, the flow-table and address/port-set can b= e=20 downloaded to the edge equipment of the metro network for rapid transition= =20 servicing provisioning.
 
 

APONF problem statement:

http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statemen= t-00.txt

 

APONF architecture:

htt= p://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt

 

 

 
Chongfeng Xie
 
xiechf01
------=_001_NextPart856287738614_=------ From nobody Mon Jun 9 23:14:27 2014 Return-Path: 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 D1FA61A03DB for ; Mon, 9 Jun 2014 23:13:54 -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 5HPdri4BgrGN for ; Mon, 9 Jun 2014 23:13:22 -0700 (PDT) Received: from out66-ams.mf.surf.net (out66-ams.mf.surf.net [145.0.1.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE431A03DC for ; Mon, 9 Jun 2014 23:13:21 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5A6N00q010907; Tue, 10 Jun 2014 08:23:00 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 08:13:19 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 08:13:18 +0200 From: To: , Thread-Topic: [Openv6] openv6 Thread-Index: AQHPhHEfEQUMIEmlK0WkxLCnrpUZJptp3Jke Date: Tue, 10 Jun 2014 06:13:18 +0000 Message-ID: References: <2014061013522916762911@gmail.com> In-Reply-To: <2014061013522916762911@gmail.com> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BC9FEXMBX23adutwent_" 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: 0bMcun0fh - 862c8c6b33b8 - 20140610 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/ptqFFXskskrh16YlfBWFq7HBAOk Subject: Re: [Openv6] openv6 X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:13:55 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BC9FEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chongfeng Xie, Thanks for your comments! I agree with your comment that we need to describe the use cases in more de= tail. It will be great if you can write an Internet draft that describes th= e use case that you are interested in! Best regards, Georgios ________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens xiechf01 [xiechf01@gmail.com] Verzonden: dinsdag 10 juni 2014 7:53 Aan: openv6 Onderwerp: [Openv6] openv6 I have reviewed the 2 documents , and I hope the use cases need to be more = detailed. For example, we have one concrete example from our needs, conside= ring multiple type of transition solutions and scenarios in the market, ope= nv6 can help ISP to dynamically provide transition services to broadband us= ers based on the types of CPEs, In this case, the flow-table and address/po= rt-set can be downloaded to the edge equipment of the metro network for rap= id transition servicing provisioning. APONF problem statement: http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00.txt APONF architecture: http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt Chongfeng Xie ________________________________ xiechf01 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BC9FEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Chongfeng Xie,

 

Thanks for your comments!

I agree with your comment that we need to describe the use cases in more= detail. It will be great if you can write an Internet draft that describes= the use case that you are interested in!

 

Best regards,

Georgios

 

Van: Openv6 [openv6-bounces@ietf.org] name= ns xiechf01 [xiechf01@gmail.com]
Verzonden: dinsdag 10 juni 2014 7:53
Aan: openv6
Onderwerp: [Openv6] openv6

 

 

I have reviewed the 2 documents , and I hope the use cases need to be = more detailed. For example, we have one concrete example from our needs, co= nsidering multiple type of transition solutions and scenarios in the market= , openv6 can help ISP to dynamically provide transition services to broadband users based on the types of CPEs,= In this case, the flow-table and address/port-set can be downloaded to the= edge equipment of the metro network for rapid transition servicing provisi= oning.
 
 
 
Chongfeng Xie
 
xiechf01
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BC9FEXMBX23adutwent_-- From nobody Mon Jun 9 23:35:51 2014 Return-Path: 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 2BD461A03DC for ; Mon, 9 Jun 2014 23:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 g7GHMWrqAJEc for ; Mon, 9 Jun 2014 23:35:45 -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 4CAC51A0402 for ; Mon, 9 Jun 2014 23:35:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIG30022; Tue, 10 Jun 2014 06:35:42 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 07:35:39 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.3]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 14:35:28 +0800 From: "Liushucheng (Will)" To: Felix , Jose Saldana , "Openv6@ietf.org" Thread-Topic: =?gb2312?B?W09wZW52Nl0gtPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9m?= =?gb2312?Q?_the_functionalities?= Thread-Index: AQHPhARDmEVvI/s5XUay20kkZ4V/+5tp49jA Date: Tue, 10 Jun 2014 06:35:27 +0000 Message-ID: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> 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_C9B5F12337F6F841B35C404CF0554ACB5FEF75CCSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/5Co0PIWPdl4J3GZ8vcLsa68Z790 Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:35:48 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FEF75CCSZXEMA509MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzENCklNSE8sIHRoaXMgb25lIGlzIGFwcHJvcHJpYXRlLg0KDQpSZWdhcmRzLA0KV2lsbCAoU2h1 Y2hlbmcgTElVKQ0KDQpGcm9tOiBPcGVudjYgW21haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEZlbGl4DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDEyOjM5 IEFNDQpUbzogSm9zZSBTYWxkYW5hOyBPcGVudjZAaWV0Zi5vcmcNClN1YmplY3Q6IFtPcGVudjZd ILTwuLQ6IEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9mIHRoZSBmdW5jdGlvbmFsaXRpZXMN Cg0KDQpIaSBhbGwsDQoNCg0KDQpJIHByZWZlciAiTmV0d29yayBjYXBhYmlsaXRpZXMiIGZvciBn cm91cGluZyB0aGVzZSBhY3Rpb25zLg0KDQoNCg0KQmVzdCByZWdhcmRzIQ0KDQpGZWxpeA0KDQoN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IE9wZW52NiBb b3BlbnY2LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9zZSBTYWxkYW5hIFtqc2FsZGFuYUB1bml6 YXIuZXNdDQq3osvNyrG85DogMjAxNMTqNtTCOcjVIDIzOjMxDQrK1bz+yMs6IE9wZW52NkBpZXRm Lm9yZzxtYWlsdG86T3BlbnY2QGlldGYub3JnPg0K1vfM4jogW09wZW52Nl0gQW5vdGhlciBxdWVz dGlvbjogdGhlIG5hbWUgb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KSGksDQoNCkFub3RoZXIgcXVl c3Rpb24gaXMgaG93IHRvIG5hbWUgdGhlIHNldCBvZiBmdW5jdGlvbmFsaXRpZXMgeW91IGFyZSBj b25zaWRlcmluZyBpbiBBUE9ORjoNCg0KLSBJbiB0aGUgZmlyc3QgcGFyYWdyYXBoLCB0aGV5IGFy ZSBjYWxsZWQgobB0cmFmZmljIGNhcGFiaWxpdGllc6GxOiChsCB0aGUgY29tbXVuaWNhdGlvbiBu ZXR3b3JrIHRvIGFwcGx5IHRoZSBmb2xsb3dpbmcgZGlmZmVyZW50IG5ldHdvcmsgbWFuYWdlbWVu dCBhbmQvb3IgdHJhZmZpYyBjYXBhYmlsaXRpZXOhsQ0KDQotIExhdGVyLCB0aGV5IGFyZSBjYWxs ZWQgobB0cmFmZmljIHBvbGljaWVzobE6IKGwRXhhbXBsZXMgb2Ygc3VjaCBuZXR3b3JrIG1hbmFn ZW1lbnQgYW5kIHRyYWZmaWMgcG9saWNpZXMgdGhhdCBhcmUgY29uc2lkZXJlZCBieSBBUE9ORiBh cmUgdGhlIGZvbGxvd2luZ6GxDQoNCg0KSSB0aGluayB0aGF0IGZpbmRpbmcgYSBnb29kIG5hbWUg Z3JvdXBpbmcgdGhlc2UgYWN0aW9ucyBpcyBjcnVjaWFsOg0KDQpNYW5hZ2UgZHluYW1pY2FsbHkg bmV0d29yayBzZW1hbnRpY3MNCk9yY2hlc3RyYXRlIGR5bmFtaWNhbGx5IHZpcnR1YWxpemVkIGZ1 bmN0aW9ucw0KUGVybWl0IG9yIEJsb2NrIG9yIFJlZGlyZWN0IHRoZSB0cmFmZmljDQpMb2cgdGhl IHRyYWZmaWMNCkNvcHkgdGhlIHRyYWZmaWMNClNldCB0aGUgdHJhZmZpYw0KTWFyayB0aGUgdHJh ZmZpYw0KDQpBcmUgdGhleSB0cmFmZmljIHBvbGljaWVzPyBOZXR3b3JrIGFjdGlvbnM/IE5ldHdv cmsgZnVuY3Rpb25hbGl0aWVzPyBOZXR3b3JrIGNhcGFiaWxpdGllcz8gVHJhZmZpYyBjYXBhYmls aXRpZXM/IE5ldHdvcmsgbWFuYWdlbWVudCBhY3Rpb25zPw0KDQoNCldoYXQgZG8geW91IHRoaW5r Pw0KDQpKb3NlIFNhbGRhbmENCg0K --_000_C9B5F12337F6F841B35C404CF0554ACB5FEF75CCSZXEMA509MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1

IMHO, this one is appr= opriate.

 

Regards,

Will (Shucheng LIU)

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of Felix
Sent: Tuesday, June 10, 2014 12:39 AM
To: Jose Saldana; Openv6@ietf.org
Subject: [Openv6] =B4=F0=B8=B4: Another ques= tion: the name of the functionalities

 

Hi all,

 

I prefer "Network capabili= ties" for grouping these actions.

 

Best regards!

Felix

 

 

=B7=A2= =BC=FE=C8=CB:<= span lang=3D"ES" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif";color:black"> Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29<= span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:black">=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Openv6@ietf.org
=D6=F7=CC=E2: [Openv6] Another question: the name of the functionalities

Hi,

 <= /o:p>

Another question is how to name the set of f= unctionalities you are considering in APONF:

 <= /o:p>

- In the first paragraph, they are called = =A1=B0traffic capabilities=A1=B1: =A1=B0&nb= sp;the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

 <= /o:p>

- Later, they are called =A1=B0traffic polic= ies=A1=B1: =A1=B0Examples of such network management and traffic policies that are considered by APONF are the following=A1=B1

 <= /o:p>

 <= /o:p>

I think that finding a good name grouping th= ese actions is crucial:=

 <= /o:p>

Manage dynamically network semantics<= span lang=3D"ES" style=3D"color:black">

Orchestrate dynamically virtualized function= s

Permit or Block or Redirect the traffic

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 <= /o:p>

Are they traffic policies? Network actions? = Network functionalities? Network capabilities? Traffic capabilities? Networ= k management actions?

 <= /o:p>

 <= /o:p>

What do you think?

 <= /o:p>

Jose Saldana

 <= /o:p>

--_000_C9B5F12337F6F841B35C404CF0554ACB5FEF75CCSZXEMA509MBSchi_-- From nobody Mon Jun 9 23:43:51 2014 Return-Path: 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 60EBB1A02DB for ; Mon, 9 Jun 2014 23:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.4 X-Spam-Level: *** X-Spam-Status: No, score=3.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651] 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 L3PdyGujGtJZ for ; Mon, 9 Jun 2014 23:43:46 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC101A03DC for ; Mon, 9 Jun 2014 23:43:46 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id DD46456608D9 for ; Tue, 10 Jun 2014 06:43:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o78CJ4KD3S2x for ; Tue, 10 Jun 2014 08:43:12 +0200 (CEST) Received: from kopoli (g225184206.adsl.alicedsl.de [92.225.184.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id C497D56608D8 for ; Tue, 10 Jun 2014 08:43:11 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> In-Reply-To: Date: Tue, 10 Jun 2014 08:43:09 +0200 Message-ID: <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CF8488.01C06B40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9kWylUUL1vYNzUR5ybFhXA4fXwwGLun+2AUkLSOCbdyVA4A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/gqKomuq42AD8bbpMfswOMcHgUww Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:43:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01CF8488.01C06B40 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, GiLan is another important application of network function virtualization. You may consider to add this into your PS draft. Best, Hosnieh =20 From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Tuesday, June 10, 2014 8:35 AM To: Felix; Jose Saldana; Openv6@ietf.org Subject: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of the functionalities =20 +1 IMHO, this one is appropriate. =20 Regards, Will (Shucheng LIU) =20 From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Felix Sent: Tuesday, June 10, 2014 12:39 AM To: Jose Saldana; Openv6@ietf.org Subject: [Openv6] =B4=F0=B8=B4: Another question: the name of the = functionalities =20 Hi all, =20 I prefer "Network capabilities" for grouping these actions. =20 Best regards! Felix =20 =20 _____ =20 =B7=A2=BC=FE=C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose = Saldana [jsaldana@unizar. es] =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29=C8=D5 23:31 =CA=D5=BC=FE=C8=CB: Openv6@ietf.org =D6=F7=CC=E2: [Openv6] Another question: the name of the functionalities Hi, =20 Another question is how to name the set of functionalities you are considering in APONF: =20 - In the first paragraph, they are called =A1=B0traffic = capabilities=A1=B1: =A1=B0 the communication network to apply the following different network = management and/or traffic capabilities=A1=B1 =20 - Later, they are called =A1=B0traffic policies=A1=B1: =A1=B0Examples of = such network management and traffic policies that are considered by APONF are the following=A1=B1 =20 =20 I think that finding a good name grouping these actions is crucial: =20 Manage dynamically network semantics Orchestrate dynamically virtualized functions=20 Permit or Block or Redirect the traffic Log the traffic=20 Copy the traffic=20 Set the traffic=20 Mark the traffic =20 Are they traffic policies? Network actions? Network functionalities? = Network capabilities? Traffic capabilities? Network management actions? =20 =20 What do you think? =20 Jose Saldana =20 ------=_NextPart_000_0031_01CF8488.01C06B40 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

   GiLan is = another important application of network function virtualization. You = may consider to add this into your PS draft.

Best,

Hosnieh

 

From:= = Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng = (Will)
Sent: Tuesday, June 10, 2014 8:35 AM
To: = Felix; Jose Saldana; Openv6@ietf.org
Subject: Re: [Openv6] = =B4=F0=B8=B4: Another = question: the name of the = functionalities

 

+1

IMHO, this one is = appropriate.

 

Regards,

Will (Shucheng = LIU)

 

From:= = Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Felix
Sent: Tuesday, June 10, 2014 = 12:39 AM
To: Jose Saldana; Openv6@ietf.org
Subject: = [Openv6] =B4=F0=B8=B4: Another = question: the name of the = functionalities

 

= Hi all,

=  

= I prefer "Network capabilities" for grouping these = actions.

=  

= Best regards!

= Felix

=  

=  

=B7=A2=BC=FE=C8= =CB= := Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED= Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA= =B1=BC=E4= := 2014=C4=EA= 6=D4=C2= 9=C8=D5= 23:31
=CA=D5=BC=FE=C8= =CB= := Openv6@ietf.org
=D6=F7=CC=E2= := [Openv6] Another question: the name of the functionalities

Hi,

 

Another = question is how to name the set of functionalities you are considering = in APONF:

 

- In the first = paragraph, they are called =A1=B0traffic capabilities=A1=B1: = =A1=B0 the = communication network to apply the following different network = management and/or traffic capabilities=A1=B1

 

- Later, they = are called =A1=B0traffic policies=A1=B1: =A1=B0Examples of such = network management and traffic policies that are considered by APONF are = the following=A1=B1

 

 

I think that = finding a good name grouping these actions is crucial:

 

Manage = dynamically network semantics

Orchestrate = dynamically virtualized functions

Permit or Block = or Redirect the traffic

Log the traffic =

Copy the = traffic

Set the traffic =

Mark the = traffic

 

Are they = traffic policies? Network actions? Network functionalities? Network = capabilities? Traffic capabilities? Network management = actions?

 

 

What do you = think?

 

Jose = Saldana

 

------=_NextPart_000_0031_01CF8488.01C06B40-- From nobody Mon Jun 9 23:47:33 2014 Return-Path: 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 8D53E1A0422 for ; Mon, 9 Jun 2014 23:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.351 X-Spam-Level: *** X-Spam-Status: No, score=3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 cjRxtHKikPps for ; Mon, 9 Jun 2014 23:47:30 -0700 (PDT) Received: from out21-ams.mf.surf.net (out21-ams.mf.surf.net [145.0.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1441B1A041B for ; Mon, 9 Jun 2014 23:47:29 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5A6lQVq013899; Tue, 10 Jun 2014 08:47:26 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 08:47:28 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 08:47:26 +0200 From: To: , Thread-Topic: =?gb2312?B?W09wZW52Nl0gtPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9m?= =?gb2312?Q?_the_functionalities?= Thread-Index: AQHPhAFf83E1b7HQf0OHVP2zV0TTNptpwsuAgAACJoCAACJa3A== Date: Tue, 10 Jun 2014 06:47:25 +0000 Message-ID: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> , <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> In-Reply-To: <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BD1FEXMBX23adutwent_" 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.48; 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: 0uMcuLqF1 - cd984c03546d - 20140610 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/mOLsGBJ_YPiI_AopHE-rSemDJJU Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:47:32 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BD1FEXMBX23adutwent_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSG9zbmllaCwNCg0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ghDQoNCkNhbiB5b3UgcGxlYXNl IHByb3ZpZGUgdGV4dD8NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KR2Vvcmdpb3MNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpWYW46IE9wZW52NiBbb3BlbnY2LWJvdW5j ZXNAaWV0Zi5vcmddIG5hbWVucyBIb3NuaWVoIFJhZmllZSBbaWV0ZkByb3phbmFrLmNvbV0NClZl cnpvbmRlbjogZGluc2RhZyAxMCBqdW5pIDIwMTQgODo0Mw0KQWFuOiBPcGVudjZAaWV0Zi5vcmcN Ck9uZGVyd2VycDogUmU6IFtPcGVudjZdILTwuLQ6IEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXMNCg0KSGkgYWxsLA0KICAgR2lMYW4gaXMgYW5vdGhlciBp bXBvcnRhbnQgYXBwbGljYXRpb24gb2YgbmV0d29yayBmdW5jdGlvbiB2aXJ0dWFsaXphdGlvbi4g WW91IG1heSBjb25zaWRlciB0byBhZGQgdGhpcyBpbnRvIHlvdXIgUFMgZHJhZnQuDQpCZXN0LA0K SG9zbmllaA0KDQpGcm9tOiBPcGVudjYgW21haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIExpdXNodWNoZW5nIChXaWxsKQ0KU2VudDogVHVlc2RheSwgSnVuZSAxMCwg MjAxNCA4OjM1IEFNDQpUbzogRmVsaXg7IEpvc2UgU2FsZGFuYTsgT3BlbnY2QGlldGYub3JnDQpT dWJqZWN0OiBSZTogW09wZW52Nl0gtPC4tDogQW5vdGhlciBxdWVzdGlvbjogdGhlIG5hbWUgb2Yg dGhlIGZ1bmN0aW9uYWxpdGllcw0KDQorMQ0KSU1ITywgdGhpcyBvbmUgaXMgYXBwcm9wcmlhdGUu DQoNClJlZ2FyZHMsDQpXaWxsIChTaHVjaGVuZyBMSVUpDQoNCkZyb206IE9wZW52NiBbbWFpbHRv Om9wZW52Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRmVsaXgNClNlbnQ6IFR1ZXNk YXksIEp1bmUgMTAsIDIwMTQgMTI6MzkgQU0NClRvOiBKb3NlIFNhbGRhbmE7IE9wZW52NkBpZXRm Lm9yZzxtYWlsdG86T3BlbnY2QGlldGYub3JnPg0KU3ViamVjdDogW09wZW52Nl0gtPC4tDogQW5v dGhlciBxdWVzdGlvbjogdGhlIG5hbWUgb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KDQoNCkhpIGFs bCwNCg0KDQoNCkkgcHJlZmVyICJOZXR3b3JrIGNhcGFiaWxpdGllcyIgZm9yIGdyb3VwaW5nIHRo ZXNlIGFjdGlvbnMuDQoNCg0KDQpCZXN0IHJlZ2FyZHMhDQoNCkZlbGl4DQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogT3BlbnY2IFtvcGVudjYtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBKb3NlIFNhbGRhbmEgW2pzYWxkYW5hQHVuaXphci5lc10NCrei y83KsbzkOiAyMDE0xOo21MI5yNUgMjM6MzENCsrVvP7IyzogT3BlbnY2QGlldGYub3JnPG1haWx0 bzpPcGVudjZAaWV0Zi5vcmc+DQrW98ziOiBbT3BlbnY2XSBBbm90aGVyIHF1ZXN0aW9uOiB0aGUg bmFtZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQpIaSwNCg0KQW5vdGhlciBxdWVzdGlvbiBpcyBo b3cgdG8gbmFtZSB0aGUgc2V0IG9mIGZ1bmN0aW9uYWxpdGllcyB5b3UgYXJlIGNvbnNpZGVyaW5n IGluIEFQT05GOg0KDQotIEluIHRoZSBmaXJzdCBwYXJhZ3JhcGgsIHRoZXkgYXJlIGNhbGxlZCCh sHRyYWZmaWMgY2FwYWJpbGl0aWVzobE6IKGwIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdvcmsgdG8g YXBwbHkgdGhlIGZvbGxvd2luZyBkaWZmZXJlbnQgbmV0d29yayBtYW5hZ2VtZW50IGFuZC9vciB0 cmFmZmljIGNhcGFiaWxpdGllc6GxDQoNCi0gTGF0ZXIsIHRoZXkgYXJlIGNhbGxlZCChsHRyYWZm aWMgcG9saWNpZXOhsTogobBFeGFtcGxlcyBvZiBzdWNoIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQg dHJhZmZpYyBwb2xpY2llcyB0aGF0IGFyZSBjb25zaWRlcmVkIGJ5IEFQT05GIGFyZSB0aGUgZm9s bG93aW5nobENCg0KDQpJIHRoaW5rIHRoYXQgZmluZGluZyBhIGdvb2QgbmFtZSBncm91cGluZyB0 aGVzZSBhY3Rpb25zIGlzIGNydWNpYWw6DQoNCk1hbmFnZSBkeW5hbWljYWxseSBuZXR3b3JrIHNl bWFudGljcw0KT3JjaGVzdHJhdGUgZHluYW1pY2FsbHkgdmlydHVhbGl6ZWQgZnVuY3Rpb25zDQpQ ZXJtaXQgb3IgQmxvY2sgb3IgUmVkaXJlY3QgdGhlIHRyYWZmaWMNCkxvZyB0aGUgdHJhZmZpYw0K Q29weSB0aGUgdHJhZmZpYw0KU2V0IHRoZSB0cmFmZmljDQpNYXJrIHRoZSB0cmFmZmljDQoNCkFy ZSB0aGV5IHRyYWZmaWMgcG9saWNpZXM/IE5ldHdvcmsgYWN0aW9ucz8gTmV0d29yayBmdW5jdGlv bmFsaXRpZXM/IE5ldHdvcmsgY2FwYWJpbGl0aWVzPyBUcmFmZmljIGNhcGFiaWxpdGllcz8gTmV0 d29yayBtYW5hZ2VtZW50IGFjdGlvbnM/DQoNCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCkpvc2Ug U2FsZGFuYQ0KDQo= --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BD1FEXMBX23adutwent_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hosnieh,

 

Thank you very much!

Can you please provide text?

 

Best regards,

Georgios

 

Van: Openv6 [openv6-bounces@ietf.org] name= ns Hosnieh Rafiee [ietf@rozanak.com]
Verzonden: dinsdag 10 juni 2014 8:43
Aan: Openv6@ietf.org
Onderwerp: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of = the functionalities

Hi all,

   GiLan is= another important application of network function virtualization. You may = consider to add this into your PS draft.

Best,

Hosnieh

 

From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng (Will)
Sent: Tuesday, June 10, 2014 8:35 AM
To: Felix; Jose Saldana; Openv6@ietf.org
Subject: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of th= e functionalities

 

+1

IMHO, this one is app= ropriate.

 

Regards,

Will (Shucheng LIU)

 

From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Felix
Sent: Tuesday, June 10, 2014 12:39 AM
To: Jose Saldana; Openv6@ietf.org
Subject: [Openv6] =B4=F0=B8=B4: Another question: the name of the fu= nctionalities

 

Hi all,

 

I prefer "Network capabilities" for gr= ouping these actions.

 

Best regards!

Felix

 

 

=B7=A2=BC=FE= =C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4:= 2014=C4=EA6=D4=C29=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Openv6@ietf.org =D6=F7=CC=E2:<= span style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: black; FONT-SIZE: = 10pt" lang=3D"ES"> [Openv6] Another question: the name of the functionalities

Hi,

&nbs= p;

Another question is how to name the set of functionalities yo= u are considering in APONF:=

&nbs= p;

- In the first paragraph, they are called =A1=B0traffic capab= ilities=A1=B1: =A1=B0 the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

&nbs= p;

- Later, they are called =A1=B0traffic policies=A1=B1: =A1=B0= E= xamples of such network management and traffic policies that are considered by APONF are the following=A1=B1

&nbs= p;

&nbs= p;

I think that finding a good name grouping these actions is cr= ucial:

&nbs= p;

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

&nbs= p;

Are they traffic policies? Network actions? Network functiona= lities? Network capabilities? Traffic capabilities? Network management acti= ons?

&nbs= p;

&nbs= p;

What do you think?

&nbs= p;

Jose Saldana<= /span>

&nbs= p;

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BD1FEXMBX23adutwent_-- From nobody Mon Jun 9 23:48:44 2014 Return-Path: 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 3C5251A0421 for ; Mon, 9 Jun 2014 23:48:43 -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 uP02cVNZcRvD for ; Mon, 9 Jun 2014 23:48:41 -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 96DC41A0407 for ; Mon, 9 Jun 2014 23:48:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIG31319; Tue, 10 Jun 2014 06:48:39 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 07:48:38 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.19]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 14:48:35 +0800 From: "Zhouqian (Cathy)" To: xiechf01 , openv6 Thread-Topic: [Openv6] About APONF drafts Thread-Index: AQHPhF8heuFD6DrOmUOV9ImjydnF6Ztp5rAA Date: Tue, 10 Jun 2014 06:48:34 +0000 Message-ID: References: <201406101140259997043@gmail.com> In-Reply-To: <201406101140259997043@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF3FD9D989SZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/Beo14SsgvYID_1WJUFaceNAcfjM Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:48:43 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF3FD9D989SZXEMA512MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chongfeng, Thanks for your suggestion. Do you mean the workflow of an example use case= ? Best Regards, Cathy From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of xiechf01 Sent: Tuesday, June 10, 2014 11:41 AM To: openv6 Subject: [Openv6] About APONF drafts Hi, folks, I support to these 2 drafts, for they can help upper-layer applications ut= ilize the carrier network capabilities more efficiently and easily. One sug= gestion, one part to describe a typical workflow can be added to the curren= t the architecture draft. Chongfeng@chinatelecom ________________________________ xiechf01 --_000_A6A061BEE5DDC94A9692D9D81AF776DF3FD9D989SZXEMA512MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chongfe= ng,

Thanks for= your suggestion. Do you mean the workflow of an example use case?

 = ;

Best Regards,

Cathy

 = ;

From: Openv6 [ma= ilto:openv6-bounces@ietf.org] On Behalf Of xiechf01
Sent: Tuesday, June 10, 2014 11:41 AM
To: openv6
Subject: [Openv6] About APONF drafts

 

 

Hi, folks,

 

I support to t= hese 2 drafts,  for they can help upper-layer applications utiliz= e the carrier network capabilities more efficiently and easily. One suggestion, one part to describe a typica= l workflow can be added to the current the architecture draft.

 

xiechf01=

--_000_A6A061BEE5DDC94A9692D9D81AF776DF3FD9D989SZXEMA512MBXchi_-- From nobody Mon Jun 9 23:51:11 2014 Return-Path: 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 E8F851A0424 for ; Mon, 9 Jun 2014 23:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 GH1iA4M2BHw4 for ; Mon, 9 Jun 2014 23:51:07 -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 4B2CC1A0422 for ; Mon, 9 Jun 2014 23:51:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFG25726; Tue, 10 Jun 2014 06:51:05 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 07:51:03 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.3]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 14:51:00 +0800 From: "Liushucheng (Will)" To: Hosnieh Rafiee , "Openv6@ietf.org" Thread-Topic: =?gb2312?B?W09wZW52Nl0gtPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9m?= =?gb2312?Q?_the_functionalities?= Thread-Index: AQHPhARDmEVvI/s5XUay20kkZ4V/+5tp49jA//98foCAAIaogA== Date: Tue, 10 Jun 2014 06:50:59 +0000 Message-ID: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> In-Reply-To: <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> 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_C9B5F12337F6F841B35C404CF0554ACB5FEF762ESZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/zqVuQsZkez0mn2GXJQD4ucOJ33Y Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 06:51:09 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FEF762ESZXEMA509MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSG9zbmllaCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHN1Z2dlc3Rpb24uIFlvdaGvcmUgcmln aHQuIEdpTEFOIGlzIGEgZ29vZCBjYXNlIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIGFkZGluZyB0 aGlzLg0KDQpSZWdhcmRzLA0KV2lsbCAoU2h1Y2hlbmcgTElVKQ0KDQpGcm9tOiBPcGVudjYgW21h aWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhvc25pZWggUmFmaWVl DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDI6NDMgUE0NClRvOiBPcGVudjZAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbT3BlbnY2XSC08Li0OiBBbm90aGVyIHF1ZXN0aW9uOiB0aGUgbmFt ZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQoNCkhpIGFsbCwNCiAgIEdpTGFuIGlzIGFub3RoZXIg aW1wb3J0YW50IGFwcGxpY2F0aW9uIG9mIG5ldHdvcmsgZnVuY3Rpb24gdmlydHVhbGl6YXRpb24u IFlvdSBtYXkgY29uc2lkZXIgdG8gYWRkIHRoaXMgaW50byB5b3VyIFBTIGRyYWZ0Lg0KQmVzdCwN Ckhvc25pZWgNCg0KRnJvbTogT3BlbnY2IFttYWlsdG86b3BlbnY2LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBMaXVzaHVjaGVuZyAoV2lsbCkNClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAs IDIwMTQgODozNSBBTQ0KVG86IEZlbGl4OyBKb3NlIFNhbGRhbmE7IE9wZW52NkBpZXRmLm9yZzxt YWlsdG86T3BlbnY2QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPcGVudjZdILTwuLQ6IEFub3Ro ZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9mIHRoZSBmdW5jdGlvbmFsaXRpZXMNCg0KKzENCklNSE8s IHRoaXMgb25lIGlzIGFwcHJvcHJpYXRlLg0KDQpSZWdhcmRzLA0KV2lsbCAoU2h1Y2hlbmcgTElV KQ0KDQpGcm9tOiBPcGVudjYgW21haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEZlbGl4DQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDEyOjM5IEFNDQpUbzog Sm9zZSBTYWxkYW5hOyBPcGVudjZAaWV0Zi5vcmc8bWFpbHRvOk9wZW52NkBpZXRmLm9yZz4NClN1 YmplY3Q6IFtPcGVudjZdILTwuLQ6IEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9mIHRoZSBm dW5jdGlvbmFsaXRpZXMNCg0KDQpIaSBhbGwsDQoNCg0KDQpJIHByZWZlciAiTmV0d29yayBjYXBh YmlsaXRpZXMiIGZvciBncm91cGluZyB0aGVzZSBhY3Rpb25zLg0KDQoNCg0KQmVzdCByZWdhcmRz IQ0KDQpGZWxpeA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IE9wZW52NiBbb3BlbnY2LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSm9zZSBTYWxkYW5h IFtqc2FsZGFuYUB1bml6YXIuZXNdDQq3osvNyrG85DogMjAxNMTqNtTCOcjVIDIzOjMxDQrK1bz+ yMs6IE9wZW52NkBpZXRmLm9yZzxtYWlsdG86T3BlbnY2QGlldGYub3JnPg0K1vfM4jogW09wZW52 Nl0gQW5vdGhlciBxdWVzdGlvbjogdGhlIG5hbWUgb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KSGks DQoNCkFub3RoZXIgcXVlc3Rpb24gaXMgaG93IHRvIG5hbWUgdGhlIHNldCBvZiBmdW5jdGlvbmFs aXRpZXMgeW91IGFyZSBjb25zaWRlcmluZyBpbiBBUE9ORjoNCg0KLSBJbiB0aGUgZmlyc3QgcGFy YWdyYXBoLCB0aGV5IGFyZSBjYWxsZWQgobB0cmFmZmljIGNhcGFiaWxpdGllc6GxOiChsCB0aGUg Y29tbXVuaWNhdGlvbiBuZXR3b3JrIHRvIGFwcGx5IHRoZSBmb2xsb3dpbmcgZGlmZmVyZW50IG5l dHdvcmsgbWFuYWdlbWVudCBhbmQvb3IgdHJhZmZpYyBjYXBhYmlsaXRpZXOhsQ0KDQotIExhdGVy LCB0aGV5IGFyZSBjYWxsZWQgobB0cmFmZmljIHBvbGljaWVzobE6IKGwRXhhbXBsZXMgb2Ygc3Vj aCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIHRyYWZmaWMgcG9saWNpZXMgdGhhdCBhcmUgY29uc2lk ZXJlZCBieSBBUE9ORiBhcmUgdGhlIGZvbGxvd2luZ6GxDQoNCg0KSSB0aGluayB0aGF0IGZpbmRp bmcgYSBnb29kIG5hbWUgZ3JvdXBpbmcgdGhlc2UgYWN0aW9ucyBpcyBjcnVjaWFsOg0KDQpNYW5h Z2UgZHluYW1pY2FsbHkgbmV0d29yayBzZW1hbnRpY3MNCk9yY2hlc3RyYXRlIGR5bmFtaWNhbGx5 IHZpcnR1YWxpemVkIGZ1bmN0aW9ucw0KUGVybWl0IG9yIEJsb2NrIG9yIFJlZGlyZWN0IHRoZSB0 cmFmZmljDQpMb2cgdGhlIHRyYWZmaWMNCkNvcHkgdGhlIHRyYWZmaWMNClNldCB0aGUgdHJhZmZp Yw0KTWFyayB0aGUgdHJhZmZpYw0KDQpBcmUgdGhleSB0cmFmZmljIHBvbGljaWVzPyBOZXR3b3Jr IGFjdGlvbnM/IE5ldHdvcmsgZnVuY3Rpb25hbGl0aWVzPyBOZXR3b3JrIGNhcGFiaWxpdGllcz8g VHJhZmZpYyBjYXBhYmlsaXRpZXM/IE5ldHdvcmsgbWFuYWdlbWVudCBhY3Rpb25zPw0KDQoNCldo YXQgZG8geW91IHRoaW5rPw0KDQpKb3NlIFNhbGRhbmENCg0K --_000_C9B5F12337F6F841B35C404CF0554ACB5FEF762ESZXEMA509MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hosnieh,=

 

Thank you for your sug= gestion. You=A1=AFre right. GiLAN is a good case that we should consider ad= ding this.

 

Regards,

Will (Shucheng LIU)

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Tuesday, June 10, 2014 2:43 PM
To: Openv6@ietf.org
Subject: Re: [Openv6] =B4=F0=B8=B4: Another = question: the name of the functionalities

 

Hi all,

   GiLan is = another important application of network function virtualization. You may c= onsider to add this into your PS draft.

Best,

Hosnieh

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng (Will)
Sent: Tuesday, June 10, 2014 8:35 AM
To: Felix; Jose Saldana; Openv6@i= etf.org
Subject: Re: [Openv6] =B4=F0=B8=B4: Another = question: the name of the functionalities

 

+1

IMHO, this one is appr= opriate.

 

Regards,

Will (Shucheng LIU)

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of Felix
Sent: Tuesday, June 10, 2014 12:39 AM
To: Jose Saldana; Openv6@ietf.org=
Subject: [Openv6] =B4=F0=B8=B4: Another ques= tion: the name of the functionalities

 

Hi all,

 

I prefer "Network capabili= ties" for grouping these actions.

 

Best regards!

Felix

 

 

=B7=A2= =BC=FE=C8=CB:<= span lang=3D"ES" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif";color:black"> Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29<= span lang=3D"ZH-CN" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:black">=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Openv6@ietf.org
=D6=F7=CC=E2: [Openv6] Another question: the name of the functionalities

Hi,

 <= /o:p>

Another question is how to name the set of f= unctionalities you are considering in APONF:

 <= /o:p>

- In the first paragraph, they are called = =A1=B0traffic capabilities=A1=B1: =A1=B0&nb= sp;the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

 <= /o:p>

- Later, they are called =A1=B0traffic polic= ies=A1=B1: =A1=B0Examples of such network management and traffic policies that are considered by APONF are the following=A1=B1

 <= /o:p>

 <= /o:p>

I think that finding a good name grouping th= ese actions is crucial:=

 <= /o:p>

Manage dynamically network semantics<= span lang=3D"ES" style=3D"color:black">

Orchestrate dynamically virtualized function= s

Permit or Block or Redirect the traffic

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 <= /o:p>

Are they traffic policies? Network actions? = Network functionalities? Network capabilities? Traffic capabilities? Networ= k management actions?

 <= /o:p>

 <= /o:p>

What do you think?

 <= /o:p>

Jose Saldana

 <= /o:p>

--_000_C9B5F12337F6F841B35C404CF0554ACB5FEF762ESZXEMA509MBSchi_-- From nobody Tue Jun 10 00:31:57 2014 Return-Path: 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 801861A0421 for ; Tue, 10 Jun 2014 00:31:55 -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 B9VJWhWsOfN2 for ; Tue, 10 Jun 2014 00:31:52 -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 1C1BB1A023C for ; Tue, 10 Jun 2014 00:31:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIG35940; Tue, 10 Jun 2014 07:31:49 +0000 (GMT) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Jun 2014 08:31:48 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.210]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Tue, 10 Jun 2014 15:31:38 +0800 From: Tina TSOU To: "karagian@cs.utwente.nl" , "jsaldana@unizar.es" , "Openv6@ietf.org" Thread-Topic: [Openv6] Is there a draft charter for APONF? Thread-Index: Ac+D9qNFruvdoEliTFauT0nZdN8okwAEVOrrAB1I+KA= Date: Tue, 10 Jun 2014 07:31:38 +0000 Message-ID: References: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.11] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8183369BCszxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/xH7zU33XTTIzEi875_ZAMvawaPY Subject: Re: [Openv6] Is there a draft charter for APONF? X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 07:31:55 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8183369BCszxeml557mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Here is the first cut of a draft charter for APONF. APONF (Application-based Policy for Network Functions) charter Description of Working Group: Currently, there are transport applications that have specific demands on a= communication network. For example, some specialized applications, like vi= rtual network function services, may need to *dynamically manage* the netwo= rk infrastructure, and other specialized applications, like streaming appli= cations and Internet of Things (IoT) applications, may require from the net= work to treat their traffic according to their demands. If possible, a spec= ialized application may require from the communication network to apply the= following different network management and/or traffic capabilities, such = as: * dynamically (re)configure a network entity * accelerate the service deployment * getting better network services from transport network * providing better user experience The application's demands on a communication network are different, but the= re are several specialized application demands that may be similar, such as= different IoT applications, virtual network function services, which can b= e grouped/classified together. The classified application demands on a comm= unication network can be presented and modeled as classified application-ba= sed policies. A set of application-based policy models may be needed for au= to-mapping of application's demands to existing network management and/or t= raffic policies. This will allow applications to use the network capabiliti= es in a more accurate and efficient way. The definition of these network management and traffic policies is out of t= he APONF scope. Examples of such network management and traffic policies that are considere= d by APONF are the following: * Manage dynamically network semantics (supported by e.g., SNMP= /MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function= Virtualization configuration) BOF activity) * Orchestrate dynamically virtualized functions (supported by e= .g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF ac= tivity, Abstraction and Control of Transport Networks (ACTN) BOF activity) * Permit/Block/Redirect the traffic (supported by e.g., I2RS WG= , FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity) * Log the traffic (supported by e.g., I2RS WG, FORCES WG, Appli= cation Enabled Collaborative Network (AECN) BOF activity) * Copy the traffic, e.g., multicast (supported by e.g.,I2RS WG,= FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity * Set the traffic, e.g., encapsulation/decapsulation (supported= for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collab= orative Network (AECN) BOF activity) * Mark the traffic (supported for/by e.g., Intserv, Diffserv, P= CN, MPLS) These application-based policy models can meet the specialized application'= s demands on the communication network and map these demands to network man= agement and traffic policies that can be understood by the communication ne= twork. The main goal of APONF is to specify the application-based policy protocol(= s), mechanisms and models required by transport applications to easily, ac= curately, and efficiently select and use the available communication networ= k capabilities, i.e., network management and/or traffic policies. The users of the APONF may be the network management applications, or (BOF)= TAPS (Transport Services) requests that have specific demands on a communi= cation network. Work items related to APONF include: * specify the APONF groups/classes of application policies and = models * provide mechanisms that can accurately map and store the APON= F groups/classes of application policies and models into existing network m= anagement and traffic policies. * specify the protocol and the required mechanisms that are abl= e to support the communication between the transport applications and the = ABPD entity that maintains the groups/classes of application policies and m= odels. * provide the means to use existing network management and/or t= raffic conditioning protocols and mechanisms to enforce the application po= licies (via the associated network management and traffic policies) into ne= twork entities. Such protocols and mechanism are supported for/by e.g., SNM= P/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon activity, SCF WG,= ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intse= rv, Diffsrerv, PCN, MPLS. * provide authentication and authorization mechanisms to suppor= t the communication between the Transport Application and the ABPD entity. * provide privacy support for the end users running the applica= tions that make use of the APONF protocol and mechanisms. Initially, the APONF work will focus on the follow aspects: * high-level architecture * Solution requirements * a set of application based policy models for different classe= s of applications * a set of use cases * analysis of existing protocols that can be reused in the arch= itecture Milestones: * November 2014 Submit I-D 'Use cases' to the IESG for consider= ation as an Informational RFC. * February 2015 - Submit I-D 'Solution Requirements' to the IES= G for consideration as an Informational RFC. * March 2015 Submit I-D 'High level Architecture' to the IESG f= or consideration as an Informational RFC.- * July 2015 Submit I-D 'Gap Analysis' to the IESG for considera= tion as an Informational RFC.- * Jul y2015 - Evaluate the need for further work based on the i= dentified gaps and revise the milestones and/or the charter of the group Thank you, Tina From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Tuesday, June 10, 2014 1:28 AM To: jsaldana@unizar.es; Openv6@ietf.org Subject: Re: [Openv6] Is there a draft charter for APONF? Hi Jose, Thanks for the comments! Yes we are planning to create a APONF BOF charter soon! Best regards, Georgios ________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens Jose Saldana [jsaldana@unizar.= es] Verzonden: maandag 9 juni 2014 17:26 Aan: Openv6@ietf.org Onderwerp: [Openv6] Is there a draft charter for APONF? Hi, I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac= /wiki. Is there a draft charter somewhere? In case not, I would suggest to write a= first version and send it to the list. It would be somewhat similar to the= BoF summary, but it would also include the goals and milestones, deliverab= les of the potential WG, interactions with other WGs, etc. Best regards, Jose Saldana --_000_C0E0A32284495243BDE0AC8A066631A8183369BCszxeml557mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Here is the first cut = of a draft charter for APONF.

 

APONF (Application-= based Policy for Network Functions) charter

 

Description of Working= Group:

 

Currently, there are t= ransport applications that have specific demands on a communication network= . For example, some specialized applications, like virtual network function= services, may need to *dynamically manage* the network infrastructure, and other specialized applications, li= ke streaming applications and Internet of Things (IoT) applications, may re= quire from the network to treat their traffic according to their demands. I= f possible, a specialized application may require from the communication network to apply the following differen= t network management and/or traffic  capabilities, such as:=

•  &nb= sp;          dynamically (re)c= onfigure a network entity

•  &nb= sp;          accelerate the se= rvice deployment

•  &nb= sp;          getting better ne= twork services from transport network

•  &nb= sp;          providing better = user experience

 

The application’= s demands on a communication network are different, but there are several s= pecialized application demands that may be similar, such as different IoT a= pplications, virtual network function services, which can be grouped/classified together. The classified application deman= ds on a communication network can be presented and modeled as classified ap= plication-based policies. A set of application-based policy models may be n= eeded for auto-mapping of application’s demands to existing network management and/or traffic policies. This will = allow applications to use the network capabilities in a more accurate and e= fficient way.

 

The definition of thes= e network management and traffic policies is out of the APONF scope.

 

Examples of such netwo= rk management and traffic policies that are considered by APONF are the fol= lowing:

 

•  &nb= sp;          Manage dynamicall= y network semantics (supported by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang,= Web Services/MIB, nfvconf (Network Function Virtualization configuration) = BOF activity)

•  &nb= sp;          Orchestrate dynam= ically virtualized functions (supported by e.g., SCF WG, nfvconf (Network F= unction Virtualization configuration) BOF activity, Abstraction and Control= of Transport Networks (ACTN) BOF activity)

•  &nb= sp;          Permit/Block/Redi= rect the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enable= d Collaborative Network (AECN) BOF activity)

•  &nb= sp;          Log the traffic (= supported by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Ne= twork (AECN) BOF activity)

•  &nb= sp;          Copy the traffic,= e.g., multicast (supported by e.g.,I2RS WG, FORCES WG, Application Enabled= Collaborative Network (AECN) BOF activity

•  &nb= sp;          Set the traffic, = e.g., encapsulation/decapsulation (supported for/by e.g., NAT, Firewall, I2= RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF acti= vity)

•  &nb= sp;          Mark the traffic = (supported for/by e.g., Intserv, Diffserv, PCN, MPLS)

 

These application-base= d policy models can meet the specialized application’s demands on the= communication network and map these demands to network management and traf= fic policies that can be understood by the communication network.

 

The main goal of APONF= is to specify the application-based policy protocol(s), mechanisms and mod= els required  by transport applications to easily, accurately, and eff= iciently select and use the available communication network capabilities, i.e., network management and/or traffic policies.

 

The users of the APONF= may be the network management applications, or (BOF) TAPS (Transport Servi= ces) requests that have specific demands on a communication network.

 

Work items related to = APONF include:

•  &nb= sp;          specify the APONF= groups/classes of application policies and models

•  &nb= sp;          provide mechanism= s that can accurately map and store the APONF groups/classes of application= policies and models into existing network management and traffic policies.

•  &nb= sp;          specify the proto= col and the required mechanisms that are able  to support the communic= ation between the transport applications and the ABPD entity that maintains= the groups/classes of application policies and models.

•  &nb= sp;          provide the means= to use existing network management and/or traffic conditioning protocols a= nd mechanisms to enforce the  application policies (via the associated= network management and traffic policies) into network entities. Such protocols and mechanism are supporte= d for/by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon= activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NA= T, Firewall, Intserv, Diffsrerv, PCN, MPLS.

•  &nb= sp;          provide authentic= ation and authorization mechanisms to support the communication between the= Transport Application and the ABPD entity.

•  &nb= sp;          provide privacy s= upport for the end users running the applications that make use of the APON= F protocol and mechanisms.

 

Initially, the APONF w= ork will focus on the follow aspects:

•  &nb= sp;          high-level archit= ecture

•  &nb= sp;          Solution requirem= ents

•  &nb= sp;          a set of applicat= ion based policy models for different classes of applications

•  &nb= sp;          a set of use case= s

•  &nb= sp;          analysis of exist= ing protocols that can be reused in the architecture

 

Milestones:

•  &nb= sp;          November 2014 Sub= mit I-D 'Use cases' to the IESG for consideration as an Informational RFC.<= o:p>

•  &nb= sp;          February 2015 = 211; Submit I-D 'Solution Requirements' to the IESG for consideration as an= Informational RFC.

•  &nb= sp;          March 2015 Submit= I-D 'High level Architecture' to the IESG for consideration as an Informat= ional RFC.-

•  &nb= sp;          July 2015 Submit = I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.-

•  &nb= sp;          Jul y2015 - Evalu= ate the need for further work based on the identified gaps and revise the m= ilestones and/or the charter of the group

 

 

Thank you,<= /span>

Tina=

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Tuesday, June 10, 2014 1:28 AM
To: jsaldana@unizar.es; Openv6@ietf.org
Subject: Re: [Openv6] Is there a draft charter for APONF?=

 

Hi Jose,

 <= /o:p>

 <= /o:p>

Thanks for t= he comments!

Yes we are p= lanning to create a APONF BOF charter soon!

 <= /o:p>

Best regards= ,

Georgios

 <= /o:p>

Van: Openv= 6 [openv6-bounces@ietf.org] namens Jose Saldana [jsaldana@unizar.es]
Verzonden: maandag 9 juni 2014 17:26
Aan: Openv6@ietf.org
Onderwerp: [Openv6] Is there a draft charter for APONF?

Hi,

 <= /o:p>

I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac/wiki.

 <= /o:p>

Is there a draft charter somewhere? In case = not, I would suggest to write a first version and send it to the list. It w= ould be somewhat similar to the BoF summary, but it would also include the go= als and milestones, deliverables of the potential WG, interactions with oth= er WGs, etc.

 <= /o:p>

Best regards,

 <= /o:p>

Jose Saldana

 <= /o:p>

--_000_C0E0A32284495243BDE0AC8A066631A8183369BCszxeml557mbschi_-- From nobody Tue Jun 10 01:17:04 2014 Return-Path: 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 056F41A0271 for ; Tue, 10 Jun 2014 01:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 9Zk4s8gJzyAJ for ; Tue, 10 Jun 2014 01:16:57 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D365F1A0011 for ; Tue, 10 Jun 2014 01:16:56 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s5A8GmdA015872; Tue, 10 Jun 2014 10:16:48 +0200 From: "Jose Saldana" To: , References: <00c901cf83f7$eb70c230$c2524690$@unizar.es>, <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> In-Reply-To: Date: Tue, 10 Jun 2014 10:16:54 +0200 Message-ID: <012b01cf8484$5717c9c0$05475d40$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012C_01CF8495.1AA29590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9kWylUUL1vYNzUR5ybFhXA4fXwwGLun+2Adevxqqbcsk00A== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/siZqMw9htD_MdBLKFpqTNYDACVc Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:17:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012C_01CF8495.1AA29590 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, Georgios. My idea is: the IETF is a standardization body, so the = terms do matter. One has to be consistent and to clearly establish a = =A1=B0glossary of terms=A1=B1 to be used always the same way. =20 In addition, it could be a very good exercise to try to summarize the objective of APONF in a single sentence. Something like this (from the = draft charter): =20 =A1=B0The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required by transport applications = to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or = traffic policies.=A1=B1 =20 So here Tina talks about =A1=B0network management and/or traffic = policies.=A1=B1 =20 =20 Jose =20 De: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]=20 Enviado el: lunes, 09 de junio de 2014 19:38 Para: jsaldana@unizar.es; Openv6@ietf.org Asunto: RE: [Openv6] =B4=F0=B8=B4: Another question: the name of the = functionalities =20 Hi Jose, =20 Thanks for the comments! It is somehow difficult to find the right name for all these terms, = since these capabilities can be network management capabilities, traffic conditioning capabilities, traffic routiong capabilities, etc. =20 I am not sure if it is needed to find just one name for these terms! =20 Best regards, Georgios =20 =20 _____ =20 =B7=A2=BC=FE=C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose = Saldana [jsaldana@unizar. es] =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29=C8=D5 23:31 =CA=D5=BC=FE=C8=CB: Openv6@ietf.org =D6=F7=CC=E2: [Openv6] Another question: the name of the functionalities Hi, =20 Another question is how to name the set of functionalities you are considering in APONF: =20 - In the first paragraph, they are called =A1=B0traffic = capabilities=A1=B1: =A1=B0 the communication network to apply the following different network = management and/or traffic capabilities=A1=B1 =20 - Later, they are called =A1=B0traffic policies=A1=B1: =A1=B0Examples of = such network management and traffic policies that are considered by APONF are the following=A1=B1 =20 =20 I think that finding a good name grouping these actions is crucial: =20 Manage dynamically network semantics Orchestrate dynamically virtualized functions=20 Permit or Block or Redirect the traffic Log the traffic=20 Copy the traffic=20 Set the traffic=20 Mark the traffic =20 Are they traffic policies? Network actions? Network functionalities? = Network capabilities? Traffic capabilities? Network management actions? =20 =20 What do you think? =20 Jose Saldana =20 ------=_NextPart_000_012C_01CF8495.1AA29590 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Georgios. My idea = is: the IETF is a standardization body, so the terms do matter. One has = to be consistent and to clearly establish a =A1=B0glossary of = terms=A1=B1 to be used always the same way.

 

In addition, it could = be a very good exercise to try to summarize the objective of APONF in a = single sentence. Something like this (from the draft = charter):

 

=A1=B0The = main goal of APONF is to specify the application-based policy = protocol(s), mechanisms and models required  by transport = applications to easily, accurately, and efficiently select and use the = available communication network capabilities, i.e., network management = and/or traffic policies.=A1=B1

 

So here Tina talks = about =A1=B0network = management and/or traffic policies.=A1=B1

=

 

 

Jose

 

De: karagian@cs.utwente.nl [mailto:karagian@cs.= utwente.nl]
Enviado el: lunes, 09 de junio de 2014 = 19:38
Para: jsaldana@unizar.es; = Openv6@ietf.org
Asunto: RE: [Openv6] =B4=F0=B8=B4: Another = question: the name of the = functionalities

 

= Hi Jose,

=  

= Thanks for the comments!
It is somehow difficult to find the right = name for all these terms, since these capabilities can be network = management capabilities, traffic conditioning capabilities, traffic = routiong capabilities, etc.

=  

= I am not sure if it is needed to find just one name for these = terms!

=  

= Best regards,

= Georgios

=  

=  

=B7= =A2=BC=FE=C8=CB= := Openv6 [openv6-bounces@ietf.org] =B4= =FA=B1=ED= Jose Saldana [jsaldana@unizar.es]
=B7= =A2=CB=CD=CA=B1=BC=E4= := 2014=C4= =EA= 6=D4= =C2= 9=C8= =D5= 23:31
=CA= =D5=BC=FE=C8=CB= := Openv6@ietf.org
=D6= =F7=CC=E2= := [Openv6] Another question: the name of the functionalities

Hi,

 

Another question is how to name the set of functionalities you = are considering in APONF:

 

- In the first paragraph, they are called =A1=B0traffic = capabilities=A1=B1: =A1=B0 the communication network to apply the following different = network management and/or traffic capabilities=A1=B1

 

- Later, they are called =A1=B0traffic policies=A1=B1: = =A1=B0Examples of such network management and traffic policies that are = considered by APONF are the following=A1=B1

 

 

I think that finding a good name grouping these actions is = crucial:

 

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 

Are they traffic policies? Network actions? Network = functionalities? Network capabilities? Traffic capabilities? Network = management actions?

 

 

What do you think?

 

Jose Saldana

 

------=_NextPart_000_012C_01CF8495.1AA29590-- From nobody Tue Jun 10 03:07:12 2014 Return-Path: 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 8EDB41A04F1 for ; Tue, 10 Jun 2014 03:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 1cVG2OuLNaad for ; Tue, 10 Jun 2014 03:07:07 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901B41A0041 for ; Tue, 10 Jun 2014 03:07:07 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id im17so7524659vcb.35 for ; Tue, 10 Jun 2014 03:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DHBR+RFWJdPsOy3QF68H8tlrP0SOtxhtoBm9FTPmXJQ=; b=RLpMyUrdC4I9DcIZYztDelSmzOQCARIGmwDxusTGIipSfyuPYNVAsiEVaBJR/IUJ/J iegkdL0PPgGcmgw7xqTKhb7Vnu0c9LqmAQfQo4W5pVCTl0KMecm+zcVzmMjrAChORciM GTSjV/YPFKaJi+B0hv4OeoDaWnDZchkrXJSOLectA/rwoLgMZZ1aBqiA6wFSO9Ux1A8E K+qzTGKslLpAbyR16x5YailtVQk1Ru3EIrv+jwU3LtON88KXTjZJpgG30yDrpS1OKN0Z Zr+yqSjOkAI7RjRwfpydgqF9HCFOfsHHqMx4zpZvcgCfmWBaicu+KlKsycqj6SVHTUUV oq/Q== X-Received: by 10.52.14.130 with SMTP id p2mr26787550vdc.39.1402394826460; Tue, 10 Jun 2014 03:07:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.209 with HTTP; Tue, 10 Jun 2014 03:06:26 -0700 (PDT) In-Reply-To: <012b01cf8484$5717c9c0$05475d40$@unizar.es> References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> <012b01cf8484$5717c9c0$05475d40$@unizar.es> From: Qiong Date: Tue, 10 Jun 2014 18:06:26 +0800 Message-ID: To: Jose Saldana Content-Type: multipart/alternative; boundary=20cf302d4fc67759df04fb787d78 Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/RhyYN6YnoZ68lnDI22qkdwUAPGY Cc: karagian@cs.utwente.nl, Openv6@ietf.org Subject: Re: [Openv6] =?utf-8?b?562U5aSNOiBBbm90aGVyIHF1ZXN0aW9uOiB0aGUgbmFt?= =?utf-8?q?e_of_the_functionalities?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:07:09 -0000 --20cf302d4fc67759df04fb787d78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jose, Thanks for your comment. I think network capability is a more general work which can be applied to different scenarios. In APONF, we are focusing more on traffic-related capabilities, so I prefer the term more specific to "traffic". Best wishes --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Tue, Jun 10, 2014 at 4:16 PM, Jose Saldana wrote: > Hi, Georgios. My idea is: the IETF is a standardization body, so the term= s > do matter. One has to be consistent and to clearly establish a =E2=80=9Cg= lossary of > terms=E2=80=9D to be used always the same way. > > > > In addition, it could be a very good exercise to try to summarize the > objective of APONF in a single sentence. Something like this (from the > draft charter): > > > > =E2=80=9CThe main goal of APONF is to specify the application-based polic= y > protocol(s), mechanisms and models required by transport applications to > easily, accurately, and efficiently select and use the available > communication network capabilities, i.e., network management and/or traff= ic > policies.=E2=80=9D > > > > So here Tina talks about =E2=80=9Cnetwork management and/or traffic polic= ies.=E2=80=9D > > > > > > Jose > > > > *De:* karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > *Enviado el:* lunes, 09 de junio de 2014 19:38 > *Para:* jsaldana@unizar.es; Openv6@ietf.org > *Asunto:* RE: [Openv6] =E7=AD=94=E5=A4=8D: Another question: the name of = the > functionalities > > > > Hi Jose, > > > > Thanks for the comments! > It is somehow difficult to find the right name for all these terms, since > these capabilities can be network management capabilities, traffic > conditioning capabilities, traffic routiong capabilities, etc. > > > > I am not sure if it is needed to find just one name for these terms! > > > > Best regards, > > Georgios > > > > > ------------------------------ > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Openv6 [openv6-bounces@ietf.org] =E4=BB= =A3=E8=A1=A8 Jose Saldana [ > jsaldana@unizar.es] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2014=E5=B9=B46=E6=9C=889=E6=97= =A5 23:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* Openv6@ietf.org > *=E4=B8=BB=E9=A2=98**:* [Openv6] Another question: the name of the functi= onalities > > Hi, > > > > Another question is how to name the set of functionalities you are > considering in APONF: > > > > - In the first paragraph, they are called =E2=80=9Ctraffic capabilities= =E2=80=9D: =E2=80=9C the > communication network to apply the following different network management > and/or traffic capabilities=E2=80=9D > > > > - Later, they are called =E2=80=9Ctraffic policies=E2=80=9D: =E2=80=9CExa= mples of such network > management and traffic policies that are considered by APONF are the > following=E2=80=9D > > > > > > I think that finding a good name grouping these actions is crucial: > > > > Manage dynamically network semantics > > Orchestrate dynamically virtualized functions > > Permit or Block or Redirect the traffic > > Log the traffic > > Copy the traffic > > Set the traffic > > Mark the traffic > > > > Are they traffic policies? Network actions? Network functionalities? > Network capabilities? Traffic capabilities? Network management actions? > > > > > > What do you think? > > > > Jose Saldana > > > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --20cf302d4fc67759df04fb787d78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jose,

Thanks for your comment. I thi= nk network capability is a more general work which can be applied to differ= ent scenarios. In APONF, we are focusing more on traffic-related capabiliti= es, so I prefer the term more specific to "traffic".

Best wishes

--=C2=A0
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6:=C2=A0http://sourceforge.net/projects/laft6/
PCP-natcoord:=C2=A0http://sourceforge.net/projects/pcpportsetdemo/=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=C2=A0


On Tue, Jun 10, 2014 at 4:16 PM, Jose Sa= ldana <jsaldana@unizar.es> wrote:

Hi, Georgios. My idea is: the IETF is a standardization body, so the= terms do matter. One has to be consistent and to clearly establish a =E2= =80=9Cglossary of terms=E2=80=9D to be used always the same way.<= /u>

=C2=A0

In addition, it could be a very good exercise to try to summa= rize the objective of APONF in a single sentence. Something like this (from= the draft charter):

=C2=A0

=E2=80=9CThe main goal of APONF is to specify the applicatio= n-based policy protocol(s), mechanisms and models required=C2=A0 by transpo= rt applications to easily, accurately, and efficiently select and use the a= vailable communication network capabilities, i.e., network management and/o= r traffic policies.=E2=80=9D

=C2=A0

So here Tina talks about =E2=80=9Cnetwork management and/or = traffic policies.=E2=80=9D

=C2=A0

=C2=A0

Jose

=C2=A0

De: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]
Enviado el: lunes, 09 de junio de 2014 19:38
Para: jsaldana@unizar.es; Openv6@ietf.org
<= b>Asunto: RE: [Openv6] =E7=AD=94=E5=A4=8D: Another question: the name of the func= tionalities

=C2=A0

Hi Jose,

=C2=A0

Thanks for the comments!
It is somehow difficult to find the right name= for all these terms, since these capabilities can be network management ca= pabilities, traffic conditioning capabilities, traffic routiong capabilitie= s, etc.

=C2=A0

I am not sure if it is needed to find just= one=C2=A0name for these terms!

=C2=A0

Best regards,

<= span style=3D"font-size:10pt;font-family:Tahoma,sans-serif;color:black">Geo= rgios

=C2=A0

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Openv6 [openv6-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Jose Saldana [jsaldana@unizar.es]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:<= span style=3D"font-size:10pt;font-family:Tahoma,sans-serif;color:black"> 20= 14=E5=B9=B46=E6=9C=889=E6=97=A5= 2= 3:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Openv6@ietf.org
=E4=B8=BB=E9=A2=98: [Openv6] Another quest= ion: the name of the functionalities

Hi,=

=C2=A0=

Another question is how to name the set of fun= ctionalities you are considering in APONF:

=C2=A0

- In the first paragraph, they are call= ed =E2=80=9Ctraffic capabilities=E2=80=9D: =E2=80=9C= =C2=A0the communication network to apply the followin= g different network management and/or traffic capabilities=E2=80=9D<= span style=3D"color:black">

=C2=A0

- Later, they are called =E2=80=9Ctraff= ic policies=E2=80=9D: =E2=80=9CExamples of such network mana= gement and traffic policies that are considered by APONF are the following= =E2=80=9D

=C2=A0

=C2=A0<= /u>

I think that finding a good name= grouping these actions is crucial:

=C2=A0

Manage dynamically network semantics

Orchestrate dynamically virtualized functions =

Permit or Block or Redirect the traffic

Log the traffic =

Copy the traffic

Set the traffic=

Mark the traffic

=C2=A0

Are they traffic policies? Network actions? Ne= twork functionalities? Network capabilities? Traffic capabilities? Network = management actions?=

=C2=A0

=C2=A0<= /u>

What do you think?

=C2=A0

Jose Saldana

=C2=A0

_______________________________________________
Openv6 mailing list
Openv6@ietf.org
= https://www.ietf.org/mailman/listinfo/openv6




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--20cf302d4fc67759df04fb787d78-- From nobody Tue Jun 10 03:08:47 2014 Return-Path: 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 4B2061A04D2 for ; Tue, 10 Jun 2014 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no 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 ZPAerFI-f8FP for ; Tue, 10 Jun 2014 03:08:41 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA251A0041 for ; Tue, 10 Jun 2014 03:08:40 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hy4so1610035vcb.33 for ; Tue, 10 Jun 2014 03:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5MHvMvtLMByBjGFlJ7bmMnoI7FgNbpiNps9kL7SbIbo=; b=0LbO1idBed8SL3RrLNp7K8Lm6pSisq5Q+o+j4gvXG2nKWjtPlNLigOnLOu4PT1HoKN V5nOv7IVESqsLzjwjfthstNGGdwbBU/yLuOVfpDGo6iBp2S9IT2dwreuyP9Isumd+aEB zRDEfUREHY613uRfjCyBo7zws9pcLLWDqQKtKy3MMfvLm4FUGP47NedeFYgS9pIa+Vii 5BVeHWmibTLEx18N8rpES4u15mC/JKy8OBxBQwQxuDNTtmORdzHqMlIZzuguwdS9JATk 4G7gPgk76VO8geqXas28CGuTKfbQXRyFCeivz+eo+raiioQXpX5IStTOVeI7DHkVrt3T PolA== X-Received: by 10.221.29.137 with SMTP id ry9mr31787177vcb.6.1402394919938; Tue, 10 Jun 2014 03:08:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.209 with HTTP; Tue, 10 Jun 2014 03:07:59 -0700 (PDT) In-Reply-To: <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> From: Qiong Date: Tue, 10 Jun 2014 18:07:59 +0800 Message-ID: To: Hosnieh Rafiee Content-Type: multipart/alternative; boundary=001a1133935c09aeb004fb7883c7 Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/0TwaIB1vEN1uk3ripWuEAEK55pc Cc: Openv6@ietf.org Subject: Re: [Openv6] =?utf-8?b?562U5aSNOiBBbm90aGVyIHF1ZXN0aW9uOiB0aGUgbmFt?= =?utf-8?q?e_of_the_functionalities?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:08:42 -0000 --001a1133935c09aeb004fb7883c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree. This is also an important use case. We would add it in the next version. Thanks! Qiong On Tue, Jun 10, 2014 at 2:43 PM, Hosnieh Rafiee wrote: > Hi all, > > GiLan is another important application of network function > virtualization. You may consider to add this into your PS draft. > > Best, > > Hosnieh > > > > *From:* Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of *Liushuchen= g > (Will) > *Sent:* Tuesday, June 10, 2014 8:35 AM > *To:* Felix; Jose Saldana; Openv6@ietf.org > *Subject:* Re: [Openv6] =E7=AD=94=E5=A4=8D: Another question: the name of= the > functionalities > > > > +1 > > IMHO, this one is appropriate. > > > > Regards, > > Will (Shucheng LIU) > > > > *From:* Openv6 [mailto:openv6-bounces@ietf.org ]= *On > Behalf Of *Felix > *Sent:* Tuesday, June 10, 2014 12:39 AM > *To:* Jose Saldana; Openv6@ietf.org > *Subject:* [Openv6] =E7=AD=94=E5=A4=8D: Another question: the name of the= functionalities > > > > Hi all, > > > > I prefer "Network capabilities" for grouping these actions. > > > > Best regards! > > Felix > > > > > ------------------------------ > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Openv6 [openv6-bounces@ietf.org] =E4=BB= =A3=E8=A1=A8 Jose Saldana [ > jsaldana@unizar.es] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2014=E5=B9=B46=E6=9C=889=E6=97= =A5 23:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* Openv6@ietf.org > *=E4=B8=BB=E9=A2=98**:* [Openv6] Another question: the name of the functi= onalities > > Hi, > > > > Another question is how to name the set of functionalities you are > considering in APONF: > > > > - In the first paragraph, they are called =E2=80=9Ctraffic capabilities= =E2=80=9D: =E2=80=9C the > communication network to apply the following different network management > and/or traffic capabilities=E2=80=9D > > > > - Later, they are called =E2=80=9Ctraffic policies=E2=80=9D: =E2=80=9CExa= mples of such network > management and traffic policies that are considered by APONF are the > following=E2=80=9D > > > > > > I think that finding a good name grouping these actions is crucial: > > > > Manage dynamically network semantics > > Orchestrate dynamically virtualized functions > > Permit or Block or Redirect the traffic > > Log the traffic > > Copy the traffic > > Set the traffic > > Mark the traffic > > > > Are they traffic policies? Network actions? Network functionalities? > Network capabilities? Traffic capabilities? Network management actions? > > > > > > What do you think? > > > > Jose Saldana > > > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a1133935c09aeb004fb7883c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree. This is also an important use case. We would add it= in the next version.

Thanks!

Qiong

On Tue, Jun 10, 2014 at 2:43 PM, Hosnieh Rafiee <ietf@rozanak.com> wrote:

Hi all,

=C2=A0=C2=A0 GiLan is another = important application of network function virtualization. You may consider = to add this into your PS draft.

Best,

Hosnieh=

<= /u>=C2=A0

From:= Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng = (Will)
Sent: Tuesday, June 10, 2014 8:35 AM
To: Felix; Jose Salda= na; Openv6@ietf.org
Subject: Re: [Openv6] =E7=AD=94=E5=A4=8D: Ano= ther question: the name of the functionalities

=C2=A0<= /u>

+1

IMHO, this= one is appropriate.

=C2=A0

Regards,=

Will (Shucheng LIU)

=C2=A0=

From: Openv6 [= mailto:openv6-= bounces@ietf.org] On Behalf Of Felix
Sent: Tuesday, June 10, 2014 12:39 AM
To: Jose Saldana; Openv6@ietf.org
<= b>Subject: [Openv6] =E7=AD=94=E5=A4=8D: Another quest= ion: the name of the functionalities

=C2=A0

Hi all,

=C2=A0

I prefer=C2=A0"Network capabili= ties" for grouping these actions.

=C2=A0

Best regards!

Felix

=C2=A0

=C2=A0

=

=E5=8F=91= =E4=BB=B6=E4=BA=BA: Openv6 [openv6-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Jose Saldana= [jsaldana@unizar.e= s]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2014=E5=B9=B46= =E6=9C=889=E6=97= =A5 23:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Openv6@ietf.org
=E4=B8=BB=E9=A2=98: [Openv6] Another qu= estion: the name of the functionalities

Hi,

=C2=A0

Another question is how to name the set of f= unctionalities you are considering in APONF:

=C2=A0

- In the first paragraph,= they are called =E2=80=9Ctraffic capabilities=E2=80=9D: =E2=80=9C=C2=A0th= e communication network to apply the following different network management= and/or traffic capabilities=E2=80=9D

=C2=A0

- Later, they are called = =E2=80=9Ctraffic policies=E2=80=9D: =E2=80=9CExamples of such network management = and traffic policies that are considered by APONF are the following=E2=80= =9D

=C2=A0

=C2=A0

I thin= k that finding a good name grouping these actions is crucial:

=C2=A0

Manage dynamically networ= k semantics

Orchestrate dynamically virtualized function= s

<= p class=3D"MsoNormal"> Permit or Block or Redirect the traffic

= Log the traffic

Copy the traffic

Set the traffic <= /u>

Mark the traffic

=C2=A0

Are they traffic policies? Network actions? = Network functionalities? Network capabilities? Traffic capabilities? Networ= k management actions?=

=C2=A0

=C2=A0

What d= o you think?

=C2=A0

Jose Saldana

=C2=A0


_______________________________________________
Openv6 mailing list
Openv6@ietf.org
= https://www.ietf.org/mailman/listinfo/openv6




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a1133935c09aeb004fb7883c7-- From nobody Tue Jun 10 08:26:38 2014 Return-Path: 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 38F761A01C4 for ; Tue, 10 Jun 2014 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.4 X-Spam-Level: *** X-Spam-Status: No, score=3.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651] 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 qejygCwIBBLD for ; Tue, 10 Jun 2014 08:26:34 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC60F1B2834 for ; Tue, 10 Jun 2014 08:26:33 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id A002D56608D9; Tue, 10 Jun 2014 15:26:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPKA5HwCMAy5; Tue, 10 Jun 2014 17:26:00 +0200 (CEST) Received: from kopoli (g225041086.adsl.alicedsl.de [92.225.41.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id BB93E56608D8; Tue, 10 Jun 2014 17:25:59 +0200 (CEST) From: "Hosnieh Rafiee" To: , References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> , <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> In-Reply-To: Date: Tue, 10 Jun 2014 17:25:56 +0200 Message-ID: <002801cf84c0$46d587a0$d48096e0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01CF84D1.0A6C6160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9kWylUUL1vYNzUR5ybFhXA4fXwwGLun+2AUkLSOABVunwrwHuHNu5m12PD6A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/hJgmUQTrluDx5OvP_5pvSaT5I3M Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:26:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0029_01CF84D1.0A6C6160 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Georgios, =20 GiLan is another important application of network function = virtualization. In mobile core networks, it is preferable that QoS provisioning and = network function requirements are different for subscribers with different = profiles. In such scenarios, specialized applications such as BSS/OSS can send service policies to a policy decision point, which further map these = service policies to GiLan specific VNF policies, and realize the required QoS = and with appropriate network functions, for example, video transcoding parameters, traffic steering points, etc. =20 Best, Hosnieh =20 =20 =20 From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl Sent: Tuesday, June 10, 2014 8:47 AM To: ietf@rozanak.com; Openv6@ietf.org Subject: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of the functionalities =20 Hi Hosnieh, =20 Thank you very much! Can you please provide text? =20 Best regards, Georgios =20 _____ =20 Van: Openv6 [openv6-bounces@ietf.org] namens Hosnieh Rafiee [ietf@rozanak.com] Verzonden: dinsdag 10 juni 2014 8:43 Aan: Openv6@ietf.org Onderwerp: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of the functionalities Hi all, GiLan is another important application of network function virtualization. You may consider to add this into your PS draft. Best, Hosnieh =20 From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Tuesday, June 10, 2014 8:35 AM To: Felix; Jose Saldana; Openv6@ietf.org Subject: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of the functionalities =20 +1 IMHO, this one is appropriate. =20 Regards, Will (Shucheng LIU) =20 From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Felix Sent: Tuesday, June 10, 2014 12:39 AM To: Jose Saldana; Openv6@ietf.org Subject: [Openv6] =B4=F0=B8=B4: Another question: the name of the = functionalities =20 Hi all, =20 I prefer "Network capabilities" for grouping these actions. =20 Best regards! Felix =20 =20 _____ =20 =B7=A2=BC=FE=C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose = Saldana [jsaldana@unizar. es] =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29=C8=D5 23:31 =CA=D5=BC=FE=C8=CB: Openv6@ietf.org =D6=F7=CC=E2: [Openv6] Another question: the name of the functionalities Hi, =20 Another question is how to name the set of functionalities you are considering in APONF: =20 - In the first paragraph, they are called =A1=B0traffic = capabilities=A1=B1: =A1=B0 the communication network to apply the following different network = management and/or traffic capabilities=A1=B1 =20 - Later, they are called =A1=B0traffic policies=A1=B1: =A1=B0Examples of = such network management and traffic policies that are considered by APONF are the following=A1=B1 =20 =20 I think that finding a good name grouping these actions is crucial: =20 Manage dynamically network semantics Orchestrate dynamically virtualized functions=20 Permit or Block or Redirect the traffic Log the traffic=20 Copy the traffic=20 Set the traffic=20 Mark the traffic =20 Are they traffic policies? Network actions? Network functionalities? = Network capabilities? Traffic capabilities? Network management actions? =20 =20 What do you think? =20 Jose Saldana =20 ------=_NextPart_000_0029_01CF84D1.0A6C6160 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Georgios,

 

  GiLan is another = important application of network function virtualization. In mobile core = networks, it is preferable that QoS provisioning and network function = requirements are different for subscribers with different profiles. In = such scenarios, specialized applications such as BSS/OSS can  send = service policies to a policy decision point, which further map these = service policies to GiLan specific VNF policies, and realize the = required QoS and with appropriate network functions, for example, video = transcoding parameters, traffic steering points, = etc.

 

Best,

Hosnieh

 

=  

 

From:= = Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of = karagian@cs.utwente.nl
Sent: Tuesday, June 10, 2014 8:47 = AM
To: ietf@rozanak.com; Openv6@ietf.org
Subject: = Re: [Openv6] =B4=F0=B8=B4: Another = question: the name of the = functionalities

 

= Hi Hosnieh,

=  

= Thank you very much!

= Can you please provide text?

=  

= Best regards,

= Georgios

=  

= Van:= Openv6 [openv6-bounces@ietf.org] namens Hosnieh Rafiee = [ietf@rozanak.com]
Verzonden: dinsdag 10 juni 2014 = 8:43
Aan: Openv6@ietf.org
Onderwerp: = Re: [Openv6] =B4=F0=B8=B4= : Another question: the name of the functionalities

Hi all,

   GiLan is another important = application of network function virtualization. You may consider to add = this into your PS draft.

Best,

Hosnieh

 

= From:= Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Liushucheng (Will)
Sent: Tuesday, June = 10, 2014 8:35 AM
To: Felix; Jose Saldana; Openv6@ietf.org
Subject: = Re: [Openv6] =B4=F0=B8=B4= : Another question: the name of the functionalities

 

+1

IMHO, this one is appropriate.

 

Regards,

Will (Shucheng LIU)

 

= From:= Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of = Felix
Sent: Tuesday, June 10, 2014 12:39 AM
To: = Jose Saldana; Openv6@ietf.org
Subject: [Openv6] = =B4=F0=B8=B4= : Another question: the name of the functionalities

 

= Hi all,

 

= I prefer "Network capabilities" for grouping these = actions.

 

= Best regards!

= Felix

 

 

=B7=A2=BC=FE=C8= =CB= := Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED= Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA= =B1=BC=E4= := 2014=C4=EA= 6=D4=C2= 9=C8=D5= 23:31
=CA=D5=BC=FE=C8= =CB= := Openv6@ietf.org
=D6=F7=CC=E2= := [Openv6] Another question: the name of the functionalities

Hi,

 

Another = question is how to name the set of functionalities you are considering = in APONF:

 

- In the first = paragraph, they are called =A1=B0traffic capabilities=A1=B1: = =A1=B0 the = communication network to apply the following different network = management and/or traffic capabilities=A1=B1

 

- Later, they = are called =A1=B0traffic policies=A1=B1: =A1=B0Examples of such = network management and traffic policies that are considered by APONF are = the following=A1=B1

 

 

I think that = finding a good name grouping these actions is crucial:

 

Manage = dynamically network semantics

Orchestrate = dynamically virtualized functions

Permit or Block = or Redirect the traffic

Log the traffic =

Copy the = traffic

Set the traffic =

Mark the = traffic

 

Are they = traffic policies? Network actions? Network functionalities? Network = capabilities? Traffic capabilities? Network management = actions?

 

 

What do you = think?

 

Jose = Saldana

 

------=_NextPart_000_0029_01CF84D1.0A6C6160-- From nobody Tue Jun 10 13:16:05 2014 Return-Path: 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 631061A0282 for ; Tue, 10 Jun 2014 13:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.351 X-Spam-Level: *** X-Spam-Status: No, score=3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 b9wLdo7LgjLw for ; Tue, 10 Jun 2014 13:15:49 -0700 (PDT) Received: from out43-ams.mf.surf.net (out43-ams.mf.surf.net [145.0.1.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937071A03A7 for ; Tue, 10 Jun 2014 13:15:47 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5AKFhJ0022439; Tue, 10 Jun 2014 22:15:43 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 22:15:46 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 22:15:43 +0200 From: To: , Thread-Topic: =?gb2312?B?W09wZW52Nl0gtPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9m?= =?gb2312?Q?_the_functionalities?= Thread-Index: AQHPhAFf83E1b7HQf0OHVP2zV0TTNptpwsuAgAACJoCAACJa3IAAb7cAgAByMXw= Date: Tue, 10 Jun 2014 20:15:42 +0000 Message-ID: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es> <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> , <003001cf8477$3e2fd310$ba8f7930$@rozanak.com> , <002801cf84c0$46d587a0$d48096e0$@rozanak.com> In-Reply-To: <002801cf84c0$46d587a0$d48096e0$@rozanak.com> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF11EXMBX23adutwent_" 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.48; 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: 0vMcIfH5O - d87b7599c8bf - 20140610 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/A4z7-JSlzrvQzO9iZxDlnD9Bjw0 Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:15:51 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF11EXMBX23adutwent_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSG9zbmllaCwNCg0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ghDQpXZSB3aWxsIGNvbnNpZGVy IGl0IGZvciB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdCEN Cg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KR2Vvcmdpb2lzDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVmFuOiBIb3NuaWVoIFJhZmllZSBbaWV0ZkByb3phbmFrLmNvbV0N ClZlcnpvbmRlbjogZGluc2RhZyAxMCBqdW5pIDIwMTQgMTc6MjUNCkFhbjogS2FyYWdpYW5uaXMs IEcuIChFV0kpOyBPcGVudjZAaWV0Zi5vcmcNCk9uZGVyd2VycDogUkU6IFtPcGVudjZdILTwuLQ6 IEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9mIHRoZSBmdW5jdGlvbmFsaXRpZXMNCg0KSGkg R2Vvcmdpb3MsDQoNCiAgR2lMYW4gaXMgYW5vdGhlciBpbXBvcnRhbnQgYXBwbGljYXRpb24gb2Yg bmV0d29yayBmdW5jdGlvbiB2aXJ0dWFsaXphdGlvbi4gSW4gbW9iaWxlIGNvcmUgbmV0d29ya3Ms IGl0IGlzIHByZWZlcmFibGUgdGhhdCBRb1MgcHJvdmlzaW9uaW5nIGFuZCBuZXR3b3JrIGZ1bmN0 aW9uIHJlcXVpcmVtZW50cyBhcmUgZGlmZmVyZW50IGZvciBzdWJzY3JpYmVycyB3aXRoIGRpZmZl cmVudCBwcm9maWxlcy4gSW4gc3VjaCBzY2VuYXJpb3MsIHNwZWNpYWxpemVkIGFwcGxpY2F0aW9u cyBzdWNoIGFzIEJTUy9PU1MgY2FuICBzZW5kIHNlcnZpY2UgcG9saWNpZXMgdG8gYSBwb2xpY3kg ZGVjaXNpb24gcG9pbnQsIHdoaWNoIGZ1cnRoZXIgbWFwIHRoZXNlIHNlcnZpY2UgcG9saWNpZXMg dG8gR2lMYW4gc3BlY2lmaWMgVk5GIHBvbGljaWVzLCBhbmQgcmVhbGl6ZSB0aGUgcmVxdWlyZWQg UW9TIGFuZCB3aXRoIGFwcHJvcHJpYXRlIG5ldHdvcmsgZnVuY3Rpb25zLCBmb3IgZXhhbXBsZSwg dmlkZW8gdHJhbnNjb2RpbmcgcGFyYW1ldGVycywgdHJhZmZpYyBzdGVlcmluZyBwb2ludHMsIGV0 Yy4NCg0KQmVzdCwNCkhvc25pZWgNCg0KDQoNCkZyb206IE9wZW52NiBbbWFpbHRvOm9wZW52Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yga2FyYWdpYW5AY3MudXR3ZW50ZS5ubA0KU2Vu dDogVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA4OjQ3IEFNDQpUbzogaWV0ZkByb3phbmFrLmNvbTsg T3BlbnY2QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09wZW52Nl0gtPC4tDogQW5vdGhlciBxdWVz dGlvbjogdGhlIG5hbWUgb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KDQoNCkhpIEhvc25pZWgsDQoN Cg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIQ0KDQpDYW4geW91IHBsZWFzZSBwcm92aWRlIHRleHQ/ DQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkdlb3JnaW9zDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVmFuOiBPcGVudjYgW29wZW52Ni1ib3VuY2VzQGlldGYub3JnXSBu YW1lbnMgSG9zbmllaCBSYWZpZWUgW2lldGZAcm96YW5hay5jb21dDQpWZXJ6b25kZW46IGRpbnNk YWcgMTAganVuaSAyMDE0IDg6NDMNCkFhbjogT3BlbnY2QGlldGYub3JnPG1haWx0bzpPcGVudjZA aWV0Zi5vcmc+DQpPbmRlcndlcnA6IFJlOiBbT3BlbnY2XSC08Li0OiBBbm90aGVyIHF1ZXN0aW9u OiB0aGUgbmFtZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQpIaSBhbGwsDQogICBHaUxhbiBpcyBh bm90aGVyIGltcG9ydGFudCBhcHBsaWNhdGlvbiBvZiBuZXR3b3JrIGZ1bmN0aW9uIHZpcnR1YWxp emF0aW9uLiBZb3UgbWF5IGNvbnNpZGVyIHRvIGFkZCB0aGlzIGludG8geW91ciBQUyBkcmFmdC4N CkJlc3QsDQpIb3NuaWVoDQoNCkZyb206IE9wZW52NiBbbWFpbHRvOm9wZW52Ni1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTGl1c2h1Y2hlbmcgKFdpbGwpDQpTZW50OiBUdWVzZGF5LCBK dW5lIDEwLCAyMDE0IDg6MzUgQU0NClRvOiBGZWxpeDsgSm9zZSBTYWxkYW5hOyBPcGVudjZAaWV0 Zi5vcmc8bWFpbHRvOk9wZW52NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT3BlbnY2XSC08Li0 OiBBbm90aGVyIHF1ZXN0aW9uOiB0aGUgbmFtZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQoNCisx DQpJTUhPLCB0aGlzIG9uZSBpcyBhcHByb3ByaWF0ZS4NCg0KUmVnYXJkcywNCldpbGwgKFNodWNo ZW5nIExJVSkNCg0KRnJvbTogT3BlbnY2IFttYWlsdG86b3BlbnY2LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBGZWxpeA0KU2VudDogVHVlc2RheSwgSnVuZSAxMCwgMjAxNCAxMjozOSBB TQ0KVG86IEpvc2UgU2FsZGFuYTsgT3BlbnY2QGlldGYub3JnPG1haWx0bzpPcGVudjZAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbT3BlbnY2XSC08Li0OiBBbm90aGVyIHF1ZXN0aW9uOiB0aGUgbmFtZSBv ZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQoNCg0KSGkgYWxsLA0KDQoNCg0KSSBwcmVmZXIgIk5ldHdv cmsgY2FwYWJpbGl0aWVzIiBmb3IgZ3JvdXBpbmcgdGhlc2UgYWN0aW9ucy4NCg0KDQoNCkJlc3Qg cmVnYXJkcyENCg0KRmVsaXgNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kt6K8/sjLOiBPcGVudjYgW29wZW52Ni1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEpvc2Ug U2FsZGFuYSBbanNhbGRhbmFAdW5pemFyLmVzXQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjnI1SAyMzoz MQ0KytW8/sjLOiBPcGVudjZAaWV0Zi5vcmc8bWFpbHRvOk9wZW52NkBpZXRmLm9yZz4NCtb3zOI6 IFtPcGVudjZdIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9mIHRoZSBmdW5jdGlvbmFsaXRp ZXMNCkhpLA0KDQpBbm90aGVyIHF1ZXN0aW9uIGlzIGhvdyB0byBuYW1lIHRoZSBzZXQgb2YgZnVu Y3Rpb25hbGl0aWVzIHlvdSBhcmUgY29uc2lkZXJpbmcgaW4gQVBPTkY6DQoNCi0gSW4gdGhlIGZp cnN0IHBhcmFncmFwaCwgdGhleSBhcmUgY2FsbGVkIKGwdHJhZmZpYyBjYXBhYmlsaXRpZXOhsTog obAgdGhlIGNvbW11bmljYXRpb24gbmV0d29yayB0byBhcHBseSB0aGUgZm9sbG93aW5nIGRpZmZl cmVudCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kL29yIHRyYWZmaWMgY2FwYWJpbGl0aWVzobENCg0K LSBMYXRlciwgdGhleSBhcmUgY2FsbGVkIKGwdHJhZmZpYyBwb2xpY2llc6GxOiChsEV4YW1wbGVz IG9mIHN1Y2ggbmV0d29yayBtYW5hZ2VtZW50IGFuZCB0cmFmZmljIHBvbGljaWVzIHRoYXQgYXJl IGNvbnNpZGVyZWQgYnkgQVBPTkYgYXJlIHRoZSBmb2xsb3dpbmehsQ0KDQoNCkkgdGhpbmsgdGhh dCBmaW5kaW5nIGEgZ29vZCBuYW1lIGdyb3VwaW5nIHRoZXNlIGFjdGlvbnMgaXMgY3J1Y2lhbDoN Cg0KTWFuYWdlIGR5bmFtaWNhbGx5IG5ldHdvcmsgc2VtYW50aWNzDQpPcmNoZXN0cmF0ZSBkeW5h bWljYWxseSB2aXJ0dWFsaXplZCBmdW5jdGlvbnMNClBlcm1pdCBvciBCbG9jayBvciBSZWRpcmVj dCB0aGUgdHJhZmZpYw0KTG9nIHRoZSB0cmFmZmljDQpDb3B5IHRoZSB0cmFmZmljDQpTZXQgdGhl IHRyYWZmaWMNCk1hcmsgdGhlIHRyYWZmaWMNCg0KQXJlIHRoZXkgdHJhZmZpYyBwb2xpY2llcz8g TmV0d29yayBhY3Rpb25zPyBOZXR3b3JrIGZ1bmN0aW9uYWxpdGllcz8gTmV0d29yayBjYXBhYmls aXRpZXM/IFRyYWZmaWMgY2FwYWJpbGl0aWVzPyBOZXR3b3JrIG1hbmFnZW1lbnQgYWN0aW9ucz8N Cg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KSm9zZSBTYWxkYW5hDQoNCg== --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF11EXMBX23adutwent_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Hosnieh,

 

Thank you very much!
We will consider it for the next version of the problem statement draft!

 

Best regards,

Georgiois

 

Van: Hosnieh Rafiee [ietf@rozanak.com]
Verzonden: dinsdag 10 juni 2014 17:25
Aan: Karagiannis, G. (EWI); Openv6@ietf.org
Onderwerp: RE: [Openv6] =B4=F0=B8=B4: Another question: the name of = the functionalities

Hi Georgios,

 

  GiLan is anoth= er important application of network function virtualization. In mobile core= networks, it is preferable that QoS provisioning and network function requ= irements are different for subscribers with different profiles. In such scenarios, specialized applications such as BS= S/OSS can  send service policies to a policy decision point, which fur= ther map these service policies to GiLan specific VNF policies, and realize= the required QoS and with appropriate network functions, for example, video transcoding parameters, traffic stee= ring points, etc.

 

Best,

Hosnieh

 

<= /span> 

 

From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Tuesday, June 10, 2014 8:47 AM
To: ietf@rozanak.com; Openv6@ietf.org
Subject: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of th= e functionalities

 

Hi Hosnieh,

 

Thank you very much!

Can you please provide text?

 

Best regards,

Georgios

 

Van:<= /b> Openv6 [openv6-bounces@ietf.org] namens Hosnieh Rafiee [ietf@rozanak.com]
Verzonden: dinsdag 10 juni 2014 8:43
Aan: Openv6@iet= f.org
Onderwerp: Re: [Openv6] =B4=F0=B8=B4: An= other question: the name of the functionalities

Hi all,

   GiLan is= another important application of network function virtualization. You may = consider to add this into your PS draft.

Best,

Hosnieh

 

From: Openv6 [mailto:openv6-bounces@ie= tf.org] On Behalf Of Liushucheng (Will)
Sent: Tuesday, June 10, 2014 8:35 AM
To: Felix; Jose Saldana; Openv6@ietf.org
Subject: Re: [Openv6] =B4=F0=B8=B4: An= other question: the name of the functionalities

 

+1

IMHO, this one is app= ropriate.

 

Regards,

Will (Shucheng LIU)

 

From: Openv6 [mailto:openv6-bounces@ie= tf.org] On Behalf Of Felix
Sent: Tuesday, June 10, 2014 12:39 AM
To: Jose Saldana; Openv6@ietf.org
Subject: [Openv6] =B4=F0=B8=B4: Another = question: the name of the functionalities 

Hi all,

 

I prefer "Network capabilities" for gr= ouping these actions.

 

Best regards!

Felix

 

 

=B7=A2=BC=FE= =C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4:= 2014=C4=EA6=D4=C29=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Openv6@ietf.org =D6=F7=CC=E2:<= span style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: black; FONT-SIZE: = 10pt" lang=3D"ES"> [Openv6] Another question: the name of the functionalities

Hi,

 

Another question is how to name the set of functionalities yo= u are considering in APONF:

 

- In the first paragraph, they are called =A1=B0traffic capab= ilities=A1=B1: =A1=B0 the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

 

- Later, they are called =A1=B0traffic policies=A1=B1: =A1=B0= E= xamples of such network management and traffic policies that are considered by APONF are the following=A1=B1

 

 

I think that finding a good name grouping these actions is cr= ucial:

 

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 

Are they traffic policies? Network actions? Network functiona= lities? Network capabilities? Traffic capabilities? Network management acti= ons?

 

 

What do you think?=

 

Jose Saldana

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF11EXMBX23adutwent_-- From nobody Tue Jun 10 13:49:26 2014 Return-Path: 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 A9DB31A02F4 for ; Tue, 10 Jun 2014 13:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3Dk_AH3u7rs for ; Tue, 10 Jun 2014 13:49:12 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F05A1A02E0 for ; Tue, 10 Jun 2014 13:49:12 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id rd3so1100341pab.27 for ; Tue, 10 Jun 2014 13:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sAfbwOW+WOR9MpC4iZz3JCDPIydtDue+fZnJicYDSX4=; b=Leg/7d9gWgBifDjK22Tc1gKzpQ9CRVYi0+EFWSkbP9+iYRXDyy76fR7ZyrQCgX5eAZ Ph1cLPoICtha3/oaVd8PeOk968vqbsINZVY/FwGGny5A8570NmwC713m/Yb7FG50cdiZ zuIANe6NzKemLYjmhC3jUTxthx0Rd9fjVMVG3fRJ+TMmOCsjB/EW/TyHTFVxfSjm5H/H GrigF2+C6CnhXqOXhiJKoMogxjY8dMrXbP7YJ6in5zM8xxLiCno+ZdtGjbYtL0g4khZr 2iOiCxqFtCFXUAW3OkdIBoiRlAigEthaSlGIHQ7ap82bzUUlJYoQdM0ClsEFUhyPhwXb eW3w== X-Received: by 10.66.180.141 with SMTP id do13mr7852595pac.93.1402433352336; Tue, 10 Jun 2014 13:49:12 -0700 (PDT) Received: from [192.168.178.23] (163.193.69.111.dynamic.snap.net.nz. [111.69.193.163]) by mx.google.com with ESMTPSA id py7sm71055667pbb.78.2014.06.10.13.49.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 13:49:11 -0700 (PDT) Message-ID: <53976F49.8060402@gmail.com> Date: Wed, 11 Jun 2014 08:49:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: karagian@cs.utwente.nl References: , <5393787F.8040301@gmail.com> <53961AE0.8040507@gmail.com>, In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/ExNBw8iiV_umUupavAE7Lod1vaI Cc: cathy.zhou@huawei.com, openv6@ietf.org Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:49:14 -0000 Yes, we should discuss and hopefully attend both BOFs to improve understanding. I think the point where our ideas touch is one item in the draft charter that was just circulated: > * provide mechanisms that can accurately map and store the > APONF groups/classes of application policies and models into > existing network management and traffic policies. This isn't easy, because existing NM and policy mechanisms are basically a mess. Autonomic Networking would be a *new* approach to the problem of getting appropriate configuration into all network elements. There would be a new bullet: * provide mechanisms that can accurately map and store the APONF groups/classes of application policies and models into autonomic networking policy intent, so that autonomic networking mechanisms can implement the policies throughout the network. Regards Brian Carpenter On 10/06/2014 17:16, karagian@cs.utwente.nl wrote: > Hi Brian, > > In addition to what Cathy answered I would like to mention that yes, it will be good to meet in Toronto and discuss the issues that you mentioned! > > Best regards, > Georgios > > > ________________________________________ > Van: Zhouqian (Cathy) [cathy.zhou@huawei.com] > Verzonden: dinsdag 10 juni 2014 5:03 > Aan: Brian E Carpenter; Karagiannis, G. (EWI) > CC: openv6@ietf.org > Onderwerp: RE: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) > > Hi Brian, > > Best Regards, > Cathy > > >> -----Original Message----- >> From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: Tuesday, June 10, 2014 4:37 AM >> To: karagian@cs.utwente.nl >> Cc: openv6@ietf.org >> Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): >> new BOF for IETF 90 (requesting comments) >> >> Hi Georgios, >> >> On 08/06/2014 19:46, karagian@cs.utwente.nl wrote: >>> Hi Brian, >>> >>> Thanks for your comments! >>> >>> Regarding the relation to openv6, please note that APONF can be used to >> support an operator on deploying and configuring (and dynamically >> reconfiguring) different IPv4/IPv6 transition solutions depending on the applied >> scenarios and the expected user experience. >> >> Yes, that would be one application but I am still confused. I have seen no other >> traffic on the openv6 list, so what are we doing here? Why isn't this discussion >> on an APONF list, and where is the actual discussion of openv6? > > Openv6 is one use case of APONF. We already had two side meetings of openv6 in both IETF 88 and IETF 89. > So we hope to use the expertise in this list to discuss APONF first. > >>> Regarding the relation of APONF to UCAN, to my understanding, the UCAN >> BOF intends to expose several use cases that are focusing on Autonomic >> Networking (AN), i.e., self management. >>> APONF is focusing not focusing on solving AN issues. Please note that the >> dynamic (re)configuration issues mentioned in the APONF BOF (pre-charter) are >> not associated with self-management. >> >> Actually, any scenario that currently relies on a policy/management function >> and some kind of automation is a possible use case for autonomic networking. I >> don't see any of the actions involved in APONF as being out of scope for AN. >> Application-based policy intent would be considered as an input to the AN >> mechanisms, and the topics that you have listed as "network management and >> traffic policies" >> are exactly the type of objectives we would consider as targets for autonomic >> negotiation between network elements. >> >> The "the application-based policy protocol(s), mechanisms and models" >> that you mention might be exactly what is needed to communicate between >> applications and the AN policy mechanism. > APONF focuses on auto-mapping application's demand on network to the policy that can be understood by network. The applications could be the following ones, e.g., Traffic Engineering, Anti-DDoS, IPv6 transition, etc. These applications are not in the scope of Autonomic Network. One of APONF's objective is to define a set of models for such applications. These models may be used for AN or any other policy based use cases. > > >> If both BOFs are approved, we need to discuss in Toronto! >> >> Regards, >> Brian >> >>> Best regards, >>> Georgios >>> >>> >>> ________________________________________ >>> Van: Brian E Carpenter [brian.e.carpenter@gmail.com] >>> Verzonden: zaterdag 7 juni 2014 22:39 >>> Aan: Karagiannis, G. (EWI) >>> CC: openv6@ietf.org >>> Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network >>> Functions): new BOF for IETF 90 (requesting comments) >>> >>> Hi, >>> >>> Can you explain the specific relationship between this BOF and IPv6? >>> As far as I can see, it is 100% independent of the IP version (and >>> that is a good thing). >>> >>> By the way, the topic of autonomic configuration by negotiation >>> between various network elements, which could include the elements >>> involved in the APONF scenarios, is the subject of another BOF >>> proposal, which also has no specific dependency on IPv6: >>> http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal >>> APONF might be an additional use case for UCAN. >>> >>> Regards >>> Brian Carpenter >>> >>> On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: >>>> Hi all, >>>> >>>> Please note that a request for a BOF associated with Openv6 has been >> requested for IETF 90. >>>> The name of this BOF is: >>>> >>>> APONF (Application-based Policy for Network Functions). >>>> >>>> The main goal of APONF is to specify the application-based policy protocol(s), >> mechanisms and models required by transport applications to easily, accurately, >> and efficiently select and use the available communication network capabilities, >> i.e., network management and/or traffic policies. >>>> For more details on APONF, please see: >>>> http://trac.tools.ietf.org/bof/trac/# >>>> >>>> Please note that in association with this BOF two Internet drafts have been >> (up to now) submitted . >>>> These drafts are: >>>> >>>> APONF problem statement: >>>> http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement-00 >>>> .txt >>>> >>>> APONF architecture: >>>> http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt >>>> >>>> Your comments on the APONF BOF, and on the Internet drafts listed above >> are very much appreciated! >>>> Best regards, >>>> Georgios Karagiannis >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> --- >>>> >>>> _______________________________________________ >>>> Openv6 mailing list >>>> Openv6@ietf.org >>>> https://www.ietf.org/mailman/listinfo/openv6 >> _______________________________________________ >> Openv6 mailing list >> Openv6@ietf.org >> https://www.ietf.org/mailman/listinfo/openv6 From nobody Tue Jun 10 13:57:51 2014 Return-Path: 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 9122D1A0439 for ; Tue, 10 Jun 2014 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.351 X-Spam-Level: *** X-Spam-Status: No, score=3.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 ntpCLT1TijIF for ; Tue, 10 Jun 2014 13:57:29 -0700 (PDT) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3C11A02F4 for ; Tue, 10 Jun 2014 13:57:28 -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 s5AKvPD4008110; Tue, 10 Jun 2014 22:57:25 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 10 Jun 2014 22:57:27 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Tue, 10 Jun 2014 22:57:25 +0200 From: To: , Thread-Topic: =?gb2312?B?W09wZW52Nl0gtPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1lIG9m?= =?gb2312?Q?_the_functionalities?= Thread-Index: AQHPhAFf83E1b7HQf0OHVP2zV0TTNptpCewzgADVNwCAAOphYA== Date: Tue, 10 Jun 2014 20:57:24 +0000 Message-ID: References: <00c901cf83f7$eb70c230$c2524690$@unizar.es>, <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> , <012b01cf8484$5717c9c0$05475d40$@unizar.es> In-Reply-To: <012b01cf8484$5717c9c0$05475d40$@unizar.es> 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF5CEXMBX23adutwent_" 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: 0vMcIVpwv - a37f91f050a9 - 20140610 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/RlWXG-sFZb7mCWTQYGGE1NKx9_A Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:57:31 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF5CEXMBX23adutwent_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSm9zZSwNCg0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ghDQoNCkkgYWdyZWUgd2l0aCB5b3Ug dGhhdCB0aGUgdXNlZCB0ZXJtaW5vbG9neSBpbiBhbGwgZHJhZnRzIG5lZWRzIHRvIGJlIGNsZWFy IQ0KDQpBIGJldHRlciB0ZXJtaW5vbG9neSBzZWN0aW9uIHdpbGwgYmUgaW5jbHVkZWQgaW4gYSBu ZXh0IHZlcnNpb24gb2YgdGhlIHByb2JsZWxtZXQgc3RhdGVtZW50IGRyYWZ0IQ0KDQpIb3dldmVy LCBwbGVhc2Ugbm90ZSB0aGF0IHdoYXQgSSBtZWFudCBpbiB0aGUgcHJldmlvdXMgZW1haWwgaXMg dGhhdCBpdCBpcyBkaWZmaWN1bHQgYW5kIGl0IGlzIG5vdCBuZWVkZWQgdG8gZmluZCBvbmx5IG9u ZSB0ZXJtL25hbWUgdGhhdCBpbmNvcnBvcmF0ZXMgYWxsIHRoZSBjYXBhYmlsaXRpZXMgdGhhdCBo YXZlIGFuIGltcGFjdCBvbiBBUE9ORi4NCg0KDQoNCkluIG9yZGVyIHRvIGJlIGNsZWFyIHdlIG5l ZWQgdG8gbGlzdCBhbGwgdGhlIGNhcGFiaWxpdGllcyAobm90IG9ubHkgYW4gYWdncmVnYXRlZCBv bmUpIHRoYXQgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIG1lY2hhbmlzbXMgYW5kIHNvbHV0aW9ucyB0 aGF0IHdpbGwgYmUgd29ya2VkIG91dCBieSBBUE9ORi4NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0K R2Vvcmdpb3MNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpWYW46IEpv c2UgU2FsZGFuYSBbanNhbGRhbmFAdW5pemFyLmVzXQ0KVmVyem9uZGVuOiBkaW5zZGFnIDEwIGp1 bmkgMjAxNCAxMDoxNg0KQWFuOiBLYXJhZ2lhbm5pcywgRy4gKEVXSSk7IE9wZW52NkBpZXRmLm9y Zw0KT25kZXJ3ZXJwOiBSRTogW09wZW52Nl0gtPC4tDogQW5vdGhlciBxdWVzdGlvbjogdGhlIG5h bWUgb2YgdGhlIGZ1bmN0aW9uYWxpdGllcw0KDQpIaSwgR2Vvcmdpb3MuIE15IGlkZWEgaXM6IHRo ZSBJRVRGIGlzIGEgc3RhbmRhcmRpemF0aW9uIGJvZHksIHNvIHRoZSB0ZXJtcyBkbyBtYXR0ZXIu IE9uZSBoYXMgdG8gYmUgY29uc2lzdGVudCBhbmQgdG8gY2xlYXJseSBlc3RhYmxpc2ggYSChsGds b3NzYXJ5IG9mIHRlcm1zobEgdG8gYmUgdXNlZCBhbHdheXMgdGhlIHNhbWUgd2F5Lg0KDQpJbiBh ZGRpdGlvbiwgaXQgY291bGQgYmUgYSB2ZXJ5IGdvb2QgZXhlcmNpc2UgdG8gdHJ5IHRvIHN1bW1h cml6ZSB0aGUgb2JqZWN0aXZlIG9mIEFQT05GIGluIGEgc2luZ2xlIHNlbnRlbmNlLiBTb21ldGhp bmcgbGlrZSB0aGlzIChmcm9tIHRoZSBkcmFmdCBjaGFydGVyKToNCg0KobBUaGUgbWFpbiBnb2Fs IG9mIEFQT05GIGlzIHRvIHNwZWNpZnkgdGhlIGFwcGxpY2F0aW9uLWJhc2VkIHBvbGljeSBwcm90 b2NvbChzKSwgbWVjaGFuaXNtcyBhbmQgbW9kZWxzIHJlcXVpcmVkICBieSB0cmFuc3BvcnQgYXBw bGljYXRpb25zIHRvIGVhc2lseSwgYWNjdXJhdGVseSwgYW5kIGVmZmljaWVudGx5IHNlbGVjdCBh bmQgdXNlIHRoZSBhdmFpbGFibGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrIGNhcGFiaWxpdGllcywg aS5lLiwgbmV0d29yayBtYW5hZ2VtZW50IGFuZC9vciB0cmFmZmljIHBvbGljaWVzLqGxDQoNClNv IGhlcmUgVGluYSB0YWxrcyBhYm91dCChsG5ldHdvcmsgbWFuYWdlbWVudCBhbmQvb3IgdHJhZmZp YyBwb2xpY2llcy6hsQ0KDQoNCkpvc2UNCg0KRGU6IGthcmFnaWFuQGNzLnV0d2VudGUubmwgW21h aWx0bzprYXJhZ2lhbkBjcy51dHdlbnRlLm5sXQ0KRW52aWFkbyBlbDogbHVuZXMsIDA5IGRlIGp1 bmlvIGRlIDIwMTQgMTk6MzgNClBhcmE6IGpzYWxkYW5hQHVuaXphci5lczsgT3BlbnY2QGlldGYu b3JnDQpBc3VudG86IFJFOiBbT3BlbnY2XSC08Li0OiBBbm90aGVyIHF1ZXN0aW9uOiB0aGUgbmFt ZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQoNCg0KSGkgSm9zZSwNCg0KDQoNClRoYW5rcyBmb3Ig dGhlIGNvbW1lbnRzIQ0KSXQgaXMgc29tZWhvdyBkaWZmaWN1bHQgdG8gZmluZCB0aGUgcmlnaHQg bmFtZSBmb3IgYWxsIHRoZXNlIHRlcm1zLCBzaW5jZSB0aGVzZSBjYXBhYmlsaXRpZXMgY2FuIGJl IG5ldHdvcmsgbWFuYWdlbWVudCBjYXBhYmlsaXRpZXMsIHRyYWZmaWMgY29uZGl0aW9uaW5nIGNh cGFiaWxpdGllcywgdHJhZmZpYyByb3V0aW9uZyBjYXBhYmlsaXRpZXMsIGV0Yy4NCg0KDQoNCkkg YW0gbm90IHN1cmUgaWYgaXQgaXMgbmVlZGVkIHRvIGZpbmQganVzdCBvbmUgbmFtZSBmb3IgdGhl c2UgdGVybXMhDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkdlb3JnaW9zDQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogT3BlbnY2IFtvcGVudjYtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBKb3NlIFNhbGRhbmEgW2pzYWxkYW5hQHVuaXphci5lc10NCrei y83KsbzkOiAyMDE0xOo21MI5yNUgMjM6MzENCsrVvP7IyzogT3BlbnY2QGlldGYub3JnPG1haWx0 bzpPcGVudjZAaWV0Zi5vcmc+DQrW98ziOiBbT3BlbnY2XSBBbm90aGVyIHF1ZXN0aW9uOiB0aGUg bmFtZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVzDQpIaSwNCg0KQW5vdGhlciBxdWVzdGlvbiBpcyBo b3cgdG8gbmFtZSB0aGUgc2V0IG9mIGZ1bmN0aW9uYWxpdGllcyB5b3UgYXJlIGNvbnNpZGVyaW5n IGluIEFQT05GOg0KDQotIEluIHRoZSBmaXJzdCBwYXJhZ3JhcGgsIHRoZXkgYXJlIGNhbGxlZCCh sHRyYWZmaWMgY2FwYWJpbGl0aWVzobE6IKGwIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdvcmsgdG8g YXBwbHkgdGhlIGZvbGxvd2luZyBkaWZmZXJlbnQgbmV0d29yayBtYW5hZ2VtZW50IGFuZC9vciB0 cmFmZmljIGNhcGFiaWxpdGllc6GxDQoNCi0gTGF0ZXIsIHRoZXkgYXJlIGNhbGxlZCChsHRyYWZm aWMgcG9saWNpZXOhsTogobBFeGFtcGxlcyBvZiBzdWNoIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQg dHJhZmZpYyBwb2xpY2llcyB0aGF0IGFyZSBjb25zaWRlcmVkIGJ5IEFQT05GIGFyZSB0aGUgZm9s bG93aW5nobENCg0KDQpJIHRoaW5rIHRoYXQgZmluZGluZyBhIGdvb2QgbmFtZSBncm91cGluZyB0 aGVzZSBhY3Rpb25zIGlzIGNydWNpYWw6DQoNCk1hbmFnZSBkeW5hbWljYWxseSBuZXR3b3JrIHNl bWFudGljcw0KT3JjaGVzdHJhdGUgZHluYW1pY2FsbHkgdmlydHVhbGl6ZWQgZnVuY3Rpb25zDQpQ ZXJtaXQgb3IgQmxvY2sgb3IgUmVkaXJlY3QgdGhlIHRyYWZmaWMNCkxvZyB0aGUgdHJhZmZpYw0K Q29weSB0aGUgdHJhZmZpYw0KU2V0IHRoZSB0cmFmZmljDQpNYXJrIHRoZSB0cmFmZmljDQoNCkFy ZSB0aGV5IHRyYWZmaWMgcG9saWNpZXM/IE5ldHdvcmsgYWN0aW9ucz8gTmV0d29yayBmdW5jdGlv bmFsaXRpZXM/IE5ldHdvcmsgY2FwYWJpbGl0aWVzPyBUcmFmZmljIGNhcGFiaWxpdGllcz8gTmV0 d29yayBtYW5hZ2VtZW50IGFjdGlvbnM/DQoNCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCkpvc2Ug U2FsZGFuYQ0KDQo= --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF5CEXMBX23adutwent_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jose,

 

Thank you very much!

I agree with you that the used terminology in all drafts needs to be cle= ar!

A better terminology section will be included in a next version of the p= roblelmet statement draft!

However, please note that what I meant in the previous email is that it&= nbsp;is difficult and it is not needed to find only one term/name that inco= rporates all the capabilities that have an impact on APONF.

 

In order to be clear we need to list all the capabilities (not only an a= ggregated one) that have an impact on the mechanisms and solutions that wil= l be worked out by APONF.

 

Best regards,

Georgios

 

Van: Jose Saldana [jsaldana@unizar.es]
Verzonden: dinsdag 10 juni 2014 10:16
Aan: Karagiannis, G. (EWI); Openv6@ietf.org
Onderwerp: RE: [Openv6] =B4=F0=B8=B4: Another question: the name of = the functionalities

Hi, Georgios. My idea is: the IETF is a standa= rdization body, so the terms do matter. One has to be consistent and to cle= arly establish a =A1=B0glossary of terms=A1=B1 to be used always the same way.

 

In addition, it could be a very good exercise = to try to summarize the objective of APONF in a single sentence. Something = like this (from the draft charter):

 

=A1=B0The main goal of APONF is to specify the ap= plication-based policy protocol(s), mechanisms and models required  by transport applications to easily, accurately,= and efficiently select and use the available communication network capabil= ities, i.e., network management and/or traffic policies.=A1=B1=

 

So here Tina talks about =A1=B0network management= and/or traffic policies.=A1=B1

 

 

Jose

 

De: karagian@cs.utwent= e.nl [mailto:karagian@cs.utwente.nl]
Enviado el: lunes, 09 de junio de 2014 19:38
Para: jsaldana@unizar.es; Openv6@ietf.org
Asunto: RE: [Openv6] =B4=F0=B8=B4: Another question: the name of the= functionalities

 

Hi Jose,

 

Thanks for the comments!
It is somehow difficult to find the right name for all these terms, since t= hese capabilities can be network management capabilities, traffic condition= ing capabilities, traffic routiong capabilities, etc.

 

I am not sure if it is needed to find just one name for thes= e terms!

 

Best regards,

Georgios

 

 

=B7=A2=BC=FE= =C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED = Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA=B1=BC=E4:<= span style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: black; FONT-SIZE: = 10pt"> 2014=C4=EA6=D4=C29= =C8=D5: Openv6@ietf.org =D6=F7=CC=E2: [Openv6] Another question: the name of the functionalitiesHi,

 

Another question is how to name the set of fun= ctionalities you are considering in APONF:

 

- In the first paragraph, they are called =A1= =B0traffic capabilities=A1=B1: =A1=B0 the communication network to apply the following different network management = and/or traffic capabilities=A1=B1

 

- Later, they are called =A1=B0traffic policie= s=A1=B1: =A1=B0Examples of such network management and traffic policies that are considered by APONF are the following=A1=B1<= /span>

 

 

I think that finding a good name grouping thes= e actions is crucial:

 

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic=

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 

Are they traffic policies? Network actions? Ne= twork functionalities? Network capabilities? Traffic capabilities? Network = management actions?

 

 

What do you think?

 

Jose Saldana 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47BF5CEXMBX23adutwent_-- From nobody Tue Jun 10 19:17:21 2014 Return-Path: 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 DA7121A03BE for ; Tue, 10 Jun 2014 19:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v3MIEUKtnPwf for ; Tue, 10 Jun 2014 19:17:16 -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 BD1181A032D for ; Tue, 10 Jun 2014 19:17:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFH11272; Wed, 11 Jun 2014 02:17:14 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 03:17:13 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.46]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 10:17:05 +0800 From: Felix To: Brian E Carpenter , "karagian@cs.utwente.nl" Thread-Topic: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) Thread-Index: Ac+Cen59c8170usIQealtBkWdImy7P//pgyAgAC6TACAAmmgAP//GRqQgAF3/ICAAQS3gP//KOLQ Date: Wed, 11 Jun 2014 02:17:05 +0000 Message-ID: <4B29BA0800EE424E850D442A1A3D1803407190BB@SZXEMA510-MBX.china.huawei.com> References: , <5393787F.8040301@gmail.com> <53961AE0.8040507@gmail.com>, <53976F49.8060402@gmail.com> In-Reply-To: <53976F49.8060402@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/QN4Z9Dzn5UKMQMM1DccGI2zMwcA Cc: "Zhouqian \(Cathy\)" , "openv6@ietf.org" Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:17:19 -0000 > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Wednesday, June 11, 2014 4:49 AM > To: karagian@cs.utwente.nl > Cc: Zhouqian (Cathy); openv6@ietf.org > Subject: Re: [Openv6] APONF (Application-based Policy for Network Functio= ns): > new BOF for IETF 90 (requesting comments) >=20 > Yes, we should discuss and hopefully attend both BOFs to improve > understanding. >=20 > I think the point where our ideas touch is one item in the draft charter = that was > just circulated: >=20 > > * provide mechanisms that can accurately map and store the APONF > > groups/classes of application policies and models into existing > > network management and traffic policies. >=20 > This isn't easy, because existing NM and policy mechanisms are basically = a > mess. Autonomic Networking would be a *new* approach to the problem of > getting appropriate configuration into all network elements. There would = be a > new bullet: >=20 > * provide mechanisms that can accurately map and store the APONF > groups/classes of application policies and models into autonomic network= ing > policy intent, so that autonomic networking mechanisms can implement the > policies throughout the network. >=20 I think that the application's demands on network are limited types. Each t= ype of demands on network may be similar. And the demands on network are ba= sed on the capabilities that network can provide. Currently, the applicatio= n can not directly let its demands be known by network. The applications mu= st put their demands to the OSS/BSS or OSS/BSS-like component. After the de= mands are permitted by the operator, the demands can be enforced on network= . The cycle is too long and instant demands can't be achieved. If there is a mechanism and a set of models (e.g. Yang models) of the deman= ds for the application to use the network capabilities instantly, the appli= cation can use the network capabilities easily and the deployment of new ap= plication/service will be accelerated. To let application easily use networ= k capabilities and to let the acceleration of new application/service deplo= yment, "mapping application's demands on network to the policy understood b= y network" and "a set of models (e.g. Yang models) for different types dema= nds on network", may needed in IETF. So, after authorization, the applicati= on can use related network capabilities within the allowable range in an op= en way. This is useful for new application innovation and the openness of n= etwork capabilities to application. > Regards > Brian Carpenter >=20 > On 10/06/2014 17:16, karagian@cs.utwente.nl wrote: > > Hi Brian, > > > > In addition to what Cathy answered I would like to mention that yes, it= will be > good to meet in Toronto and discuss the issues that you mentioned! > > > > Best regards, > > Georgios > > > > > > ________________________________________ > > Van: Zhouqian (Cathy) [cathy.zhou@huawei.com] > > Verzonden: dinsdag 10 juni 2014 5:03 > > Aan: Brian E Carpenter; Karagiannis, G. (EWI) > > CC: openv6@ietf.org > > Onderwerp: RE: [Openv6] APONF (Application-based Policy for Network > > Functions): new BOF for IETF 90 (requesting comments) > > > > Hi Brian, > > > > Best Regards, > > Cathy > > > > > >> -----Original Message----- > >> From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Brian E > >> Carpenter > >> Sent: Tuesday, June 10, 2014 4:37 AM > >> To: karagian@cs.utwente.nl > >> Cc: openv6@ietf.org > >> Subject: Re: [Openv6] APONF (Application-based Policy for Network > Functions): > >> new BOF for IETF 90 (requesting comments) > >> > >> Hi Georgios, > >> > >> On 08/06/2014 19:46, karagian@cs.utwente.nl wrote: > >>> Hi Brian, > >>> > >>> Thanks for your comments! > >>> > >>> Regarding the relation to openv6, please note that APONF can be used > >>> to > >> support an operator on deploying and configuring (and dynamically > >> reconfiguring) different IPv4/IPv6 transition solutions depending on > >> the applied scenarios and the expected user experience. > >> > >> Yes, that would be one application but I am still confused. I have > >> seen no other traffic on the openv6 list, so what are we doing here? > >> Why isn't this discussion on an APONF list, and where is the actual > discussion of openv6? > > > > Openv6 is one use case of APONF. We already had two side meetings of > openv6 in both IETF 88 and IETF 89. > > So we hope to use the expertise in this list to discuss APONF first. > > > >>> Regarding the relation of APONF to UCAN, to my understanding, the > >>> UCAN > >> BOF intends to expose several use cases that are focusing on > >> Autonomic Networking (AN), i.e., self management. > >>> APONF is focusing not focusing on solving AN issues. Please note > >>> that the > >> dynamic (re)configuration issues mentioned in the APONF BOF > >> (pre-charter) are not associated with self-management. > >> > >> Actually, any scenario that currently relies on a policy/management > >> function and some kind of automation is a possible use case for > >> autonomic networking. I don't see any of the actions involved in APONF= as > being out of scope for AN. > >> Application-based policy intent would be considered as an input to > >> the AN mechanisms, and the topics that you have listed as "network > >> management and traffic policies" > >> are exactly the type of objectives we would consider as targets for > >> autonomic negotiation between network elements. > >> > >> The "the application-based policy protocol(s), mechanisms and models" > >> that you mention might be exactly what is needed to communicate > >> between applications and the AN policy mechanism. > > APONF focuses on auto-mapping application's demand on network to the > policy that can be understood by network. The applications could be the > following ones, e.g., Traffic Engineering, Anti-DDoS, IPv6 transition, et= c. These > applications are not in the scope of Autonomic Network. One of APONF's > objective is to define a set of models for such applications. These model= s may > be used for AN or any other policy based use cases. > > > > > >> If both BOFs are approved, we need to discuss in Toronto! > >> > >> Regards, > >> Brian > >> > >>> Best regards, > >>> Georgios > >>> > >>> > >>> ________________________________________ > >>> Van: Brian E Carpenter [brian.e.carpenter@gmail.com] > >>> Verzonden: zaterdag 7 juni 2014 22:39 > >>> Aan: Karagiannis, G. (EWI) > >>> CC: openv6@ietf.org > >>> Onderwerp: Re: [Openv6] APONF (Application-based Policy for Network > >>> Functions): new BOF for IETF 90 (requesting comments) > >>> > >>> Hi, > >>> > >>> Can you explain the specific relationship between this BOF and IPv6? > >>> As far as I can see, it is 100% independent of the IP version (and > >>> that is a good thing). > >>> > >>> By the way, the topic of autonomic configuration by negotiation > >>> between various network elements, which could include the elements > >>> involved in the APONF scenarios, is the subject of another BOF > >>> proposal, which also has no specific dependency on IPv6: > >>> http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal > >>> APONF might be an additional use case for UCAN. > >>> > >>> Regards > >>> Brian Carpenter > >>> > >>> On 08/06/2014 06:01, karagian@cs.utwente.nl wrote: > >>>> Hi all, > >>>> > >>>> Please note that a request for a BOF associated with Openv6 has > >>>> been > >> requested for IETF 90. > >>>> The name of this BOF is: > >>>> > >>>> APONF (Application-based Policy for Network Functions). > >>>> > >>>> The main goal of APONF is to specify the application-based policy > >>>> protocol(s), > >> mechanisms and models required by transport applications to easily, > >> accurately, and efficiently select and use the available > >> communication network capabilities, i.e., network management and/or > traffic policies. > >>>> For more details on APONF, please see: > >>>> http://trac.tools.ietf.org/bof/trac/# > >>>> > >>>> Please note that in association with this BOF two Internet drafts > >>>> have been > >> (up to now) submitted . > >>>> These drafts are: > >>>> > >>>> APONF problem statement: > >>>> http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statement- > >>>> 00 > >>>> .txt > >>>> > >>>> APONF architecture: > >>>> http://tools.ietf.org/id/draft-zhou-aponf-architecture-00.txt > >>>> > >>>> Your comments on the APONF BOF, and on the Internet drafts listed > >>>> above > >> are very much appreciated! > >>>> Best regards, > >>>> Georgios Karagiannis > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> --- > >>>> > >>>> _______________________________________________ > >>>> Openv6 mailing list > >>>> Openv6@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/openv6 > >> _______________________________________________ > >> Openv6 mailing list > >> Openv6@ietf.org > >> https://www.ietf.org/mailman/listinfo/openv6 >=20 > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 From nobody Tue Jun 10 23:18:07 2014 Return-Path: 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 DD0FB1A039C for ; Tue, 10 Jun 2014 23:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 67X_uNJ0oVxU for ; Tue, 10 Jun 2014 23:18:03 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7571A038A for ; Tue, 10 Jun 2014 23:18:03 -0700 (PDT) Received: from 89-212-12-89.dynamic.t-2.net ([89.212.12.89] helo=[192.168.10.87]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WubrC-0008Pj-Iw; Wed, 11 Jun 2014 08:17:58 +0200 Message-ID: <5397F469.1050503@gont.com.ar> Date: Wed, 11 Jun 2014 08:17:13 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Zhouqian (Cathy)" , xiechf01 , openv6 References: <201406101140259997043@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/O7GadPGNcsHuabrc1IHqTEp63CM Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 06:18:06 -0000 Hi, Cathy et al, I personally think it would be helpful that this ID indicates how other related work being carried out elsewhere (e.g. ETSI) relates to this work. For example, would it make sensible to take some of the work on trust models at ETSI to address the questions that have been raised on this list? Thanks! Best regards, Fernando On 06/10/2014 08:48 AM, Zhouqian (Cathy) wrote: > Hi Chongfeng, > > Thanks for your suggestion. Do you mean the workflow of an example use case? > > > > Best Regards, > > Cathy > > > > *From:*Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of *xiechf01 > *Sent:* Tuesday, June 10, 2014 11:41 AM > *To:* openv6 > *Subject:* [Openv6] About APONF drafts > > > > > > Hi, folks, > > > > I support to these 2 drafts, for they can help upper-layer applications > utilize the carrier network capabilities more efficiently and easily. > One suggestion, one part to describe a typical workflow can be added to > the current the architecture draft. > > > > Chongfeng@chinatelecom > > ------------------------------------------------------------------------ > > xiechf01 > > > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Jun 11 05:08:38 2014 Return-Path: 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 998371A03DB for ; Wed, 11 Jun 2014 00:25:07 -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 u1BKFiSdXNc4 for ; Wed, 11 Jun 2014 00:25:01 -0700 (PDT) Received: from out29-ams.mf.surf.net (out29-ams.mf.surf.net [145.0.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE811B2826 for ; Wed, 11 Jun 2014 00:25:00 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5B7Oqrb030361; Wed, 11 Jun 2014 09:24:52 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 11 Jun 2014 09:24:56 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 09:24:52 +0200 From: To: , , , Thread-Topic: [Openv6] About APONF drafts Thread-Index: AQHPhF8giKj8IzMkdEWbiNetyEwMPJtpxbkAgAGJk4CAADOlMA== Date: Wed, 11 Jun 2014 07:24:51 +0000 Message-ID: References: <201406101140259997043@gmail.com> <5397F469.1050503@gont.com.ar> In-Reply-To: <5397F469.1050503@gont.com.ar> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.48; 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: 0uMcToQPW - c598d78abb19 - 20140611 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/TD9XB5W3iTZTEyQsFqYWx4DeSRU Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 07:25:07 -0000 Hi Fernando, Yes, it will be great to have a use cases Internet draft that describes how= the ETSI trust models are used to solve similar problems! Can you start working and edit such an Internet draft? Best regards, Georgios > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Fernando > Gont > Sent: woensdag 11 juni 2014 8:17 > To: Zhouqian (Cathy); xiechf01; openv6 > Subject: Re: [Openv6] About APONF drafts >=20 > Hi, Cathy et al, >=20 > I personally think it would be helpful that this ID indicates how other r= elated > work being carried out elsewhere (e.g. ETSI) relates to this work. For > example, would it make sensible to take some of the work on trust models = at > ETSI to address the questions that have been raised on this list? >=20 > Thanks! >=20 > Best regards, > Fernando >=20 >=20 >=20 >=20 > On 06/10/2014 08:48 AM, Zhouqian (Cathy) wrote: > > Hi Chongfeng, > > > > Thanks for your suggestion. Do you mean the workflow of an example use > case? > > > > > > > > Best Regards, > > > > Cathy > > > > > > > > *From:*Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of > *xiechf01 > > *Sent:* Tuesday, June 10, 2014 11:41 AM > > *To:* openv6 > > *Subject:* [Openv6] About APONF drafts > > > > > > > > > > > > Hi, folks, > > > > > > > > I support to these 2 drafts, for they can help upper-layer > > applications utilize the carrier network capabilities more efficiently = and > easily. > > One suggestion, one part to describe a typical workflow can be added > > to the current the architecture draft. > > > > > > > > Chongfeng@chinatelecom > > > > ---------------------------------------------------------------------- > > -- > > > > xiechf01 > > > > > > > > _______________________________________________ > > Openv6 mailing list > > Openv6@ietf.org > > https://www.ietf.org/mailman/listinfo/openv6 > > >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 From nobody Wed Jun 11 05:38:43 2014 Return-Path: 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 8BD911B27B7 for ; Wed, 11 Jun 2014 05:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 SWLCnJNsZxKJ for ; Wed, 11 Jun 2014 05:38:37 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95E801ACAD6 for ; Wed, 11 Jun 2014 05:38:36 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s5BCcQCs012547; Wed, 11 Jun 2014 14:38:27 +0200 From: "Jose Saldana" To: , References: <00c901cf83f7$eb70c230$c2524690$@unizar.es>, <4B29BA0800EE424E850D442A1A3D180340718BEA@SZXEMA510-MBX.china.huawei.com> , <012b01cf8484$5717c9c0$05475d40$@unizar.es> In-Reply-To: Date: Wed, 11 Jun 2014 14:38:35 +0200 Message-ID: <008801cf8572$0fdab0b0$2f901210$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CF8582.D365F1B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9kWylUUL1vYNzUR5ybFhXA4fXwwGLun+2AdevxqoCUSlSCgIwfitem1CYrNA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/LKaFlOQ3euMR19RsDP5vmqmgebQ Subject: Re: [Openv6] =?gb2312?b?tPC4tDogIEFub3RoZXIgcXVlc3Rpb246IHRoZSBuYW1l?= =?gb2312?b?IG9mIHRoZSBmdW5jdGlvbmFsaXRpZXM=?= X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:38:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0089_01CF8582.D365F1B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Fully agree. =20 Best regards, =20 Jose =20 De: Openv6 [mailto:openv6-bounces@ietf.org] En nombre de karagian@cs.utwente.nl Enviado el: martes, 10 de junio de 2014 22:57 Para: jsaldana@unizar.es; Openv6@ietf.org Asunto: Re: [Openv6] =B4=F0=B8=B4: Another question: the name of the = functionalities =20 Hi Jose, =20 Thank you very much! I agree with you that the used terminology in all drafts needs to be = clear! A better terminology section will be included in a next version of the problelmet statement draft! However, please note that what I meant in the previous email is that it = is difficult and it is not needed to find only one term/name that = incorporates all the capabilities that have an impact on APONF. =20 In order to be clear we need to list all the capabilities (not only an aggregated one) that have an impact on the mechanisms and solutions that will be worked out by APONF. =20 Best regards, Georgios =20 _____ =20 Van: Jose Saldana [jsaldana@unizar.es] Verzonden: dinsdag 10 juni 2014 10:16 Aan: Karagiannis, G. (EWI); Openv6@ietf.org Onderwerp: RE: [Openv6] =B4=F0=B8=B4: Another question: the name of the functionalities Hi, Georgios. My idea is: the IETF is a standardization body, so the = terms do matter. One has to be consistent and to clearly establish a = =A1=B0glossary of terms=A1=B1 to be used always the same way. =20 In addition, it could be a very good exercise to try to summarize the objective of APONF in a single sentence. Something like this (from the = draft charter): =20 =A1=B0The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required by transport applications = to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or = traffic policies.=A1=B1 =20 So here Tina talks about =A1=B0network management and/or traffic = policies.=A1=B1 =20 =20 Jose =20 De: karagian@cs.utwente.nl [mailto: karagian@cs.utwente.nl]=20 Enviado el: lunes, 09 de junio de 2014 19:38 Para: jsaldana@unizar.es; Openv6@ietf.org Asunto: RE: [Openv6] =B4=F0=B8=B4: Another question: the name of the = functionalities =20 Hi Jose, =20 Thanks for the comments! It is somehow difficult to find the right name for all these terms, = since these capabilities can be network management capabilities, traffic conditioning capabilities, traffic routiong capabilities, etc. =20 I am not sure if it is needed to find just one name for these terms! =20 Best regards, Georgios =20 =20 _____ =20 =B7=A2=BC=FE=C8=CB: Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED Jose = Saldana [jsaldana@unizar. es] =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C29=C8=D5 23:31 =CA=D5=BC=FE=C8=CB: Openv6@ietf.org =D6=F7=CC=E2: [Openv6] Another question: the name of the functionalities Hi, =20 Another question is how to name the set of functionalities you are considering in APONF: =20 - In the first paragraph, they are called =A1=B0traffic = capabilities=A1=B1: =A1=B0 the communication network to apply the following different network = management and/or traffic capabilities=A1=B1 =20 - Later, they are called =A1=B0traffic policies=A1=B1: =A1=B0Examples of = such network management and traffic policies that are considered by APONF are the following=A1=B1 =20 =20 I think that finding a good name grouping these actions is crucial: =20 Manage dynamically network semantics Orchestrate dynamically virtualized functions=20 Permit or Block or Redirect the traffic Log the traffic=20 Copy the traffic=20 Set the traffic=20 Mark the traffic =20 Are they traffic policies? Network actions? Network functionalities? = Network capabilities? Traffic capabilities? Network management actions? =20 =20 What do you think? =20 Jose Saldana =20 ------=_NextPart_000_0089_01CF8582.D365F1B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Fully agree.

 

Best regards,

 

Jose<= /o:p>

 

De: = Openv6 [mailto:openv6-bounces@ietf.org] En nombre de = karagian@cs.utwente.nl
Enviado el: martes, 10 de junio de = 2014 22:57
Para: jsaldana@unizar.es; = Openv6@ietf.org
Asunto: Re: [Openv6] =B4=F0=B8=B4: Another = question: the name of the = functionalities

 

= Hi Jose,

=  

= Thank you very much!

= I agree with you that the used terminology in all drafts needs to be = clear!

= A better terminology section will be included in a next version of the = problelmet statement draft!

= However, please note that what I meant in the previous email is that = it is difficult and it is not needed to find only one term/name = that incorporates all the capabilities that have an impact = on APONF.

=  

= In order to be clear we need to list all the capabilities (not only an = aggregated one) that have an impact on the mechanisms and solutions that = will be worked out by APONF.

=  

= Best regards,

= Georgios

=  

= Van:= Jose Saldana [jsaldana@unizar.es]
Verzonden: dinsdag 10 juni = 2014 10:16
Aan: Karagiannis, G. (EWI); Openv6@ietf.org
Onderwerp: = RE: [Openv6] =B4= =F0=B8=B4= : Another question: the name of the functionalities

Hi, Georgios. My idea is: the IETF is a standardization body, so = the terms do matter. One has to be consistent and to clearly establish a = =A1=B0glossary of terms=A1=B1 to be used always the same = way.

 

In addition, it could be a very good exercise to try to = summarize the objective of APONF in a single sentence. Something like = this (from the draft charter):

 

=A1=B0The = main goal of APONF is to specify the application-based policy = protocol(s), mechanisms and models required  by transport = applications to easily, accurately, and efficiently select and use the = available communication network capabilities, i.e., network management = and/or traffic policies.=A1=B1

 

So here Tina talks about =A1=B0network = management and/or traffic policies.=A1=B1

 

 

Jose

 

De: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl= ]
Enviado el: lunes, 09 de junio de 2014 = 19:38
Para: jsaldana@unizar.es; Openv6@ietf.org
Asunto: = RE: [Openv6] =B4=F0=B8=B4= : Another question: the name of the functionalities

 

= Hi Jose,

 

= Thanks for the comments!
It is somehow difficult to find the right = name for all these terms, since these capabilities can be network = management capabilities, traffic conditioning capabilities, traffic = routiong capabilities, etc.

 

= I am not sure if it is needed to find just one name for these = terms!

 

= Best regards,

= Georgios

 

 

=B7=A2=BC=FE=C8= =CB= := Openv6 [openv6-bounces@ietf.org] =B4=FA=B1=ED= Jose Saldana [jsaldana@unizar.es]
=B7=A2=CB=CD=CA= =B1=BC=E4= := 2014=C4=EA= 6=D4=C2= 9=C8=D5= 23:31
=CA=D5=BC=FE=C8= =CB= := Openv6@ietf.org
=D6=F7=CC=E2= := [Openv6] Another question: the name of the functionalities

Hi,

 

Another question is how to name the set of functionalities you = are considering in APONF:

 

- In the first paragraph, they are called =A1=B0traffic = capabilities=A1=B1: =A1=B0 the communication network to apply the following different = network management and/or traffic capabilities=A1=B1

 

- Later, they are called =A1=B0traffic policies=A1=B1: = =A1=B0Examples of such network management and traffic policies that are = considered by APONF are the following=A1=B1

 

 

I think that finding a good name grouping these actions is = crucial:

 

Manage dynamically network semantics

Orchestrate dynamically virtualized functions

Permit or Block or Redirect the traffic

Log the traffic

Copy the traffic

Set the traffic

Mark the traffic

 

Are they traffic policies? Network actions? Network = functionalities? Network capabilities? Traffic capabilities? Network = management actions?

 

 

What do you think?

 

Jose Saldana

 

------=_NextPart_000_0089_01CF8582.D365F1B0-- From nobody Wed Jun 11 09:13:19 2014 Return-Path: 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 BA32C1B27A4 for ; Wed, 11 Jun 2014 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DRZcfY96fVn2 for ; Wed, 11 Jun 2014 09:13:15 -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 4B99B1A01AB for ; Wed, 11 Jun 2014 09:13:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFH85592; Wed, 11 Jun 2014 16:13:12 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 17:13:12 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml702-chm.china.huawei.com ([169.254.4.56]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 09:13:01 -0700 From: Linda Dunbar To: "karagian@cs.utwente.nl" , "fernando@gont.com.ar" , "Zhouqian (Cathy)" , "xiechf01@gmail.com" , Tina TSOU Thread-Topic: [Openv6] About APONF drafts Thread-Index: AQHPhTzuhqO1cUMEzE+czqV71QlOLptr91WAgAASoRCAAAqAsA== Date: Wed, 11 Jun 2014 16:13:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D3211E@dfweml701-chm.china.huawei.com> References: <201406101140259997043@gmail.com> <5397F469.1050503@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/73bh20iNxDTki5A5kVaeGx4GNxc Cc: "Openv6@ietf.org" Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:13:17 -0000 How about a use case draft on Enterprise DC Applications Policy Translation= ? In ONF L4-L7 Service group, we have been working on various policies that c= an be sent to network automatically from applications. Some of those cases = are applicable to APONF BoF.=20 Linda -----Original Message----- From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Wednesday, June 11, 2014 2:25 AM To: fernando@gont.com.ar; Zhouqian (Cathy); xiechf01@gmail.com; openv6@ietf= .org Subject: Re: [Openv6] About APONF drafts Hi Fernando, Yes, it will be great to have a use cases Internet draft that describes how= the ETSI trust models are used to solve similar problems! Can you start working and edit such an Internet draft? Best regards, Georgios > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Fernando=20 > Gont > Sent: woensdag 11 juni 2014 8:17 > To: Zhouqian (Cathy); xiechf01; openv6 > Subject: Re: [Openv6] About APONF drafts >=20 > Hi, Cathy et al, >=20 > I personally think it would be helpful that this ID indicates how=20 > other related work being carried out elsewhere (e.g. ETSI) relates to=20 > this work. For example, would it make sensible to take some of the=20 > work on trust models at ETSI to address the questions that have been rais= ed on this list? >=20 > Thanks! >=20 > Best regards, > Fernando >=20 >=20 >=20 >=20 > On 06/10/2014 08:48 AM, Zhouqian (Cathy) wrote: > > Hi Chongfeng, > > > > Thanks for your suggestion. Do you mean the workflow of an example=20 > > use > case? > > > > > > > > Best Regards, > > > > Cathy > > > > > > > > *From:*Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of > *xiechf01 > > *Sent:* Tuesday, June 10, 2014 11:41 AM > > *To:* openv6 > > *Subject:* [Openv6] About APONF drafts > > > > > > > > > > > > Hi, folks, > > > > > > > > I support to these 2 drafts, for they can help upper-layer=20 > > applications utilize the carrier network capabilities more=20 > > efficiently and > easily. > > One suggestion, one part to describe a typical workflow can be added=20 > > to the current the architecture draft. > > > > > > > > Chongfeng@chinatelecom > > > > -------------------------------------------------------------------- > > -- > > -- > > > > xiechf01 > > > > > > > > _______________________________________________ > > Openv6 mailing list > > Openv6@ietf.org > > https://www.ietf.org/mailman/listinfo/openv6 > > >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6 From nobody Wed Jun 11 09:26:24 2014 Return-Path: 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 486001B27B7 for ; Wed, 11 Jun 2014 09:26:21 -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 DchqG3_EcyVI for ; Wed, 11 Jun 2014 09:26:18 -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 AA9A51ACAD6 for ; Wed, 11 Jun 2014 09:26:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFH86429; Wed, 11 Jun 2014 16:26:07 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 17:26:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml704-chm.china.huawei.com ([169.254.6.5]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 09:25:53 -0700 From: Linda Dunbar To: Felix , "openv6@ietf.org" , "Brian E Carpenter" Thread-Topic: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) Thread-Index: Ac+FkdJE7DEkHyCRTMGQmAfhx+2sDg== Date: Wed, 11 Jun 2014 16:25:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D32179@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.29] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D32179dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/ligBG_PE4G4ZP2CHCbD5WOCURdo Subject: Re: [Openv6] APONF (Application-based Policy for Network Functions): new BOF for IETF 90 (requesting comments) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:26:21 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D32179dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Felix and Brian, Questions are inserted below: > -----Original Message----- > > * provide mechanisms that can accurately map and store the APONF > > groups/classes of application policies and models into existing > > network management and traffic policies. > > This isn't easy, because existing NM and policy mechanisms are basically = a > mess. Autonomic Networking would be a *new* approach to the problem of > getting appropriate configuration into all network elements. There would = be a > new bullet: > > * provide mechanisms that can accurately map and store the APONF > groups/classes of application policies and models into autonomic network= ing > policy intent, so that autonomic networking mechanisms can implement the > policies throughout the network. > [Linda] Are those "Mapping" being provided by providers before the Applicat= ions need to use them? In another words, are those mappings statically conf= igured ahead of time? So that Applications can search through the available= ones and map themselves? Linda If there is a mechanism and a set of models (e.g. Yang models) of the deman= ds for the application to use the network capabilities instantly, the appli= cation can use the network capabilities easily and the deployment of new ap= plication/service will be accelerated. [Linda] I would think that Yang Models would be the second step. The first = step might be having a signaling model for applications to search through t= he available mappings and choose the one that fit them the best. Then they = can use Yang Model to send their desired mapping to the network. To let application easily use network capabilities and to let the accelerat= ion of new application/service deployment, "mapping application's demands o= n network to the policy understood by network" and "a set of models (e.g. Y= ang models) for different types demands on network", may needed in IETF. So= , after authorization, the application can use related network capabilities= within the allowable range in an open way. This is useful for new applicat= ion innovation and the openness of network capabilities to application. > Regards > Brian Carpenter > > On 10/06/2014 17:16, karagian at cs.utwente.nl wrote: > > Hi Brian, > > > > In addition to what Cathy answered I would like to mention that yes, it= will be > good to meet in Toronto and discuss the issues that you mentioned! > > > > Best regards, > > Georgios > > > > > > ________________________________________ > > Van: Zhouqian (Cathy) [cathy.zhou at huawei.com] > > Verzonden: dinsdag 10 juni 2014 5:03 > > Aan: Brian E Carpenter; Karagiannis, G. (EWI) > > CC: openv6 at ietf.org > > Onderwerp: RE: [Openv6] APONF (Application-based Policy for Network > > Functions): new BOF for IETF 90 (requesting comments) > > > > Hi Brian, > > > > Best Regards, > > Cathy --_000_4A95BA014132FF49AE685FAB4B9F17F645D32179dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
 
Felix and Brian, 
 

Questions are inserted below:

 
 
> -----Original Message-----
> > * provide mechanisms that can accurately map and store the A=
PONF
> > groups/classes of application policies and models into exist=
ing
> > network management and traffic policies.
> 
> This isn't easy, because existing NM and policy mechanisms are ba=
sically a
> mess. Autonomic Networking would be a *new* approach to the probl=
em of
> getting appropriate configuration into all network elements. Ther=
e would be a
> new bullet:
> 
>  * provide mechanisms that can accurately map and store the&=
nbsp; APONF
> groups/classes of application policies and models into  auto=
nomic networking
> policy intent, so that autonomic networking  mechanisms can =
implement the
> policies throughout the network.
> 
 
[Linda] Are those “Mapping” being provided by providers be=
fore the Applications need to use them? In another words, are those mapping=
s statically configured ahead of time? So that Applications can search thro=
ugh the available ones and map themselves? 
 
Linda
 
 
If there is a mechanism and a set of models (e.g. Yang models) of the =
demands for the application to use the network capabilities instantly, the =
application can use the network capabilities easily and the deployment of n=
ew application/service will be accelerated. 
 
[Linda] I would think that Yang Models would be the second step. The f=
irst step might be having a signaling model for applications to search thro=
ugh the available mappings and choose the one that fit them the best. Then =
they can use Yang Model to send their desired mapping to the network. =

 
 
 
 
To let application easily use network capabilities and to let the acce=
leration of new application/service deployment, "mapping application's=
 demands on network to the policy understood by network" and "a s=
et of models (e.g. Yang models) for different types demands on network"=
;, may needed in IETF. So, after authorization, the application can use rel=
ated network capabilities within the allowable range in an open way. This i=
s useful for new application innovation and the openness of network capabil=
ities to application.
 
> Regards
>    Brian Carpenter
> 
> On 10/06/2014 17:16, karagian at cs.utwente.nl wrote:<=
/pre>

> > Hi Brian,


> >


> > In addition to what Cathy answered I would like to mention t=
hat yes, it will be


> good to meet in Toronto and discuss the issues that you mentioned=
!


> >


> > Best regards,


> > Georgios


> >


> >


> > ________________________________________


> > Van: Zhouqian (Cathy) [cathy.zhou at huawei.com]<=
/pre>

> > Verzonden: dinsdag 10 juni 2014 5:03


> > Aan: Brian E Carpenter; Karagiannis, G. (EWI)

> > CC: openv6 at ietf.org


> > Onderwerp: RE: [Openv6] APONF (Application-based Policy for =
Network


> > Functions): new BOF for IETF 90 (requesting comments)


> >


> > Hi Brian,


> >


> > Best Regards,


> > Cathy


 
--_000_4A95BA014132FF49AE685FAB4B9F17F645D32179dfweml701chmchi_-- From nobody Wed Jun 11 10:44:23 2014 Return-Path: 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 9452D1B2799 for ; Wed, 11 Jun 2014 10:44:19 -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 nNn9ShBFTX7i for ; Wed, 11 Jun 2014 10:44:16 -0700 (PDT) Received: from out61-ams.mf.surf.net (out61-ams.mf.surf.net [145.0.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7268E1A0213 for ; Wed, 11 Jun 2014 10:44:15 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5BHrrPI007897; Wed, 11 Jun 2014 19:53:53 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 11 Jun 2014 19:44:09 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 19:44:03 +0200 From: To: , , , , Thread-Topic: [Openv6] About APONF drafts Thread-Index: AQHPhF8giKj8IzMkdEWbiNetyEwMPJtr91WAgAASoRCAAAqAsIAAHA+p Date: Wed, 11 Jun 2014 17:44:03 +0000 Message-ID: References: <201406101140259997043@gmail.com> <5397F469.1050503@gont.com.ar> ,<4A95BA014132FF49AE685FAB4B9F17F645D3211E@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D3211E@dfweml701-chm.china.huawei.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.48; 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: 0bMd5RRjW - c7f29857269b - 20140611 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/70PZSoSMM3o8HEAm0GpR5PkN5jQ Cc: Openv6@ietf.org Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:44:19 -0000 Hi Linda, Thanks for the suggestion!=20 Yes, I think that this use case fits very well within the scope of APONF! Will you be willing to start working and/or editing an Internet draft that = describes this use case? Best regards, Georgios ________________________________________ Van: Linda Dunbar [linda.dunbar@huawei.com] Verzonden: woensdag 11 juni 2014 18:13 Aan: Karagiannis, G. (EWI); fernando@gont.com.ar; Zhouqian (Cathy); xiechf0= 1@gmail.com; Tina TSOU CC: Openv6@ietf.org Onderwerp: RE: [Openv6] About APONF drafts How about a use case draft on Enterprise DC Applications Policy Translation= ? In ONF L4-L7 Service group, we have been working on various policies that c= an be sent to network automatically from applications. Some of those cases = are applicable to APONF BoF. Linda -----Original Message----- From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Wednesday, June 11, 2014 2:25 AM To: fernando@gont.com.ar; Zhouqian (Cathy); xiechf01@gmail.com; openv6@ietf= .org Subject: Re: [Openv6] About APONF drafts Hi Fernando, Yes, it will be great to have a use cases Internet draft that describes how= the ETSI trust models are used to solve similar problems! Can you start working and edit such an Internet draft? Best regards, Georgios > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Fernando > Gont > Sent: woensdag 11 juni 2014 8:17 > To: Zhouqian (Cathy); xiechf01; openv6 > Subject: Re: [Openv6] About APONF drafts > > Hi, Cathy et al, > > I personally think it would be helpful that this ID indicates how > other related work being carried out elsewhere (e.g. ETSI) relates to > this work. For example, would it make sensible to take some of the > work on trust models at ETSI to address the questions that have been rais= ed on this list? > > Thanks! > > Best regards, > Fernando > > > > > On 06/10/2014 08:48 AM, Zhouqian (Cathy) wrote: > > Hi Chongfeng, > > > > Thanks for your suggestion. Do you mean the workflow of an example > > use > case? > > > > > > > > Best Regards, > > > > Cathy > > > > > > > > *From:*Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of > *xiechf01 > > *Sent:* Tuesday, June 10, 2014 11:41 AM > > *To:* openv6 > > *Subject:* [Openv6] About APONF drafts > > > > > > > > > > > > Hi, folks, > > > > > > > > I support to these 2 drafts, for they can help upper-layer > > applications utilize the carrier network capabilities more > > efficiently and > easily. > > One suggestion, one part to describe a typical workflow can be added > > to the current the architecture draft. > > > > > > > > Chongfeng@chinatelecom > > > > -------------------------------------------------------------------- > > -- > > -- > > > > xiechf01 > > > > > > > > _______________________________________________ > > Openv6 mailing list > > Openv6@ietf.org > > https://www.ietf.org/mailman/listinfo/openv6 > > > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6= From nobody Wed Jun 11 11:08:23 2014 Return-Path: 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 A02561A0254 for ; Wed, 11 Jun 2014 11:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QSaAvcBGKA02 for ; Wed, 11 Jun 2014 11:08:18 -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 3A83A1A023A for ; Wed, 11 Jun 2014 11:08:18 -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 BII00691; Wed, 11 Jun 2014 18:08:14 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 19:08:12 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 11:07:56 -0700 From: Linda Dunbar To: "karagian@cs.utwente.nl" , "fernando@gont.com.ar" , "Zhouqian (Cathy)" , "xiechf01@gmail.com" , Tina TSOU Thread-Topic: [Openv6] About APONF drafts Thread-Index: AQHPhTzuhqO1cUMEzE+czqV71QlOLptr91WAgAASoRCAAAqAsIAAj+CA//+RR/A= Date: Wed, 11 Jun 2014 18:07:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D3344D@dfweml701-chm.china.huawei.com> References: <201406101140259997043@gmail.com> <5397F469.1050503@gont.com.ar> ,<4A95BA014132FF49AE685FAB4B9F17F645D3211E@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/QySNpMCfyygGRFvPZYXljnBNu9M Cc: "Openv6@ietf.org" Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:08:21 -0000 I will get the draft out by next week.=20 Linda -----Original Message----- From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]=20 Sent: Wednesday, June 11, 2014 12:44 PM To: Linda Dunbar; fernando@gont.com.ar; Zhouqian (Cathy); xiechf01@gmail.co= m; Tina TSOU Cc: Openv6@ietf.org Subject: RE: [Openv6] About APONF drafts Hi Linda, Thanks for the suggestion!=20 Yes, I think that this use case fits very well within the scope of APONF! Will you be willing to start working and/or editing an Internet draft that = describes this use case? Best regards, Georgios ________________________________________ Van: Linda Dunbar [linda.dunbar@huawei.com] Verzonden: woensdag 11 juni 2014 18:13 Aan: Karagiannis, G. (EWI); fernando@gont.com.ar; Zhouqian (Cathy); xiechf0= 1@gmail.com; Tina TSOU CC: Openv6@ietf.org Onderwerp: RE: [Openv6] About APONF drafts How about a use case draft on Enterprise DC Applications Policy Translation= ? In ONF L4-L7 Service group, we have been working on various policies that c= an be sent to network automatically from applications. Some of those cases = are applicable to APONF BoF. Linda -----Original Message----- From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Wednesday, June 11, 2014 2:25 AM To: fernando@gont.com.ar; Zhouqian (Cathy); xiechf01@gmail.com; openv6@ietf= .org Subject: Re: [Openv6] About APONF drafts Hi Fernando, Yes, it will be great to have a use cases Internet draft that describes how= the ETSI trust models are used to solve similar problems! Can you start working and edit such an Internet draft? Best regards, Georgios > -----Original Message----- > From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Fernando=20 > Gont > Sent: woensdag 11 juni 2014 8:17 > To: Zhouqian (Cathy); xiechf01; openv6 > Subject: Re: [Openv6] About APONF drafts > > Hi, Cathy et al, > > I personally think it would be helpful that this ID indicates how=20 > other related work being carried out elsewhere (e.g. ETSI) relates to=20 > this work. For example, would it make sensible to take some of the=20 > work on trust models at ETSI to address the questions that have been rais= ed on this list? > > Thanks! > > Best regards, > Fernando > > > > > On 06/10/2014 08:48 AM, Zhouqian (Cathy) wrote: > > Hi Chongfeng, > > > > Thanks for your suggestion. Do you mean the workflow of an example=20 > > use > case? > > > > > > > > Best Regards, > > > > Cathy > > > > > > > > *From:*Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of > *xiechf01 > > *Sent:* Tuesday, June 10, 2014 11:41 AM > > *To:* openv6 > > *Subject:* [Openv6] About APONF drafts > > > > > > > > > > > > Hi, folks, > > > > > > > > I support to these 2 drafts, for they can help upper-layer=20 > > applications utilize the carrier network capabilities more=20 > > efficiently and > easily. > > One suggestion, one part to describe a typical workflow can be added=20 > > to the current the architecture draft. > > > > > > > > Chongfeng@chinatelecom > > > > -------------------------------------------------------------------- > > -- > > -- > > > > xiechf01 > > > > > > > > _______________________________________________ > > Openv6 mailing list > > Openv6@ietf.org > > https://www.ietf.org/mailman/listinfo/openv6 > > > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6 From nobody Wed Jun 11 20:59:14 2014 Return-Path: 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 151641B29BA for ; Wed, 11 Jun 2014 20:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-0AtpiFbov6 for ; Wed, 11 Jun 2014 20:59:08 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5CF1B29B2 for ; Wed, 11 Jun 2014 20:59:08 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id i57so561911yha.15 for ; Wed, 11 Jun 2014 20:59:07 -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:cc:subject :content-type:content-transfer-encoding; bh=oCGy05dh/5MYvMKYpzdgcC1jHiABr5UTh8FM3/miqKk=; b=t232jUaWO7I1ykjqdo2ECx39/MJXuNy5ZCHCOIU27TdyKwAziEdsX4un6w9MDex+jD j9Si9Znmoxs+mWHeWZFVyM22YfdzGoNsry3torBivmIrYPvIMOitv9NjOV741CyYRMdj v0dFmoOsGFup7/7H+wO1NLTk7c4xTVruI8tFmspRrGsPjK9E4mjToPsRjG2pKt7Mstob iRgsMGk/WGuiXC1QjIEabdDwZIVhEN6dZf/PWNfWblezdDU5WAL+wH4rb7BI8kpEkGv4 5t6iDx1ZBOSN2Kz6wvC8W+pokRbLFSHwm0tc+JI+VnSdZjoxjDgZV2S4ooC7bhewF5XH 0VvA== X-Received: by 10.236.204.33 with SMTP id g21mr11844184yho.92.1402545547625; Wed, 11 Jun 2014 20:59:07 -0700 (PDT) Received: from [10.71.14.162] ([64.197.173.10]) by mx.google.com with ESMTPSA id a26sm21115626yho.0.2014.06.11.20.59.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 20:59:07 -0700 (PDT) Message-ID: <53992588.9030109@gmail.com> Date: Wed, 11 Jun 2014 22:59:04 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: 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/Y-lNkIRIaCQ_ss-OEScIGaW0Pos Cc: "tsv-ads@tools.ietf.org" , Ted Lemon Subject: [Openv6] Feedback on APONF BOF request X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 03:59:11 -0000 Dear APONF BOF requesters, As the responsible AD for the APONF BOF request, I wanted to report back to you that the IESG and IAB reviewed the APONF BOF request, and decided that APONF wasn't ready for a BOF at IETF 90 in Toronto. I can tell you that both the IESG and IAB members on the call took the request very seriously. I'm thinking we talked about APONF for close to half an hour and returned to it a couple of times during the call. I have some suggestions for you, if you plan to continue to work on this proposal. I'll try to provide them in priority order. Here are the points I noted during the discussion: - First and most important, we had the sense that something like APONF has been done in the past - specifically, NSIS. So the technical feasibility isn't in question. NSIS was completed, including interoperability testing at IETF meetings, so we know it's possible to do something like this. - It would be good to perform a gap analysis on NSIS, and explain why NSIS can't be used to do what APONF wants to do. - NSIS didn't get deployed after it was completed, because most application developers weren't interested in providing information to the network ("best effort was good enough"). The concern was that if only a small percentage of applications provide this information, it will cost more for carriers to deploy it (and modify back office systems to bill for it) than carriers can make selling the service. It would be good to explain why the situation is different in 2014 (and it may be different). - Most people speaking on the call thought it would be more likely that network management applications would provide information to the network, so you might consider limiting the scope of the proposal to network management applications, rather than including end user applications as the proposal does now. - It's possible that distributed data center applications would be willing and able to take advantage of APONF, but the proposal would need to focus on those applications (rather than add them to an existing set of applications under consideration). - More generally, the proposal was considered to be "too large for a single working group", so anything else you could remove would be helpful. - Erik Nordmark asked where the trust boundaries were (is this entirely within an administrative domain, or interdomain? Does the network trust the application? Is the application controlling what the network does, or providing hints that the network would take into account, along with other inputs?). That would be helpful to explain in a bit more detail. I can also tell you that we talked about other "dynamically discovering and changing the configuration of parts of the Internet to support specified services at multiple layers using standard interfaces" proposals on the call, including AECON, ACTN, TIME, VFNCONF. (APONF got points because it was the only proposal that was aware of all the other proposals). The same concerns were raised again and again. Some members of the IAB were talking about whether an IAB workshop to resolve the questions that we asked about each specific proposal in a more general way. It would be helpful to talk to Brian Trammel (IAB) about this, in Toronto. It's also worth noting that Jari would like to find some way to make progress on at least some of these proposals. We recommended an IETF 90 side meeting of BOF proponents from as many of these proposals as makes sense, to look for commonalities and differences. I believe Ted is planning to meet with AECON requesters; if part of the conversation is making the difference between AECON and APONF more clear, perhaps talking to Ted about that meeting would be helpful. I hope this is helpful, and best wishes if you move forward with this proposal. Spencer From nobody Wed Jun 11 21:30:03 2014 Return-Path: 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 BB4721A036C for ; Wed, 11 Jun 2014 21:30:01 -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 OlN_VybxL1Sg for ; Wed, 11 Jun 2014 21:29:59 -0700 (PDT) Received: from out25-ams.mf.surf.net (out25-ams.mf.surf.net [145.0.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5381A035E for ; Wed, 11 Jun 2014 21:29:59 -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 s5C4TjM1021796; Thu, 12 Jun 2014 06:29:51 +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, 12 Jun 2014 06:29:48 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 06:29:45 +0200 From: To: , Thread-Topic: [Openv6] Feedback on APONF BOF request Thread-Index: AQHPhfKxGV0lWNRSn0Go09CkJXuUlpts3uW7 Date: Thu, 12 Jun 2014 04:29:44 +0000 Message-ID: References: <53992588.9030109@gmail.com> In-Reply-To: <53992588.9030109@gmail.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 0uMdgtK8M - 6a110b61b5f7 - 20140612 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/vY1WtJf1Fv8VeEKlAlUeZl4EZLg Cc: tsv-ads@tools.ietf.org, Ted.Lemon@nominum.com Subject: Re: [Openv6] Feedback on APONF BOF request X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 04:30:01 -0000 Dear Spencer, Thank you very much for the useful feedback! I would like to inform you that we will very much like to proceed with the = APONF activities. We will follow and try to satisfy all the IESG and IAB suggestions and reco= mmendations! Best regards, Georgios Karagiannis ________________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens Spencer Dawkins [spencerdawkin= s.ietf@gmail.com] Verzonden: donderdag 12 juni 2014 5:59 Aan: openv6@ietf.org CC: tsv-ads@tools.ietf.org; Ted Lemon Onderwerp: [Openv6] Feedback on APONF BOF request Dear APONF BOF requesters, As the responsible AD for the APONF BOF request, I wanted to report back to you that the IESG and IAB reviewed the APONF BOF request, and decided that APONF wasn't ready for a BOF at IETF 90 in Toronto. I can tell you that both the IESG and IAB members on the call took the request very seriously. I'm thinking we talked about APONF for close to half an hour and returned to it a couple of times during the call. I have some suggestions for you, if you plan to continue to work on this proposal. I'll try to provide them in priority order. Here are the points I noted during the discussion: - First and most important, we had the sense that something like APONF has been done in the past - specifically, NSIS. So the technical feasibility isn't in question. NSIS was completed, including interoperability testing at IETF meetings, so we know it's possible to do something like this. - It would be good to perform a gap analysis on NSIS, and explain why NSIS can't be used to do what APONF wants to do. - NSIS didn't get deployed after it was completed, because most application developers weren't interested in providing information to the network ("best effort was good enough"). The concern was that if only a small percentage of applications provide this information, it will cost more for carriers to deploy it (and modify back office systems to bill for it) than carriers can make selling the service. It would be good to explain why the situation is different in 2014 (and it may be different). - Most people speaking on the call thought it would be more likely that network management applications would provide information to the network, so you might consider limiting the scope of the proposal to network management applications, rather than including end user applications as the proposal does now. - It's possible that distributed data center applications would be willing and able to take advantage of APONF, but the proposal would need to focus on those applications (rather than add them to an existing set of applications under consideration). - More generally, the proposal was considered to be "too large for a single working group", so anything else you could remove would be helpful. - Erik Nordmark asked where the trust boundaries were (is this entirely within an administrative domain, or interdomain? Does the network trust the application? Is the application controlling what the network does, or providing hints that the network would take into account, along with other inputs?). That would be helpful to explain in a bit more detail. I can also tell you that we talked about other "dynamically discovering and changing the configuration of parts of the Internet to support specified services at multiple layers using standard interfaces" proposals on the call, including AECON, ACTN, TIME, VFNCONF. (APONF got points because it was the only proposal that was aware of all the other proposals). The same concerns were raised again and again. Some members of the IAB were talking about whether an IAB workshop to resolve the questions that we asked about each specific proposal in a more general way. It would be helpful to talk to Brian Trammel (IAB) about this, in Toronto. It's also worth noting that Jari would like to find some way to make progress on at least some of these proposals. We recommended an IETF 90 side meeting of BOF proponents from as many of these proposals as makes sense, to look for commonalities and differences. I believe Ted is planning to meet with AECON requesters; if part of the conversation is making the difference between AECON and APONF more clear, perhaps talking to Ted about that meeting would be helpful. I hope this is helpful, and best wishes if you move forward with this proposal. Spencer _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6= From nobody Wed Jun 11 23:30:13 2014 Return-Path: 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 46E731B29D7 for ; Wed, 11 Jun 2014 22:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 JrjDWBtcXGx3 for ; Wed, 11 Jun 2014 22:45:07 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4926E1A0375 for ; Wed, 11 Jun 2014 22:45:07 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so629105pad.10 for ; Wed, 11 Jun 2014 22:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:references:mime-version:message-id :content-type; bh=u1RM70u6Zu6Pf9iHlx/N3YBD4ELG6B+nAhFpHUpJPtE=; b=ki0iyUcmnLhV21+a/F1K8q37AazFPRjmxET+E5KuCZ+Pj8855pbWZQXwUzPNT0lbCC eeCaP+pjG4lllaYH06X/3aZccw6rnRynPWWYVPm1cc4rjmO1gSY4KXhqZ3HIkno1L5It jLNPl3vAYlk9/AH7vq1Ujp+qtrSfX7K5CvWTVoBMEfzsMLeRyLC6qyMSZE8AgMJQu6cD pf4UbtI+B/6O6yfF8J6ZKR1abZ0TTfZfdRN1E05gl2HZ9TcIC6Gj6v1a4+Y2HO0S+0nM erJkLj/Q1n0KSrSpHlkDZeBtJb6X/QrtHmbUwf7jBnpbQU6IbLpGlNmrPvFTczpDf6bd eJCA== X-Received: by 10.68.200.10 with SMTP id jo10mr10142987pbc.143.1402551906888; Wed, 11 Jun 2014 22:45:06 -0700 (PDT) Received: from xiechf-ctbri-PC ([124.127.116.138]) by mx.google.com with ESMTPSA id fk4sm39904750pab.23.2014.06.11.22.45.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jun 2014 22:45:06 -0700 (PDT) Date: Thu, 12 Jun 2014 13:45:09 +0800 From: xiechf01 To: cathy.zhou , openv6 References: <201406101140259997043@gmail.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <2014061213450617810718@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart324060022285_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/oxXc0KxDqbB4xXUYE3hHexEMfac X-Mailman-Approved-At: Wed, 11 Jun 2014 23:30:11 -0700 Subject: Re: [Openv6] About APONF drafts X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 05:45:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart324060022285_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpZZXMsICBteSBwZXJzb25hbCBvcGluaW9uIGlzIGEgd29ya2Zsb3cgdGhhdCBkZXNjcmliZSB0 aGUgdHlwaWNhbCB1c2VjYXNlIHdpbGwgbWFrZSBhcmNoaXRlY3R1cmUgbW9yZSBjb21wcmVoZW5z aXZlICBhbmQgY29udmluY2luZy4gICA6KQ0KDQoNCg0KDQp4aWVjaGYwMQ0KDQpGcm9tOiBaaG91 cWlhbiAoQ2F0aHkpDQpEYXRlOiAyMDE0LTA2LTEwIDE0OjQ4DQpUbzogeGllY2hmMDE7IG9wZW52 Ng0KU3ViamVjdDogUkU6IFtPcGVudjZdIEFib3V0IEFQT05GIGRyYWZ0cw0KSGkgQ2hvbmdmZW5n LA0KVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIERvIHlvdSBtZWFuIHRoZSB3b3JrZmxvdyBv ZiBhbiBleGFtcGxlIHVzZSBjYXNlPw0KIA0KQmVzdCBSZWdhcmRzLA0KQ2F0aHkNCiANCkZyb206 IE9wZW52NiBbbWFpbHRvOm9wZW52Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgeGll Y2hmMDENClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTAsIDIwMTQgMTE6NDEgQU0NClRvOiBvcGVudjYN ClN1YmplY3Q6IFtPcGVudjZdIEFib3V0IEFQT05GIGRyYWZ0cw0KIA0KIA0KSGksIGZvbGtzLA0K IA0KSSBzdXBwb3J0IHRvIHRoZXNlIDIgZHJhZnRzLCAgZm9yIHRoZXkgY2FuIGhlbHAgdXBwZXIt bGF5ZXIgYXBwbGljYXRpb25zIHV0aWxpemUgdGhlIGNhcnJpZXIgbmV0d29yayBjYXBhYmlsaXRp ZXMgbW9yZSBlZmZpY2llbnRseSBhbmQgZWFzaWx5LiBPbmUgc3VnZ2VzdGlvbiwgb25lIHBhcnQg dG8gZGVzY3JpYmUgYSB0eXBpY2FsIHdvcmtmbG93IGNhbiBiZSBhZGRlZCB0byB0aGUgY3VycmVu dCB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Lg0KIA0KQ2hvbmdmZW5nQGNoaW5hdGVsZWNvbQ0KDQoN Cg0KeGllY2hmMDE= ------=_001_NextPart324060022285_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
Yes,  my personal opinion is a workflow that describe = the=20 typical usecase will make architecture more comprehensive  and=20 convincing.   :)
 
xiechf01
 
Date: 2014-06-10 14:48
To: xiechf01; <= A=20 href=3D"mailto:openv6@ietf.org">openv6
Subject: RE: [Openv6] About APONF drafts

Hi=20 Chongfeng,

Thanks=20 for your suggestion. Do you mean the workflow of an example use=20 case?

 

Best=20 Regards,

Cathy

 

From:= Openv6=20 [mailto:openv6-bounces@ietf.org] On Behalf Of xiechf01
Sent:<= /B>=20 Tuesday, June 10, 2014 11:41 AM
To: openv6
Subject: [O= penv6]=20 About APONF drafts

 

 

Hi,=20 folks,

 

I support=20 to these 2 drafts,  for they can help upper-layer applications u= tilize=20 the carrier network capabilities more efficiently and easily. One suggesti= on,=20 one part to describe a typical workflow can be added to the current the=20 architecture draft.

 

Chongfeng@chinatelecom

xiechf01

------=_001_NextPart324060022285_=------ From nobody Thu Jun 12 07:35:56 2014 Return-Path: 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 D55A91B2A68 for ; Thu, 12 Jun 2014 07:35:55 -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 sJdDebIQDe1T for ; Thu, 12 Jun 2014 07:35:53 -0700 (PDT) Received: from out41-ams.mf.surf.net (out41-ams.mf.surf.net [145.0.1.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC4E1A012D for ; Thu, 12 Jun 2014 07:35:52 -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 s5CEZmB5028827; Thu, 12 Jun 2014 16:35:48 +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, 12 Jun 2014 16:35:51 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 16:35:48 +0200 From: To: Thread-Topic: APONF next steps and Doodle poll for bar BOF during IETF 90 Thread-Index: AQHPhkuHmQMfsgFnMUawpwiUc/5DpA== Date: Thu, 12 Jun 2014 14:35:46 +0000 Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 0vMdqzMT9 - f050db76cfc6 - 20140612 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/XZ8OpaCXFtESDKsBE_-HZf4ROY0 Cc: sob@harvard.edu Subject: [Openv6] APONF next steps and Doodle poll for bar BOF during IETF 90 X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 14:35:56 -0000 Hi all, Unfortunately, is our APONF BOF request not approved for IETF 90.=20 However, we received very positive and constructive feedback from the IESG = and IAB via Spencer Dowkins (AD). Currently we are studying carefully the feedback and will come back to you = with a list of actions soon. In addition to that, we would like to inform you that we are willing to org= anize a bar BOF during the IETF 90 in Toronto, in order to discuss and poss= ibly solve any issues related to the next steps that we have to take in or= der to satisfy the IESG and IAB recommendations. In order to find a suitable day and time during the IETF 90, we created a D= oodle poll, see below: http://doodle.com/hbtkqvirfyqqteiz Can you please fill in your availability dates as soon as possible and befo= re the 1st of July 2014? Kind regards, Scott Bradner & Georgios Karagiannis ________________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens Spencer Dawkins [spencerdawkin= s.ietf@gmail.com] Verzonden: donderdag 12 juni 2014 5:59 Aan: openv6@ietf.org CC: tsv-ads@tools.ietf.org; Ted Lemon Onderwerp: [Openv6] Feedback on APONF BOF request Dear APONF BOF requesters, As the responsible AD for the APONF BOF request, I wanted to report back to you that the IESG and IAB reviewed the APONF BOF request, and decided that APONF wasn't ready for a BOF at IETF 90 in Toronto. I can tell you that both the IESG and IAB members on the call took the request very seriously. I'm thinking we talked about APONF for close to half an hour and returned to it a couple of times during the call. I have some suggestions for you, if you plan to continue to work on this proposal. I'll try to provide them in priority order. Here are the points I noted during the discussion: - First and most important, we had the sense that something like APONF has been done in the past - specifically, NSIS. So the technical feasibility isn't in question. NSIS was completed, including interoperability testing at IETF meetings, so we know it's possible to do something like this. - It would be good to perform a gap analysis on NSIS, and explain why NSIS can't be used to do what APONF wants to do. - NSIS didn't get deployed after it was completed, because most application developers weren't interested in providing information to the network ("best effort was good enough"). The concern was that if only a small percentage of applications provide this information, it will cost more for carriers to deploy it (and modify back office systems to bill for it) than carriers can make selling the service. It would be good to explain why the situation is different in 2014 (and it may be different). - Most people speaking on the call thought it would be more likely that network management applications would provide information to the network, so you might consider limiting the scope of the proposal to network management applications, rather than including end user applications as the proposal does now. - It's possible that distributed data center applications would be willing and able to take advantage of APONF, but the proposal would need to focus on those applications (rather than add them to an existing set of applications under consideration). - More generally, the proposal was considered to be "too large for a single working group", so anything else you could remove would be helpful. - Erik Nordmark asked where the trust boundaries were (is this entirely within an administrative domain, or interdomain? Does the network trust the application? Is the application controlling what the network does, or providing hints that the network would take into account, along with other inputs?). That would be helpful to explain in a bit more detail. I can also tell you that we talked about other "dynamically discovering and changing the configuration of parts of the Internet to support specified services at multiple layers using standard interfaces" proposals on the call, including AECON, ACTN, TIME, VFNCONF. (APONF got points because it was the only proposal that was aware of all the other proposals). The same concerns were raised again and again. Some members of the IAB were talking about whether an IAB workshop to resolve the questions that we asked about each specific proposal in a more general way. It would be helpful to talk to Brian Trammel (IAB) about this, in Toronto. It's also worth noting that Jari would like to find some way to make progress on at least some of these proposals. We recommended an IETF 90 side meeting of BOF proponents from as many of these proposals as makes sense, to look for commonalities and differences. I believe Ted is planning to meet with AECON requesters; if part of the conversation is making the difference between AECON and APONF more clear, perhaps talking to Ted about that meeting would be helpful. I hope this is helpful, and best wishes if you move forward with this proposal. Spencer _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6= From nobody Thu Jun 12 09:43:10 2014 Return-Path: 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 1B17A1B2AA3 for ; Thu, 12 Jun 2014 09:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KXng8p6bB9n9 for ; Thu, 12 Jun 2014 09:43:04 -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 C72EA1A0880 for ; Thu, 12 Jun 2014 09:43:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII95341; Thu, 12 Jun 2014 16:43:01 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 17:43:01 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 09:42:56 -0700 From: Linda Dunbar To: Spencer Dawkins , "openv6@ietf.org" Thread-Topic: [Openv6] Feedback on APONF BOF request Thread-Index: AQHPhfLE3bIACOzwtkuUed8dGZhhDpttrB6g Date: Thu, 12 Jun 2014 16:42:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D341E4@dfweml701-chm.china.huawei.com> References: <53992588.9030109@gmail.com> In-Reply-To: <53992588.9030109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/3LRem6Egkh3UamXn7P-_FzPvaAw Cc: "tsv-ads@tools.ietf.org" , Ted Lemon Subject: Re: [Openv6] Feedback on APONF BOF request X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:43:09 -0000 Spencer,=20 Thank you very much for the feedback.=20 My comments to the IESG feedback are inserted below: -----Original Message----- From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Spencer Dawkins - First and most important, we had the sense that something like APONF has = been done in the past - specifically, NSIS. So the technical feasibility is= n't in question. NSIS was completed, including interoperability testing at = IETF meetings, so we know it's possible to do something like this. [Linda] Some of the deliverables by AEON is truly covered by NSIS charter, = (e.g. "middle box traversal protocol" by NSIS is what AEON try to do). But = APONF is quite different. I have to say that we need a better and more accu= rate name than "APONF" to describe the initiative of APONF.=20 - NSIS didn't get deployed after it was completed, because most application= developers weren't interested in providing information to the network ("be= st effort was good enough"). The concern was that if only a small percentag= e of applications provide this information, it will cost more for carriers = to deploy it (and modify back office systems to bill for it) than carriers = can make selling the service. It would be good to explain why the situation= is different in 2014 (and it may be different). [Linda] The interface addressed by APONF will be very useful by IoT, sensor= network, network services that using virtualized network functions to offe= r flexible services. Again, I agree, the use cases need to be more focused.= =20 - Most people speaking on the call thought it would be more likely that net= work management applications would provide information to the network, so y= ou might consider limiting the scope of the proposal to network management = applications, rather than including end user applications as the proposal d= oes now. [Linda] It might not be NMS, but maybe some controllers. Application to Net= work (controller) interface is much more realistic than Application to netw= ork elements interface.=20 - Erik Nordmark asked where the trust boundaries were (is this entirely wit= hin an administrative domain, or interdomain? Does the network trust the ap= plication? Is the application controlling what the network does, or providi= ng hints that the network would take into account, along with other inputs?= ). That would be helpful to explain in a bit more detail. [Linda] absolutely. The security will be a big part of this initiative.=20 Linda _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6 From nobody Sat Jun 14 07:11:44 2014 Return-Path: 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 17B1F1B28F1 for ; Sat, 14 Jun 2014 07:11:42 -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 SUQsN8_V_OZ2 for ; Sat, 14 Jun 2014 07:11:34 -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 AE50B1B2853 for ; Sat, 14 Jun 2014 07:11:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFK25341; Sat, 14 Jun 2014 14:11:31 +0000 (GMT) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 14 Jun 2014 15:11:30 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.210]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sat, 14 Jun 2014 22:11:23 +0800 From: Tina TSOU To: "karagian@cs.utwente.nl" , "jsaldana@unizar.es" , "Openv6@ietf.org" Thread-Topic: [Openv6] Is there a draft charter for APONF? Thread-Index: Ac+D9qNFruvdoEliTFauT0nZdN8okwAEVOrrAB1I+KAA11qzdg== Date: Sat, 14 Jun 2014 14:11:23 +0000 Message-ID: <6344BC5E-9EF0-45CD-9664-91CD60193E18@huawei.com> References: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6344BC5E9EF045CD966491CD60193E18huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/Or3XYIffq6Q-FRvM0XlPUge2rMo Subject: Re: [Openv6] Is there a draft charter for APONF? X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 14:11:42 -0000 --_000_6344BC5E9EF045CD966491CD60193E18huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all, Below is 2nd version of the charter based on all the feedback, many things = are removed. Comments are very welcome. ---- APONF (Application-based Policy for Network Functions) charter Description of Working Group: Currently, there are network management applications that have specific dem= ands on a communication network. For example, some specialized applications= , like virtual network function services and Distributed Data Center Applic= ation, may need to *dynamically manage* the network infrastructure, and oth= er specialized applications, like streaming applications and Internet of Th= ings (IoT) applications, may require to configure the network according to = their demands. If possible, a network management application may require fr= om the communication network to apply the following different network manag= ement capabilities, such as: =95 dynamically (re)configure a network entity =95 accelerate the service deployment =95 getting better network services from transport network =95 providing better user experience The network management application=92s demands on a communication network a= re different, but there are several demands that may be similar, such as di= fferent Web Surfing/Browsing applications, IoT applications, virtual networ= k function services, Distributed Data Center Application, which can be grou= ped/classified together. The classified network management application dema= nds on a communication network can be presented and modeled as classified n= etwork management application-based policies. A set of network management a= pplication-based policy models may be needed for auto-mapping of network ma= nagement application=92s demands to existing network management policies. T= his will allow network management applications to use the network capabilit= ies in a more accurate and efficient way. The definition of these network management policies is out of the APONF sco= pe. Examples of such network management policies that are considered by APONF a= re the following: =95 Manage dynamically network semantics (supported by e.g., SN= MP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Functi= on Virtualization configuration) BOF activity) =95 Orchestrate dynamically virtualized functions (supported by= e.g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF = activity, Abstraction and Control of Transport Networks (ACTN) BOF activity= ) =95 Log the traffic (supported by e.g., I2RS WG, FORCES WG, App= lication Enabled Collaborative Network (AECN) BOF activity) =95 Set the traffic, e.g., encapsulation/decapsulation (support= ed for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Coll= aborative Network (AECN) BOF activity) These network management application-based policy models can meet the netwo= rk management application=92s demands on the communication network and map = these demands to network management policies that can be understood by the = communication network. The main goal of APONF is to specify the network management application-bas= ed policy protocol(s), mechanisms and models required by network managemen= t applications to easily, accurately, and efficiently select and use the av= ailable communication network capabilities, i.e., network management polici= es. The users of the APONF are network management applications requests that ha= ve specific demands on a communication network. Work items related to APONF include: =95 specify the APONF groups/classes of application policies an= d models =95 provide mechanisms that can accurately map and store the AP= ONF groups/classes of application policies and models into existing network= management policies. =95 specify the protocol and the required mechanisms that are a= ble to support the communication between the network management applicatio= ns and the ABPD entity that maintains the groups/classes of application pol= icies and models. =95 provide the means to use existing network management protoc= ols and mechanisms to enforce the network management application policies = (via the associated network management policies) into network entities. Suc= h protocols and mechanism are supported for/by e.g., SNMP/MIB, COPS-PR/PIB,= NetCon/Yang, Web Services/MIB, nfvcon activity, SCF WG, ACT activity, I2RS= WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN,= MPLS. =95 provide authentication and authorization mechanisms to supp= ort the communication between the Network Management Application and the AB= PD entity. =95 provide privacy support for the end users running the appli= cations that make use of the APONF protocol and mechanisms. Initially, the APONF work will focus on the follow aspects: =95 high-level architecture =95 Solution requirements =95 a set of application based policy models for different clas= ses of applications =95 a set of use cases =95 analysis of existing protocols that can be reused in the ar= chitecture Milestones: =95 November 2014 Submit I-D 'Use cases' to the IESG for consid= eration as an Informational RFC. =95 February 2015 =96 Submit I-D 'Solution Requirements' to the= IESG for consideration as an Informational RFC. =95 March 2015 Submit I-D 'High level Architecture' to the IESG= for consideration as an Informational RFC.- =95 July 2015 Submit I-D 'Gap Analysis' to the IESG for conside= ration as an Informational RFC.- =95 Jul y2015 - Evaluate the need for further work based on the= identified gaps and revise the milestones and/or the charter of the group ----- Thank you, Tina On Jun 10, 2014, at 4:00 PM, "Tina TSOU" > wrote: Dear all, Here is the first cut of a draft charter for APONF. APONF (Application-based Policy for Network Functions) charter Description of Working Group: Currently, there are transport applications that have specific demands on a= communication network. For example, some specialized applications, like vi= rtual network function services, may need to *dynamically manage* the netwo= rk infrastructure, and other specialized applications, like streaming appli= cations and Internet of Things (IoT) applications, may require from the net= work to treat their traffic according to their demands. If possible, a spec= ialized application may require from the communication network to apply the= following different network management and/or traffic capabilities, such = as: =95 dynamically (re)configure a network entity =95 accelerate the service deployment =95 getting better network services from transport network =95 providing better user experience The application=92s demands on a communication network are different, but t= here are several specialized application demands that may be similar, such = as different IoT applications, virtual network function services, which can= be grouped/classified together. The classified application demands on a co= mmunication network can be presented and modeled as classified application-= based policies. A set of application-based policy models may be needed for = auto-mapping of application=92s demands to existing network management and/= or traffic policies. This will allow applications to use the network capabi= lities in a more accurate and efficient way. The definition of these network management and traffic policies is out of t= he APONF scope. Examples of such network management and traffic policies that are considere= d by APONF are the following: =95 Manage dynamically network semantics (supported by e.g., SN= MP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Functi= on Virtualization configuration) BOF activity) =95 Orchestrate dynamically virtualized functions (supported by= e.g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF = activity, Abstraction and Control of Transport Networks (ACTN) BOF activity= ) =95 Permit/Block/Redirect the traffic (supported by e.g., I2RS = WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activit= y) =95 Log the traffic (supported by e.g., I2RS WG, FORCES WG, App= lication Enabled Collaborative Network (AECN) BOF activity) =95 Copy the traffic, e.g., multicast (supported by e.g.,I2RS W= G, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity =95 Set the traffic, e.g., encapsulation/decapsulation (support= ed for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Coll= aborative Network (AECN) BOF activity) =95 Mark the traffic (supported for/by e.g., Intserv, Diffserv,= PCN, MPLS) These application-based policy models can meet the specialized application= =92s demands on the communication network and map these demands to network = management and traffic policies that can be understood by the communication= network. The main goal of APONF is to specify the application-based policy protocol(= s), mechanisms and models required by transport applications to easily, ac= curately, and efficiently select and use the available communication networ= k capabilities, i.e., network management and/or traffic policies. The users of the APONF may be the network management applications, or (BOF)= TAPS (Transport Services) requests that have specific demands on a communi= cation network. Work items related to APONF include: =95 specify the APONF groups/classes of application policies an= d models =95 provide mechanisms that can accurately map and store the AP= ONF groups/classes of application policies and models into existing network= management and traffic policies. =95 specify the protocol and the required mechanisms that are a= ble to support the communication between the transport applications and th= e ABPD entity that maintains the groups/classes of application policies and= models. =95 provide the means to use existing network management and/or= traffic conditioning protocols and mechanisms to enforce the application = policies (via the associated network management and traffic policies) into = network entities. Such protocols and mechanism are supported for/by e.g., S= NMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon activity, SCF W= G, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Int= serv, Diffsrerv, PCN, MPLS. =95 provide authentication and authorization mechanisms to supp= ort the communication between the Transport Application and the ABPD entity= . =95 provide privacy support for the end users running the appli= cations that make use of the APONF protocol and mechanisms. Initially, the APONF work will focus on the follow aspects: =95 high-level architecture =95 Solution requirements =95 a set of application based policy models for different clas= ses of applications =95 a set of use cases =95 analysis of existing protocols that can be reused in the ar= chitecture Milestones: =95 November 2014 Submit I-D 'Use cases' to the IESG for consid= eration as an Informational RFC. =95 February 2015 =96 Submit I-D 'Solution Requirements' to the= IESG for consideration as an Informational RFC. =95 March 2015 Submit I-D 'High level Architecture' to the IESG= for consideration as an Informational RFC.- =95 July 2015 Submit I-D 'Gap Analysis' to the IESG for conside= ration as an Informational RFC.- =95 Jul y2015 - Evaluate the need for further work based on the= identified gaps and revise the milestones and/or the charter of the group Thank you, Tina From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Tuesday, June 10, 2014 1:28 AM To: jsaldana@unizar.es; Openv6@ietf.org Subject: Re: [Openv6] Is there a draft charter for APONF? Hi Jose, Thanks for the comments! Yes we are planning to create a APONF BOF charter soon! Best regards, Georgios ________________________________ Van: Openv6 [openv6-bounces@ietf.org] namen= s Jose Saldana [jsaldana@unizar.es] Verzonden: maandag 9 juni 2014 17:26 Aan: Openv6@ietf.org Onderwerp: [Openv6] Is there a draft charter for APONF? Hi, I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac= /wiki. Is there a draft charter somewhere? In case not, I would suggest to write a= first version and send it to the list. It would be somewhat similar to the= BoF summary, but it would also include the goals and milestones, deliverab= les of the potential WG, interactions with other WGs, etc. Best regards, Jose Saldana --_000_6344BC5E9EF045CD966491CD60193E18huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear all,

Below is 2nd version of the = charter based on all the feedback, many things are removed.

Comments are very welcome.

----

APONF (Application-based Policy for Network Functions) charte= r

 

Description of Working Group:

 

Currently, there are network management applications that have s= pecific demands on a communication network. For example, some specialized applications, like virtual network function = services and Distributed Data Center Application, may need to *dynamically = manage* the network infrastructure, and other specialized applications, lik= e streaming applications and Internet of Things (IoT) applications, may require to configure the network accordi= ng to their demands. If possible, a network management application may requ= ire from the communication network to apply the following different network= management capabilities, such as:

=95          &= nbsp;  dynamically (re)configure a network entity

=95          &= nbsp;  accelerate the service deployment

=95          &= nbsp;  getting better network services from transport network

=95          &= nbsp;  providing better user experience

 

The network management application=92s demands on a communicatio= n network are different, but there are several demands that may be similar, such as different Web Surfing/Browsing applic= ations, IoT applications, virtual network function services, Distributed Da= ta Center Application, which can be grouped/classified together. The classi= fied network management application demands on a communication network can be presented and modeled as classif= ied network management application-based policies. A set of network managem= ent application-based policy models may be needed for auto-mapping of netwo= rk management application=92s demands to existing network management policies. This will allow network managemen= t applications to use the network capabilities in a more accurate and effic= ient way.

 

The definition of these network management policies is out of th= e APONF scope.

 

Examples of such network management policies that are considered= by APONF are the following:

 

=95          &= nbsp;  Manage dynamically network semantics (supported by e.g., SNMP/M= IB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function Virtualization configuration) = BOF activity)

=95          &= nbsp;  Orchestrate dynamically virtualized functions (supported by e.g= ., SCF WG, nfvconf (Network Function Virtualization configuration) BOF activity, Abstraction and Contr= ol of Transport Networks (ACTN) BOF activity)

=95          &= nbsp;  Log the traffic (supported by e.g., I2RS WG, FORCES WG, Applica= tion Enabled Collaborative Network (AECN) BOF activity)

=95          &= nbsp;  Set the traffic, e.g., encapsulation/decapsulation (supported f= or/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF a= ctivity)

 

These network management application-based policy models can mee= t the network management application=92s demands on the communication network and map these demands to network management p= olicies that can be understood by the communication network.

 

The main goal of APONF is to specify the network management appl= ication-based policy protocol(s), mechanisms and models required  by network management applications to easily, ac= curately, and efficiently select and use the available communication networ= k capabilities, i.e., network management policies.=

 

The users of the APONF are network management applications reque= sts that have specific demands on a communication network.

 

Work items related to APONF include:

=95          &= nbsp;  specify the APONF groups/classes of application policies and mo= dels

=95          &= nbsp;  provide mechanisms that can accurately map and store the APONF = groups/classes of application policies and models into existing network management policies.<= /span>

=95          &= nbsp;  specify the protocol and the required mechanisms that are able&= nbsp; to support the communication between the network management applications and the ABPD entity that maint= ains the groups/classes of application policies and models.

=95          &= nbsp;  provide the means to use existing network management protocols = and mechanisms to enforce the  network management application policies (via the associated network manage= ment policies) into network entities. Such protocols and mechanism are supp= orted for/by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nf= vcon activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv,= PCN, MPLS.

=95          &= nbsp;  provide authentication and authorization mechanisms to support = the communication between the Network Management Application and the ABPD entity.

=95          &= nbsp;  provide privacy support for the end users running the applicati= ons that make use of the APONF protocol and mechanisms.

 

Initially, the APONF work will focus on the follow aspects:=

=95          &= nbsp;  high-level architecture

=95          &= nbsp;  Solution requirements

=95          &= nbsp;  a set of application based policy models for different classes = of applications

=95          &= nbsp;  a set of use cases

=95          &= nbsp;  analysis of existing protocols that can be reused in the archit= ecture

 

Milestones:

=95          &= nbsp;  November 2014 Submit I-D 'Use cases' to the IESG for considerat= ion as an Informational RFC.

=95          &= nbsp;  February 2015 =96 Submit I-D 'Solution Requirements' to the IES= G for consideration as an Informational RFC.

=95          &= nbsp;  March 2015 Submit I-D 'High level Architecture' to the IESG for= consideration as an Informational RFC.-

=95          &= nbsp;  July 2015 Submit I-D 'Gap Analysis' to the IESG for considerati= on as an Informational RFC.-

=95          &= nbsp;  Jul y2015 - Evaluate the need for further work based on the ide= ntified gaps and revise the milestones and/or the charter of the group

-----



Thank you,
Tina

On Jun 10, 2014, at 4:00 PM, "Tina TSOU" <Tina.Tsou.Zouting@huawei.com> wrote:

Dear all,

 

Here is the first cut = of a draft charter for APONF.

 

APONF (Application-= based Policy for Network Functions) charter

 

Description of Working= Group:

 

Currently, there are t= ransport applications that have specific demands on a communication network= . For example, some specialized applications, like virtual network function= services, may need to *dynamically manage* the network infrastructure, and other specialized applications, li= ke streaming applications and Internet of Things (IoT) applications, may re= quire from the network to treat their traffic according to their demands. I= f possible, a specialized application may require from the communication network to apply the following differen= t network management and/or traffic  capabilities, such as:=

=95   &= nbsp;         dynamically (re)confi= gure a network entity

=95   &= nbsp;         accelerate the servic= e deployment

=95   &= nbsp;         getting better networ= k services from transport network

=95   &= nbsp;         providing better user= experience

 

The application=92s de= mands on a communication network are different, but there are several speci= alized application demands that may be similar, such as different IoT appli= cations, virtual network function services, which can be grouped/classified together. The classified application deman= ds on a communication network can be presented and modeled as classified ap= plication-based policies. A set of application-based policy models may be n= eeded for auto-mapping of application=92s demands to existing network management and/or traffic policies. This will = allow applications to use the network capabilities in a more accurate and e= fficient way.

 

The definition of thes= e network management and traffic policies is out of the APONF scope.

 

Examples of such netwo= rk management and traffic policies that are considered by APONF are the fol= lowing:

 

=95   &= nbsp;         Manage dynamically ne= twork semantics (supported by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web= Services/MIB, nfvconf (Network Function Virtualization configuration) BOF = activity)

=95   &= nbsp;         Orchestrate dynamical= ly virtualized functions (supported by e.g., SCF WG, nfvconf (Network Funct= ion Virtualization configuration) BOF activity, Abstraction and Control of = Transport Networks (ACTN) BOF activity)

=95   &= nbsp;         Permit/Block/Redirect= the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enabled Co= llaborative Network (AECN) BOF activity)

=95   &= nbsp;         Log the traffic (supp= orted by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Networ= k (AECN) BOF activity)

=95   &= nbsp;         Copy the traffic, e.g= ., multicast (supported by e.g.,I2RS WG, FORCES WG, Application Enabled Col= laborative Network (AECN) BOF activity

=95   &= nbsp;         Set the traffic, e.g.= , encapsulation/decapsulation (supported for/by e.g., NAT, Firewall, I2RS W= G, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity= )

=95   &= nbsp;         Mark the traffic (sup= ported for/by e.g., Intserv, Diffserv, PCN, MPLS)

 

These application-base= d policy models can meet the specialized application=92s demands on the com= munication network and map these demands to network management and traffic = policies that can be understood by the communication network.

 

The main goal of APONF= is to specify the application-based policy protocol(s), mechanisms and mod= els required  by transport applications to easily, accurately, and eff= iciently select and use the available communication network capabilities, i.e., network management and/or traffic policies.

 

The users of the APONF= may be the network management applications, or (BOF) TAPS (Transport Servi= ces) requests that have specific demands on a communication network.

 

Work items related to = APONF include:

=95   &= nbsp;         specify the APONF gro= ups/classes of application policies and models

=95   &= nbsp;         provide mechanisms th= at can accurately map and store the APONF groups/classes of application pol= icies and models into existing network management and traffic policies.

=95   &= nbsp;         specify the protocol = and the required mechanisms that are able  to support the communicatio= n between the transport applications and the ABPD entity that maintains the= groups/classes of application policies and models.

=95   &= nbsp;         provide the means to = use existing network management and/or traffic conditioning protocols and m= echanisms to enforce the  application policies (via the associated net= work management and traffic policies) into network entities. Such protocols and mechanism are supporte= d for/by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon= activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NA= T, Firewall, Intserv, Diffsrerv, PCN, MPLS.

=95   &= nbsp;         provide authenticatio= n and authorization mechanisms to support the communication between the Tra= nsport Application and the ABPD entity.

=95   &= nbsp;         provide privacy suppo= rt for the end users running the applications that make use of the APONF pr= otocol and mechanisms.

 

Initially, the APONF w= ork will focus on the follow aspects:

=95   &= nbsp;         high-level architectu= re

=95   &= nbsp;         Solution requirements=

=95   &= nbsp;         a set of application = based policy models for different classes of applications=

=95   &= nbsp;         a set of use cases

=95   &= nbsp;         analysis of existing = protocols that can be reused in the architecture

 

Milestones:

=95   &= nbsp;         November 2014 Submit = I-D 'Use cases' to the IESG for consideration as an Informational RFC.=

=95   &= nbsp;         February 2015 =96 Sub= mit I-D 'Solution Requirements' to the IESG for consideration as an Informa= tional RFC.

=95   &= nbsp;         March 2015 Submit I-D= 'High level Architecture' to the IESG for consideration as an Informationa= l RFC.-

=95   &= nbsp;         July 2015 Submit I-D = 'Gap Analysis' to the IESG for consideration as an Informational RFC.-

=95   &= nbsp;         Jul y2015 - Evaluate = the need for further work based on the identified gaps and revise the miles= tones and/or the charter of the group

 

 

Thank you,<= /span>

Tina=

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.u= twente.nl
Sent: Tuesday, June 10, 2014 1:28 AM
To: jsaldana@unizar.es; Openv6@ietf.org
Subject: Re: [Openv6] Is there a draft charter for APONF?=

 

Hi Jose,

 <= /o:p>

 <= /o:p>

Thanks for t= he comments!

Yes we are p= lanning to create a APONF BOF charter soon!

 <= /o:p>

Best regards= ,

Georgios

 <= /o:p>

Van: Openv= 6 [openv6-bounces@ietf.org] namens Jose Saldana [jsaldana@unizar= .es]
Verzonden: maandag 9 juni 2014 17:26
Aan: Openv6@ietf.org
Onderwerp: [Openv6] Is there a draft charter for APONF?

Hi,

 <= /o:p>

I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac/wiki.

 <= /o:p>

Is there a draft charter somewhere? In case = not, I would suggest to write a first version and send it to the list. It w= ould be somewhat similar to the BoF summary, but it would also include the go= als and milestones, deliverables of the potential WG, interactions with oth= er WGs, etc.

 <= /o:p>

Best regards,

 <= /o:p>

Jose Saldana

 <= /o:p>

--_000_6344BC5E9EF045CD966491CD60193E18huaweicom_-- From nobody Wed Jun 18 23:40:34 2014 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 06:40:33 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434EXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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=92s goal here is to create an abstracted view of the network, so th= at you=92re programming the abstraction, rather than manipulating individua= l devices. That way, you can write software that programs an arbitrary netw= ork.", cited from: http://www.sdncentral.com/news/google-open-source-help-policy-based-sdn/201= 4/06/ This vision can be realised within the IETF as follows: The abstract view of the network can be realised by using the Service Funct= ion Path (SFP), specified by the IETF SFC WG. In adition to this, a way is needed to provide the SFP network view to appl= ication developers, such that the application developer can use this SFP du= ring the development, but also runtime phases, such that the application ca= n 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 an= d 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 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434EXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Dear all,

 

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

 

This example is based on how t= he view of google on application based policy could be realised in the cont= ext of IETF.

 

The main goal of application b= ased policy according to google is:

 

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

 

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

 

This vision can be realised wi= thin the IETF as follows:

 

The abstract view of the netwo= rk can be realised by using the Service Function Path (SFP), specified by t= he IETF SFC WG.

 

In adition to this, a way is n= eeded 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 applica= tion can utilize the network configuration and resources in the most optimu= m way.

 

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

 

What APONF can do is the follo= wing (scope of APONF):

 

o) monitor and verify the fres= hness of the Service Function Path (SFP)

 

o) distribute the SFP to netwo= rk management applications (OSS applications). Note that a network manageme= nt application are Operational Support System (OSS) applications
that help a communications service provider to monitor, control, analyze an= d manage a communication network.

 

o) any modifications done by n= etwork management applications on an SFP are communicated to the network ma= nagement system

 

o) The network management syst= em needs to use the updated SFP and implement the possible configuration ch= anges! This action is out of the APONF scope.

 

Comments are very much appreci= ated!


Best regards,
Georgios Karagiannis

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F48D434EXMBX23adutwent_-- From nobody Mon Jun 23 22:51:45 2014 Return-Path: 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 0C38A1B2847 for ; Mon, 23 Jun 2014 22:51:43 -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 nRw22p2RT37c for ; Mon, 23 Jun 2014 22:51:40 -0700 (PDT) Received: from out42-ams.mf.surf.net (out42-ams.mf.surf.net [145.0.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2144A1B283A for ; Mon, 23 Jun 2014 22:51:39 -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 s5O5pb9o006257 for ; Tue, 24 Jun 2014 07:51:37 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 24 Jun 2014 07:51:38 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Tue, 24 Jun 2014 07:51:36 +0200 From: To: Thread-Topic: APONF bar BOF agenda proposal Thread-Index: AQHPj3BbVcfOAJel3UyTOvCXbiV1gA== Date: Tue, 24 Jun 2014 05:51:35 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.224.118.204] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4941DFEXMBX23adutwent_" 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: 0vMi5PBcq - 02d1e46bf828 - 20140624 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/yv6bAvSCm4B3MvfizmJC3ufht80 Subject: [Openv6] APONF bar BOF agenda proposal X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 05:51:43 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4941DFEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Below you can find a proposal for the APONF bar BOF agenda. Please note that we have not yet chosen a a suitable day and time for the A= PONF bar BOF. The reason for this is that the APONF doodle poll has not yet closed! The closing date is the 1st of July! If you have not yet filled in the doodle poll, can you please fill in your = availability time, following the below URL? http://doodle.com/hbtkqvirfyqqteiz If you have any comments, or if you would like to add more agenda points to= the agenda, please let us know! Proposed agenda items APONF bar BOF =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D o) briefly present APONF use cases, o) problem statement o) what is in the scope and what is out of the scope of APONF o) what are the relations with other IETF WGs and available BOF description= s o) what are the expected deliverables o) what are the next steps Best regards, Scott Bradner and Georgios Karagiannis --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4941DFEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Below you can find a proposal for the APONF bar BOF agenda.

 

Please note that we have not yet chosen a a suitable day and time for th= e APONF bar BOF.

 

The reason for this is that the APONF doodle poll has not yet closed!

 

The closing date is the 1st of July!

 

If you have not yet filled in the doodle poll, can you please fill in yo= ur availability time, following the below URL?

 

http://= doodle.com/hbtkqvirfyqqteiz

 

If you have any comments, or if you would like to add more agenda points= to the agenda, please let us know!

 

Proposed agenda items APONF bar BOF

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

o) briefly present APONF use cases,


o) problem statement

 

o) what is in the scope and what is out of the scope of APONF


o) what are the relations with other IETF WGs and available BOF description= s

 

o) what are the expected deliverables

o) what are the next steps

 

Best regards,

Scott Bradner and Georgios Karagiannis

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4941DFEXMBX23adutwent_-- From nobody Wed Jun 25 01:12:37 2014 Return-Path: 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 74C5B1B2B0B for ; Wed, 25 Jun 2014 01:12:31 -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 1Su1XctxGsNF for ; Wed, 25 Jun 2014 01:12:20 -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 D171E1B2AF2 for ; Wed, 25 Jun 2014 01:12:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJF12679; Wed, 25 Jun 2014 08:12:16 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 09:12:13 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.118]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 16:12:09 +0800 From: "Liushucheng (Will)" To: "karagian@cs.utwente.nl" , "openv6@ietf.org" Thread-Topic: APONF bar BOF agenda proposal Thread-Index: AQHPj3BbVcfOAJel3UyTOvCXbiV1gJuBesng Date: Wed, 25 Jun 2014 08:12:08 +0000 Message-ID: References: In-Reply-To: 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_C9B5F12337F6F841B35C404CF0554ACB5FF1A7AASZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/OG2Jp5-O_v3_3Rwh7QYVFdKeySA Subject: Re: [Openv6] APONF bar BOF agenda proposal X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 08:12:33 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF1A7AASZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Georgios, You may consider to add an approximate slot for each part. Regards, Will (Shucheng LIU) From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Tuesday, June 24, 2014 1:52 PM To: openv6@ietf.org Subject: [Openv6] APONF bar BOF agenda proposal Dear all, Below you can find a proposal for the APONF bar BOF agenda. Please note that we have not yet chosen a a suitable day and time for the A= PONF bar BOF. The reason for this is that the APONF doodle poll has not yet closed! The closing date is the 1st of July! If you have not yet filled in the doodle poll, can you please fill in your = availability time, following the below URL? http://doodle.com/hbtkqvirfyqqteiz If you have any comments, or if you would like to add more agenda points to= the agenda, please let us know! Proposed agenda items APONF bar BOF =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D o) briefly present APONF use cases, o) problem statement o) what is in the scope and what is out of the scope of APONF o) what are the relations with other IETF WGs and available BOF description= s o) what are the expected deliverables o) what are the next steps Best regards, Scott Bradner and Georgios Karagiannis --_000_C9B5F12337F6F841B35C404CF0554ACB5FF1A7AASZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Georgios,

You may consider to add a= n approximate slot for each part.

Regards,

Will (Shucheng LIU)

From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Tuesday, June 24, 2014 1:52 PM
To: openv6@ietf.org
Subject: [Openv6] APONF bar BOF agenda proposal

 

Dear all,

 

Below you can find a proposal for the APONF bar = BOF agenda.

 

Please note that we have not yet chosen a a suit= able day and time for the APONF bar BOF.

 

The reason for this is that the APONF doodle pol= l has not yet closed!

 

The closing date is the 1st of July!<= /span>

 

If you have not yet filled in the doodle poll, c= an you please fill in your availability time, following the below URL?

 

http://doodle.com/hbtkqvirfyqqteiz

 

If you have any comments, or if you would like t= o add more agenda points to the agenda, please let us know!

 

Proposed agenda items APONF bar BOF

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

o) briefly present APONF use cases,


o) problem statement

 

o) what is in the scope and what is out of the s= cope of APONF


o) what are the relations with other IETF WGs and available BOF description= s

 

o) what are the expected deliverables=

o) what are the next steps

 

Best regards,

Scott Bradner and Georgios Karagiannis

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF1A7AASZXEMA509MBSchi_-- From nobody Wed Jun 25 03:05:09 2014 Return-Path: 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 2570B1B2B42 for ; Wed, 25 Jun 2014 03:05:08 -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 NF_f-ykX_dXm for ; Wed, 25 Jun 2014 03:05:00 -0700 (PDT) Received: from out69-ams.mf.surf.net (out69-ams.mf.surf.net [145.0.1.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB6D1B2B2B for ; Wed, 25 Jun 2014 03:04:59 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5PA4nXH001061; Wed, 25 Jun 2014 12:04:52 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 25 Jun 2014 12:04:55 +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; Wed, 25 Jun 2014 12:04:51 +0200 From: To: , Thread-Topic: APONF bar BOF agenda proposal Thread-Index: AQHPj3BbVcfOAJel3UyTOvCXbiV1gJuBesnggAAgAK0= Date: Wed, 25 Jun 2014 10:04:50 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [95.224.118.204] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F49552CEXMBX23adutwent_" 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.48; 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: 0bMiy4QeE - cd1793414f33 - 20140625 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/RtVSl490zrmmZ55TgJ9KGyF1xQ8 Subject: Re: [Openv6] APONF bar BOF agenda proposal X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:05:08 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F49552CEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Will, Thank you very much! We will do that! Best regards, Georgios ________________________________ Van: Liushucheng (Will) [liushucheng@huawei.com] Verzonden: woensdag 25 juni 2014 10:12 Aan: Karagiannis, G. (EWI); openv6@ietf.org Onderwerp: RE: APONF bar BOF agenda proposal Hi Georgios, You may consider to add an approximate slot for each part. Regards, Will (Shucheng LIU) From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Tuesday, June 24, 2014 1:52 PM To: openv6@ietf.org Subject: [Openv6] APONF bar BOF agenda proposal Dear all, Below you can find a proposal for the APONF bar BOF agenda. Please note that we have not yet chosen a a suitable day and time for the A= PONF bar BOF. The reason for this is that the APONF doodle poll has not yet closed! The closing date is the 1st of July! If you have not yet filled in the doodle poll, can you please fill in your = availability time, following the below URL? http://doodle.com/hbtkqvirfyqqteiz If you have any comments, or if you would like to add more agenda points to= the agenda, please let us know! Proposed agenda items APONF bar BOF =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D o) briefly present APONF use cases, o) problem statement o) what is in the scope and what is out of the scope of APONF o) what are the relations with other IETF WGs and available BOF description= s o) what are the expected deliverables o) what are the next steps Best regards, Scott Bradner and Georgios Karagiannis --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F49552CEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Will,

 

Thank you very much!

 

We will do that!

 

Best regards,

Georgios

 

Van: Liushucheng (Will) [liushucheng@huawe= i.com]
Verzonden: woensdag 25 juni 2014 10:12
Aan: Karagiannis, G. (EWI); openv6@ietf.org
Onderwerp: RE: APONF bar BOF agenda proposal

Hi Georgios,

You may consider to add an approximate slo= t for each part.

Regards,

Will (Shuche= ng LIU)

From: Openv6 [mailto:o= penv6-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Tuesday, June 24, 2014 1:52 PM
To: openv6@ietf.org
Subject: [Openv6] APONF bar BOF agenda proposal

 

Dear all,

 

Below you can find a proposal for the APONF bar BOF agenda.

 

Please note that we have not yet chosen a a suitable day and time= for the APONF bar BOF.

 

The reason for this is that the APONF doodle poll has not yet clo= sed!

 

The closing date is the 1st of July!

 

If you have not yet filled in the doodle poll, can you please fil= l in your availability time, following the below URL?

 

= http://doodle.com/hbtkqvirfyqqteiz

 

If you have any comments, or if you would like to add more agenda= points to the agenda, please let us know!

 

Proposed agenda items APONF bar BOF

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

o) briefly present APONF use cases,


o) problem statement

 

o) what is in the scope and what is out of the scope of APONF


o) what are the relations with other IETF WGs and available BOF description= s

 

o) what are the expected deliverables

o) what are the next steps

 

Best regards,

Scott Bradner and Georgios Karagiannis

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F49552CEXMBX23adutwent_-- From nobody Sat Jun 28 03:35:52 2014 Return-Path: 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 BD2431A0340 for ; Sat, 28 Jun 2014 03:35:49 -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 s1GQJl7P6bdM for ; Sat, 28 Jun 2014 03:35:47 -0700 (PDT) Received: from out67-ams.mf.surf.net (out67-ams.mf.surf.net [145.0.1.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9FA1A033B for ; Sat, 28 Jun 2014 03:35:45 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5SAZXcn017808; Sat, 28 Jun 2014 12:35:33 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 28 Jun 2014 12:35:40 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Sat, 28 Jun 2014 12:35:32 +0200 From: To: Thread-Topic: [Openv6] About APONF drafts (regarding your comment on security) Thread-Index: AQHPkryvdUF4vzbzZUu2OTjHyjgvQg== Date: Sat, 28 Jun 2014 10:35:31 +0000 Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.48; 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: 0bMjKzxBd - bdc1349d1e2e - 20140628 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/3UnivOv1_YaZpSCC2pBKu2p1h5w Cc: cathy.zhou@huawei.com, openv6@ietf.org, xiechf01@gmail.com Subject: Re: [Openv6] About APONF drafts (regarding your comment on security) X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 10:35:49 -0000 Dear Fernando, In the below email you mentioned that the ID indicates how other related work being carried out elsewhere (e.g. ETSI) relates to this work. Do you want to provide a use case in the area of APONF security support? Please note that your comment will be supported by including the following = text in the Security Considerations section: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Security Considerations Security is a key aspect of any protocol that allows state installation and extracting of detailed configuration states. More investigation remains to fully define the security requirements, such as authorization and authentication levels. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best regards, Georgios ________________________________________ Van: Openv6 [openv6-bounces@ietf.org] namens Fernando Gont [fernando@gont.c= om.ar] Verzonden: woensdag 11 juni 2014 8:17 Aan: Zhouqian (Cathy); xiechf01; openv6 Onderwerp: Re: [Openv6] About APONF drafts Hi, Cathy et al, I personally think it would be helpful that this ID indicates how other related work being carried out elsewhere (e.g. ETSI) relates to this work. For example, would it make sensible to take some of the work on trust models at ETSI to address the questions that have been raised on this list? Thanks! Best regards, Fernando On 06/10/2014 08:48 AM, Zhouqian (Cathy) wrote: > Hi Chongfeng, > > Thanks for your suggestion. Do you mean the workflow of an example use ca= se? > > > > Best Regards, > > Cathy > > > > *From:*Openv6 [mailto:openv6-bounces@ietf.org] *On Behalf Of *xiechf01 > *Sent:* Tuesday, June 10, 2014 11:41 AM > *To:* openv6 > *Subject:* [Openv6] About APONF drafts > > > > > > Hi, folks, > > > > I support to these 2 drafts, for they can help upper-layer applications > utilize the carrier network capabilities more efficiently and easily. > One suggestion, one part to describe a typical workflow can be added to > the current the architecture draft. > > > > Chongfeng@chinatelecom > > ------------------------------------------------------------------------ > > xiechf01 > > > > _______________________________________________ > Openv6 mailing list > Openv6@ietf.org > https://www.ietf.org/mailman/listinfo/openv6 > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Openv6 mailing list Openv6@ietf.org https://www.ietf.org/mailman/listinfo/openv6= From nobody Sat Jun 28 05:53:50 2014 Return-Path: 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 ; 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 ; 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 ; 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)" To: "karagian@cs.utwente.nl" , "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: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 12:53:50 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF1F141SZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Georgios, I agree that this may be a strong use case to show how a service provider t= o make good use of APONF, specially on the words "abstracted view of the ne= twork, so that you're programming the abstraction", which IMHO means to abs= tract the common parts and models from the existing complex and diversifor= m 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 th= ose big global network service companies like google, as they may need to c= hange their programming strategy according to the particular scenarios. And you're right. The points you listed are out of scope of SFC WG, and sho= uld be covered in IETF. I think a detailed use case draft describing the google case may be very he= lpful 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.utwe= nte.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 appli= cation 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 de= vices. 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/201= 4/06/ This vision can be realised within the IETF as follows: The abstract view of the network can be realised by using the Service Funct= ion Path (SFP), specified by the IETF SFC WG. In adition to this, a way is needed to provide the SFP network view to appl= ication developers, such that the application developer can use this SFP du= ring the development, but also runtime phases, such that the application ca= n 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 an= d 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 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF1F141SZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Georgios,

 

I agree that this may = be a strong use case to show how a service provider to make good use of APO= NF, specially on the words “abstracted view of the network, so that y= ou’re programming the abstraction”, which IMHO means to abstract the common parts and models from the existing compl= ex and  diversiform network devices and architectures. During our surv= ey 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 pr= ogramming 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 i= n IETF.

 

I think a detailed use= case draft describing the google case may be very helpful to clarify the s= cope 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 o= n 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 vie= w of google on application based policy could be realised in the context of= IETF.

 

The main goal of application based p= olicy 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 fr= om:

 

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

 

This vision can be realised within t= he IETF as follows:

 

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

 

In adition to this, a way is needed = to provide the SFP network view to application developers, such that the ap= plication 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 (S= FP) 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 man= agement applications (OSS applications). Note that a network management app= lication are Operational Support System (OSS) applications
that help a communications service provider to monitor, control, analyze an= d manage a communication network.

 

 

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

 

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

 

Comments are very much appreciated!<= o:p>


Best regards,
Georgios Karagiannis

 =

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF1F141SZXEMA509MBSchi_-- From nobody Sun Jun 29 23:41:49 2014 Return-Path: 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 68B221A0180 for ; Sun, 29 Jun 2014 23:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 liM0Zus-KD-3 for ; Sun, 29 Jun 2014 23:41:46 -0700 (PDT) Received: from out63-ams.mf.surf.net (out63-ams.mf.surf.net [145.0.1.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88A41A0179 for ; Sun, 29 Jun 2014 23:41:45 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s5U6fhs9028167 for ; Mon, 30 Jun 2014 08:41:43 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 30 Jun 2014 08:41:43 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Mon, 30 Jun 2014 08:41:43 +0200 From: To: Thread-Topic: APONF bar BOF agenda proposal update + reminder to fill in doodle Thread-Index: AQHPlC5aAtVtL6jRx0+BG0FaxqF3hw== Date: Mon, 30 Jun 2014 06:41:42 +0000 Message-ID: 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_FF1A9612A94D5C4A81ED7DE1039AB80F4F4960C9EXMBX23adutwent_" 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: 0bMkuFHbB - fa2c690fa5b8 - 20140630 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/9clO5rO90bEG-dG2hIRhA981eW0 Subject: [Openv6] APONF bar BOF agenda proposal update + reminder to fill in doodle X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 06:41:48 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4960C9EXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all, Below you can find an update of the APONF bar BOF agenda. Please note that we have not yet chosen a a suitable day and time for the A= PONF bar BOF. The reason for this is that the APONF doodle poll has not yet closed! The closing date is the 1st of July (tomorrow)! If you have not yet filled in the doodle poll, can you please fill in your = availability time, following the below URL? http://doodle.com/hbtkqvirfyqqteiz APONF Application-based Policy for Network Functions) bar BOF agenda (total time 120 minutes) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Note: all questions are taken during =93Discussion and Next Steps=94 time s= lot o) briefly present APONF use cases (5 use cases * 5 =3D 25 minutes) o) problem statement (Georgios: 30 minutes) o) what is in the scope and what is out of the scope of APONF (10 minutes) o) what are the relations with other IETF WGs and available BOF description= s (10 minutes) o) what are the expected deliverables (10 minutes) o) Discussion and next steps (35 minutes) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Best regards, Scott Bradner & Georgios Karagiannis --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4960C9EXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Below you can find an update of the APONF bar BOF agenda.

 

Please note that we have not yet chosen a a suitable day and time= for the APONF bar BOF.

 

The reason for this is that the APONF doodle poll has not yet clo= sed!

 

The closing date is the 1st of July (tomorrow)!

 

If you have not yet filled in the doodle poll, can you please fil= l in your availability time, following the below URL?

 

= http://doodle.com/hbtkqvirfyqqteiz

 

 

<= span lang=3D"EN-US">APONF Application-based Policy for Network Functions) bar= BOF agenda

<= span lang=3D"EN-US">(total time 120 minutes)=

<= span lang=3D"EN-US">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

<= span lang=3D"EN-US">

<= span lang=3D"EN-US">Note: all questions are taken during = =93Discussion and Next Steps=94 time slot

 

o) briefly present APONF use cases (5 use cases * = 5 =3D 25 minutes)


o) problem statement (Georgios: 30 minutes)

 

o) what is in the scope and what is out of the sco= pe of APONF (10 minutes)


o) what are the relations with other IETF WGs and available BOF description= s (10 minutes)

 

o) what are the expected deliverables (10 minutes)

 

o) Discussion and next steps (35 minutes)

<= span lang=3D"EN-US">

<= span lang=3D"EN-US">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= span lang=3D"EN-US"> 

<= span lang=3D"EN-US">Best regards,

<= span lang=3D"EN-US">Scott Bradner & Georgios Karagiann= is

<= span lang=3D"EN-US"> 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F4960C9EXMBX23adutwent_-- From nobody Mon Jun 30 02:51:33 2014 Return-Path: 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 ABD8A1A01D9 for ; Mon, 30 Jun 2014 02:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 OuFojVycOCJv for ; Mon, 30 Jun 2014 02:51:25 -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 823871A01D2 for ; Mon, 30 Jun 2014 02:51:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGQ15572; Mon, 30 Jun 2014 09:51:20 +0000 (GMT) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 10:51:19 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.34]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 17:51:13 +0800 From: Tina TSOU To: "karagian@cs.utwente.nl" , "jsaldana@unizar.es" , "Openv6@ietf.org" Thread-Topic: [Openv6] Is there a draft charter for APONF? Thread-Index: Ac+D9qNFXyUFgyrbQS6LFACB00Od8gAEVOrrAB1I+KAA11qzdgMbPPKg Date: Mon, 30 Jun 2014 09:51:13 +0000 Message-ID: References: <00b801cf83f7$2eaffd00$8c0ff700$@unizar.es> , <6344BC5E-9EF0-45CD-9664-91CD60193E18@huawei.com> In-Reply-To: <6344BC5E-9EF0-45CD-9664-91CD60193E18@huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.249] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8183BED63szxeml557mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/8J4Fxgn0EozQzSR6UxEiQqQ8e2Q Subject: Re: [Openv6] Is there a draft charter for APONF? X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 09:51:33 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8183BED63szxeml557mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Based on everybody's feedback, here comes the 3rd version of the charter. Hope it is more precise and concrete for you to comment on. ------------------------------------ APONF (Application-based Policy for Network Functions) charter Target Area: Operations and Management Area Description of Working Group: Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract= view of a network infrastructure can be realized using a network configur= ation model, that provides a declarative configuration and a network topolo= gy model that describes a multi-layer network. Network management applicati= ons are Operational Support System (OSS) like applications that help a comm= unication service provider to monitor, control, analyze and manage a commun= ication network. In this context, network management applications can be used to provide the= required configuration and application programming interfaces to such serv= ice developers. Subsequently, a network management application can use the = application based demands and possibly update its associated network config= uration and/or network topology model. Examples of network management appli= cations that can modify the network configuration and/or network topology m= odels are for example, virtual network function services, Distributed Data = Center Application, IPv6 transitions, streaming and IoT applications, need = to change the network infrastructure configuration. The updated network configuration and network topology model needs to be co= mmunicated to e.g., the network management system, the routing controlling = system or other controlling systems, to map the network configuration and n= etwork topology models into specific device level configuration models. Currently, there are no IETF standard mechanisms or modeling languages that= can directly be applied to model the network configuration nor the network= topology. IETF has however, created the IETF SFC WG to document a new appr= oach to service delivery and operation, where one of its goals is to realiz= e an abstract view of a network by using a service graph denoted as the Ser= vice Function Path (SFP). This will enable the development of suitable mode= ls for network configuration and network topology. Furthermore, there are currently no IETF solutions that can be used to prov= ide the necessary configuration interfaces to service developers to program= the abstract view of a network infrastructure. Currently, the Application = Enabled Collaborative Network (AECON) activity can provide these necessary = solutions. Moreover, there are no IETF solutions that can directly be used to (1) enab= le the streaming transfer of bulk-variable/data of network configuration an= d network topology models between network management application systems an= d e.g., the network management system, the routing controlling system or ot= her controlling systems, and (2) map the network configuration and network = topology models into specific device level configuration models. The APONF = activity can provide a solution to this challenge. The main goal of APONF is to: o) enable the streaming transfer of bulk-variable/data of the up to date SF= P based network configuration and network topology models between network m= anagement application systems and e.g., the network management system, the = routing controlling system or other controlling systems, by using and exten= ding the IETF Next Steps in Signaling Protocol (NSIS). o) map the SFP based network configuration and network topology models into= specific device level configuration models. The APONF requirements/objectives are: o) monitor and verify the freshness of the SFP based network configuration = and network topology models o) extend the IETF NSIS protocol to securely and efficiently distribute the= SFP based network configuration and network topology models between networ= k management applications (e.g., OSS applications) and e.g., the network ma= nagement system, the routing controlling system or other controlling system= s o) use application based demands generated by network management applicatio= ns to map the SFP based network configuration and network topology models i= nto specific device level configuration models. Such application based dema= nds are: a) Encapsulating, de-encapsulating packets associated with a flow into a tu= nnel (for example, VPN service, IPv6 transition service need to manage the = network function to do that): b) blocking, or dropping packets associated with a flow in (the edge of) th= e network element when the network security service is aware of the attack = (for example, SAVI service, Anti-DoS service need to manage the network fun= ction to do that). c) configure and dynamically reconfigure data centers to the steer and rero= ute traffic associated with a specific flow d) configure and dynamically reconfigure data centers to change priorities= of different types of traffic associated with a specific flow e) Logging the traffic associated with a flow for network security service,= optimization of the traffic in network for IETF ALTO service f) other actions defined by the administrator o) specify the Authentication Authorization and Accounting (AAA) method Work items related to APONF include: o) specify the problem statement and use cases o) specify the APONF architecture o) specify extensions to the IETF NSIS protocol to distribute the SFP based= network configuration and network topology models between network manageme= nt applications (e.g., OSS applications) and e.g., the network management s= ystem, the routing controlling system or other controlling systems. The IET= F Next Steps in Signaling (NSIS) protocol may be extended in two ways to su= pport this interface: a) Extend NSIS GIST to be used for off-path support b) Specify a new NSLP (NSIS Signaling Layer Protocol), similar to the NAT/F= irewall NSLP and QoS NSLP that can be applied and support the APONF use cas= es. o) map the SFP based network configuration and network topology models into= specific device level configuration models o) specify the AAA method. Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'APONF Architecture' as an Informational RFC. I-D 'Mapping SFP based models into specific device level configuration mode= ls' as an Informational RFC. I-D 'APONF based NSIS Protocol Specification' Standards Track RFC. -------------------------------------- Thank you, Tina From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Tina TSOU Sent: Saturday, June 14, 2014 10:11 PM To: karagian@cs.utwente.nl; jsaldana@unizar.es; Openv6@ietf.org Subject: Re: [Openv6] Is there a draft charter for APONF? Dear all, Below is 2nd version of the charter based on all the feedback, many things = are removed. Comments are very welcome. ---- APONF (Application-based Policy for Network Functions) charter Description of Working Group: Currently, there are network management applications that have specific dem= ands on a communication network. For example, some specialized applications= , like virtual network function services and Distributed Data Center Applic= ation, may need to *dynamically manage* the network infrastructure, and oth= er specialized applications, like streaming applications and Internet of Th= ings (IoT) applications, may require to configure the network according to = their demands. If possible, a network management application may require fr= om the communication network to apply the following different network manag= ement capabilities, such as: * dynamically (re)configure a network entity * accelerate the service deployment * getting better network services from transport network * providing better user experience The network management application's demands on a communication network are= different, but there are several demands that may be similar, such as diff= erent Web Surfing/Browsing applications, IoT applications, virtual network = function services, Distributed Data Center Application, which can be groupe= d/classified together. The classified network management application demand= s on a communication network can be presented and modeled as classified net= work management application-based policies. A set of network management app= lication-based policy models may be needed for auto-mapping of network mana= gement application's demands to existing network management policies. This = will allow network management applications to use the network capabilities = in a more accurate and efficient way. The definition of these network management policies is out of the APONF sco= pe. Examples of such network management policies that are considered by APONF a= re the following: * Manage dynamically network semantics (supported by e.g., SNMP= /MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function= Virtualization configuration) BOF activity) * Orchestrate dynamically virtualized functions (supported by e= .g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF ac= tivity, Abstraction and Control of Transport Networks (ACTN) BOF activity) * Log the traffic (supported by e.g., I2RS WG, FORCES WG, Appli= cation Enabled Collaborative Network (AECN) BOF activity) * Set the traffic, e.g., encapsulation/decapsulation (supported= for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collab= orative Network (AECN) BOF activity) These network management application-based policy models can meet the netwo= rk management application's demands on the communication network and map th= ese demands to network management policies that can be understood by the co= mmunication network. The main goal of APONF is to specify the network management application-bas= ed policy protocol(s), mechanisms and models required by network managemen= t applications to easily, accurately, and efficiently select and use the av= ailable communication network capabilities, i.e., network management polici= es. The users of the APONF are network management applications requests that ha= ve specific demands on a communication network. Work items related to APONF include: * specify the APONF groups/classes of application policies and = models * provide mechanisms that can accurately map and store the APON= F groups/classes of application policies and models into existing network m= anagement policies. * specify the protocol and the required mechanisms that are abl= e to support the communication between the network management applications= and the ABPD entity that maintains the groups/classes of application polic= ies and models. * provide the means to use existing network management protocol= s and mechanisms to enforce the network management application policies (v= ia the associated network management policies) into network entities. Such = protocols and mechanism are supported for/by e.g., SNMP/MIB, COPS-PR/PIB, N= etCon/Yang, Web Services/MIB, nfvcon activity, SCF WG, ACT activity, I2RS W= G, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN, M= PLS. * provide authentication and authorization mechanisms to suppor= t the communication between the Network Management Application and the ABPD= entity. * provide privacy support for the end users running the applica= tions that make use of the APONF protocol and mechanisms. Initially, the APONF work will focus on the follow aspects: * high-level architecture * Solution requirements * a set of application based policy models for different classe= s of applications * a set of use cases * analysis of existing protocols that can be reused in the arch= itecture Milestones: * November 2014 Submit I-D 'Use cases' to the IESG for consider= ation as an Informational RFC. * February 2015 - Submit I-D 'Solution Requirements' to the IES= G for consideration as an Informational RFC. * March 2015 Submit I-D 'High level Architecture' to the IESG f= or consideration as an Informational RFC.- * July 2015 Submit I-D 'Gap Analysis' to the IESG for considera= tion as an Informational RFC.- * Jul y2015 - Evaluate the need for further work based on the i= dentified gaps and revise the milestones and/or the charter of the group ----- Thank you, Tina On Jun 10, 2014, at 4:00 PM, "Tina TSOU" > wrote: Dear all, Here is the first cut of a draft charter for APONF. APONF (Application-based Policy for Network Functions) charter Description of Working Group: Currently, there are transport applications that have specific demands on a= communication network. For example, some specialized applications, like vi= rtual network function services, may need to *dynamically manage* the netwo= rk infrastructure, and other specialized applications, like streaming appli= cations and Internet of Things (IoT) applications, may require from the net= work to treat their traffic according to their demands. If possible, a spec= ialized application may require from the communication network to apply the= following different network management and/or traffic capabilities, such = as: * dynamically (re)configure a network entity * accelerate the service deployment * getting better network services from transport network * providing better user experience The application's demands on a communication network are different, but the= re are several specialized application demands that may be similar, such as= different IoT applications, virtual network function services, which can b= e grouped/classified together. The classified application demands on a comm= unication network can be presented and modeled as classified application-ba= sed policies. A set of application-based policy models may be needed for au= to-mapping of application's demands to existing network management and/or t= raffic policies. This will allow applications to use the network capabiliti= es in a more accurate and efficient way. The definition of these network management and traffic policies is out of t= he APONF scope. Examples of such network management and traffic policies that are considere= d by APONF are the following: * Manage dynamically network semantics (supported by e.g., SNMP= /MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function= Virtualization configuration) BOF activity) * Orchestrate dynamically virtualized functions (supported by e= .g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF ac= tivity, Abstraction and Control of Transport Networks (ACTN) BOF activity) * Permit/Block/Redirect the traffic (supported by e.g., I2RS WG= , FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity) * Log the traffic (supported by e.g., I2RS WG, FORCES WG, Appli= cation Enabled Collaborative Network (AECN) BOF activity) * Copy the traffic, e.g., multicast (supported by e.g.,I2RS WG,= FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity * Set the traffic, e.g., encapsulation/decapsulation (supported= for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collab= orative Network (AECN) BOF activity) * Mark the traffic (supported for/by e.g., Intserv, Diffserv, P= CN, MPLS) These application-based policy models can meet the specialized application'= s demands on the communication network and map these demands to network man= agement and traffic policies that can be understood by the communication ne= twork. The main goal of APONF is to specify the application-based policy protocol(= s), mechanisms and models required by transport applications to easily, ac= curately, and efficiently select and use the available communication networ= k capabilities, i.e., network management and/or traffic policies. The users of the APONF may be the network management applications, or (BOF)= TAPS (Transport Services) requests that have specific demands on a communi= cation network. Work items related to APONF include: * specify the APONF groups/classes of application policies and = models * provide mechanisms that can accurately map and store the APON= F groups/classes of application policies and models into existing network m= anagement and traffic policies. * specify the protocol and the required mechanisms that are abl= e to support the communication between the transport applications and the = ABPD entity that maintains the groups/classes of application policies and m= odels. * provide the means to use existing network management and/or t= raffic conditioning protocols and mechanisms to enforce the application po= licies (via the associated network management and traffic policies) into ne= twork entities. Such protocols and mechanism are supported for/by e.g., SNM= P/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon activity, SCF WG,= ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intse= rv, Diffsrerv, PCN, MPLS. * provide authentication and authorization mechanisms to suppor= t the communication between the Transport Application and the ABPD entity. * provide privacy support for the end users running the applica= tions that make use of the APONF protocol and mechanisms. Initially, the APONF work will focus on the follow aspects: * high-level architecture * Solution requirements * a set of application based policy models for different classe= s of applications * a set of use cases * analysis of existing protocols that can be reused in the arch= itecture Milestones: * November 2014 Submit I-D 'Use cases' to the IESG for consider= ation as an Informational RFC. * February 2015 - Submit I-D 'Solution Requirements' to the IES= G for consideration as an Informational RFC. * March 2015 Submit I-D 'High level Architecture' to the IESG f= or consideration as an Informational RFC.- * July 2015 Submit I-D 'Gap Analysis' to the IESG for considera= tion as an Informational RFC.- * Jul y2015 - Evaluate the need for further work based on the i= dentified gaps and revise the milestones and/or the charter of the group Thank you, Tina From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.utwe= nte.nl Sent: Tuesday, June 10, 2014 1:28 AM To: jsaldana@unizar.es; Openv6@ietf.org Subject: Re: [Openv6] Is there a draft charter for APONF? Hi Jose, Thanks for the comments! Yes we are planning to create a APONF BOF charter soon! Best regards, Georgios ________________________________ Van: Openv6 [openv6-bounces@ietf.org] namen= s Jose Saldana [jsaldana@unizar.es] Verzonden: maandag 9 juni 2014 17:26 Aan: Openv6@ietf.org Onderwerp: [Openv6] Is there a draft charter for APONF? Hi, I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac= /wiki. Is there a draft charter somewhere? In case not, I would suggest to write a= first version and send it to the list. It would be somewhat similar to the= BoF summary, but it would also include the goals and milestones, deliverab= les of the potential WG, interactions with other WGs, etc. Best regards, Jose Saldana --_000_C0E0A32284495243BDE0AC8A066631A8183BED63szxeml557mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Based on everybodyR= 17;s feedback, here comes the 3rd version of the charter.

 

Hope it is more precis= e and concrete for you to comment on.

 

----------------------= --------------

APONF (Application-= based Policy for Network Functions) charter

 

Target Area: Operation= s and Management Area

 

Description of Working= Group:

 

Today network operator= s are challenged to create an abstract view of their network infrastructure= and help service developers on using and programming this abstraction rath= er than  manipulating individual devices. An abstract view of a network infrastructure can be realized using  a= network configuration model, that provides a declarative configuration and= a network topology model that describes a multi-layer network. Network man= agement applications are Operational Support System (OSS) like applications that help a communication service p= rovider to monitor, control, analyze and manage a communication network.

In this context, netwo= rk management applications can be used to provide the required configuratio= n and application programming interfaces to such service developers. Subseq= uently, a network management application can use the application based demands and possibly update its associated n= etwork configuration and/or network topology model. Examples of network man= agement applications that can modify the network configuration and/or netwo= rk topology models are for example, virtual network function services, Distributed Data Center Application, IP= v6 transitions, streaming and IoT applications, need to change the network = infrastructure configuration.

The updated network co= nfiguration and network topology model needs to be communicated to e.g., th= e network management system, the routing controlling system or other contro= lling systems, to map the network configuration and network topology models into specific device level configuration model= s.

 

Currently, there are n= o IETF standard mechanisms or modeling languages that can directly be appli= ed to model the network configuration nor the network topology. IETF has ho= wever, created the IETF SFC WG to document a new approach to service delivery and operation, where one of its goals i= s to realize an abstract view of a network by using a service graph denoted= as the Service Function Path (SFP). This will enable the development of su= itable models for network configuration and network topology.

Furthermore, there are= currently no IETF solutions that can be used to provide the necessary conf= iguration interfaces to service developers to program the abstract view of = a network infrastructure. Currently, the Application Enabled Collaborative Network (AECON) activity can provide= these necessary solutions.

 

Moreover, there are no= IETF solutions that can directly be used to (1) enable the streaming trans= fer of bulk-variable/data of network configuration and network topology mod= els between network management application systems and e.g., the network management system, the routing controlling s= ystem or other controlling systems, and (2) map the network configuration a= nd network topology models into specific device level configuration models.= The APONF activity can provide a solution to this challenge.

 

The main goal of APONF= is to:

o) enable the streamin= g transfer of bulk-variable/data of the up to date SFP based network config= uration and network topology models between network management application = systems and e.g., the network management system, the routing controlling system or other controlling systems, by us= ing and extending the IETF Next Steps in Signaling Protocol (NSIS).

o) map the SFP based n= etwork configuration and network topology models into specific device level= configuration models.

 

The APONF requirements= /objectives are:

 

o) monitor and verify = the freshness of the SFP based network configuration and network topology m= odels

 

o) extend the IETF NSI= S protocol to securely and efficiently distribute the SFP based network con= figuration and network topology models between network management applicati= ons (e.g., OSS applications) and e.g., the network management system, the routing controlling system or other con= trolling systems

 

o) use application bas= ed demands generated by network management applications to map the SFP base= d network configuration and network topology models into specific device le= vel configuration models. Such application based demands are:

 

a) Encapsulating, de-e= ncapsulating packets associated with a flow into a tunnel (for example, VPN= service, IPv6 transition service need to manage the network function to do= that):

 

b) blocking, or droppi= ng packets associated with a flow in (the edge of) the network element when= the network security service is aware of the attack (for example, SAVI ser= vice, Anti-DoS service need to manage the network function to do that).

 

c) configure and dynam= ically reconfigure data centers to the steer and reroute traffic associated= with a specific flow

 

d) configure and dynam= ically reconfigure data centers to  change priorities of different typ= es of traffic associated with a specific flow

 

e) Logging the traffic= associated with a flow for network security service, optimization of the t= raffic in network for IETF ALTO service

 

f) other actions defin= ed by the administrator

 

o) specify the Authent= ication Authorization and Accounting (AAA) method

 

Work items related to = APONF include:

o) specify the problem= statement and use cases

 

o) specify the APONF a= rchitecture

 

o) specify extensions = to the IETF NSIS protocol to distribute the SFP based network configuration= and network topology models between network management applications (e.g.,= OSS applications) and e.g., the network management system, the routing controlling system or other controlling sys= tems. The IETF Next Steps in Signaling (NSIS) protocol may be extended in t= wo ways to support this interface:

a) Extend NSIS GIST to= be used for off-path support

 

b) Specify a new NSLP = (NSIS Signaling Layer Protocol), similar to the NAT/Firewall NSLP and QoS N= SLP that can be applied and support the APONF use cases. 

 

o) map the SFP based n= etwork configuration and network topology models into specific device level= configuration models

 

o) specify the AAA met= hod.

 

Milestones:=

 

I-D 'Problem Statement= and Use Cases' as an Informational RFC.

 

I-D 'APONF Architectur= e' as an Informational RFC.

 

I-D 'Mapping SFP based= models into specific device level configuration models' as an Informationa= l RFC.

 

I-D 'APONF based NSIS = Protocol Specification' Standards Track RFC.

----------------------= ----------------

 

 

Thank you,<= /span>

Tina=

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Saturday, June 14, 2014 10:11 PM
To: karagian@cs.utwente.nl; jsaldana@unizar.es; Openv6@ietf.org
Subject: Re: [Openv6] Is there a draft charter for APONF?=

 

Dear all,

 

Below is 2nd version of the charter based on all the= feedback, many things are removed.

 

Comments are very welcome.

 

----

APONF (Application-based Policy for Network Functions) cha= rter

 

Description of Working Group:

 

Currently, there are network management applications that hav= e specific demands on a communication network. For example, some specialized applications, like virtual network function services and = Distributed Data Center Application, may need to *dynamically manage* the n= etwork infrastructure, and other specialized applications, like streaming a= pplications and Internet of Things (IoT) applications, may require to configure the network according to thei= r demands. If possible, a network management application may require from t= he communication network to apply the following different network managemen= t capabilities, such as:

•         =     dynamically (re)configure a network entity

•         =     accelerate the service deployment

•         =     getting better network services from transport network

•         =     providing better user experience

 

The network management application’s demands on a commu= nication network are different, but there are several demands that may be similar, such as different Web Surfing/Browsing applications, IoT a= pplications, virtual network function services, Distributed Data Center App= lication, which can be grouped/classified together. The classified network = management application demands on a communication network can be presented and modeled as classified network= management application-based policies. A set of network management applica= tion-based policy models may be needed for auto-mapping of network manageme= nt application’s demands to existing network management policies. This will allow network management applicatio= ns to use the network capabilities in a more accurate and efficient way.

 

The definition of these network management policies is out of= the APONF scope.

 

Examples of such network management policies that are conside= red by APONF are the following:

 

•         =     Manage dynamically network semantics (supported by e.g.,= SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvconf (Network Function Virtualization configuration) BOF activity)

•         =     Orchestrate dynamically virtualized functions (supported= by e.g., SCF WG, nfvconf (Network Function Virtualization configuration) BOF activity, Abstraction and Control of Transport Networks= (ACTN) BOF activity)

•         =     Log the traffic (supported by e.g., I2RS WG, FORCES WG, = Application Enabled Collaborative Network (AECN) BOF activity)

•         =     Set the traffic, e.g., encapsulation/decapsulation (supp= orted for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF activity)<= o:p>

 

These network management application-based policy models can = meet the network management application’s demands on the communicatio= n network and map these demands to network management policies that can be u= nderstood by the communication network.

 

The main goal of APONF is to specify the network management a= pplication-based policy protocol(s), mechanisms and models required  by network management applications to easily, accurately, a= nd efficiently select and use the available communication network capabilit= ies, i.e., network management policies.

 

The users of the APONF are network management applications re= quests that have specific demands on a communication network.

 

Work items related to APONF include:

•         =     specify the APONF groups/classes of application policies= and models

•         =     provide mechanisms that can accurately map and store the= APONF groups/classes of application policies and models into existing network management policies.

•         =     specify the protocol and the required mechanisms that ar= e able  to support the communication between the network management applications and the ABPD entity that maintains the gro= ups/classes of application policies and models.

•         =     provide the means to use existing network management pro= tocols and mechanisms to enforce the  network management application policies (via the associated network management policies) into= network entities. Such protocols and mechanism are supported for/by e.g., = SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon activity, SCF = WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN, MPLS.

•         =     provide authentication and authorization mechanisms to s= upport the communication between the Network Management Application and the ABPD entity.

•         =     provide privacy support for the end users running the ap= plications that make use of the APONF protocol and mechanisms.

 

Initially, the APONF work will focus on the follow aspects:

•         =     high-level architecture

•         =     Solution requirements

•         =     a set of application based policy models for different c= lasses of applications

•         =     a set of use cases

•         =     analysis of existing protocols that can be reused in the= architecture

 

Milestones:

•         =     November 2014 Submit I-D 'Use cases' to the IESG for con= sideration as an Informational RFC.

•         =     February 2015 – Submit I-D 'Solution Requirements'= to the IESG for consideration as an Informational RFC.

•         =     March 2015 Submit I-D 'High level Architecture' to the I= ESG for consideration as an Informational RFC.-

•         =     July 2015 Submit I-D 'Gap Analysis' to the IESG for cons= ideration as an Informational RFC.-

•         =     Jul y2015 - Evaluate the need for further work based on = the identified gaps and revise the milestones and/or the charter of the group

-----



 

Thank you,

Tina


On Jun 10, 2014, at 4:00 PM, "Tina TSOU" <Tina.Tsou.Zouting@huawei.com> wrote:

Dear all,<= /o:p>

 

Here is the first cut = of a draft charter for APONF.

 

APONF (Application-= based Policy for Network Functions) charter

 

Description of Working= Group:

 

Currently, there are t= ransport applications that have specific demands on a communication network= . For example, some specialized applications, like virtual network function= services, may need to *dynamically manage* the network infrastructure, and other specialized applications, li= ke streaming applications and Internet of Things (IoT) applications, may re= quire from the network to treat their traffic according to their demands. I= f possible, a specialized application may require from the communication network to apply the following differen= t network management and/or traffic  capabilities, such as:

•  &nb= sp;          dynamically (re)c= onfigure a network entity

•  &nb= sp;          accelerate the se= rvice deployment

•  &nb= sp;          getting better ne= twork services from transport network

•  &nb= sp;          providing better = user experience

 

The application’= s demands on a communication network are different, but there are several s= pecialized application demands that may be similar, such as different IoT a= pplications, virtual network function services, which can be grouped/classified together. The classified application deman= ds on a communication network can be presented and modeled as classified ap= plication-based policies. A set of application-based policy models may be n= eeded for auto-mapping of application’s demands to existing network management and/or traffic policies. This will = allow applications to use the network capabilities in a more accurate and e= fficient way.

 

The definition of thes= e network management and traffic policies is out of the APONF scope.

 

Examples of such netwo= rk management and traffic policies that are considered by APONF are the fol= lowing:

 

•  &nb= sp;          Manage dynamicall= y network semantics (supported by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang,= Web Services/MIB, nfvconf (Network Function Virtualization configuration) = BOF activity)

•  &nb= sp;          Orchestrate dynam= ically virtualized functions (supported by e.g., SCF WG, nfvconf (Network F= unction Virtualization configuration) BOF activity, Abstraction and Control= of Transport Networks (ACTN) BOF activity)

•  &nb= sp;          Permit/Block/Redi= rect the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enable= d Collaborative Network (AECN) BOF activity)

•  &nb= sp;          Log the traffic (= supported by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Ne= twork (AECN) BOF activity)

•  &nb= sp;          Copy the traffic,= e.g., multicast (supported by e.g.,I2RS WG, FORCES WG, Application Enabled= Collaborative Network (AECN) BOF activity

•  &nb= sp;          Set the traffic, = e.g., encapsulation/decapsulation (supported for/by e.g., NAT, Firewall, I2= RS WG, FORCES WG, Application Enabled Collaborative Network (AECN) BOF acti= vity)

•  &nb= sp;          Mark the traffic = (supported for/by e.g., Intserv, Diffserv, PCN, MPLS)

 

These application-base= d policy models can meet the specialized application’s demands on the= communication network and map these demands to network management and traf= fic policies that can be understood by the communication network.

 

The main goal of APONF= is to specify the application-based policy protocol(s), mechanisms and mod= els required  by transport applications to easily, accurately, and eff= iciently select and use the available communication network capabilities, i.e., network management and/or traffic policies.

 

The users of the APONF= may be the network management applications, or (BOF) TAPS (Transport Servi= ces) requests that have specific demands on a communication network.

 

Work items related to = APONF include:

•  &nb= sp;          specify the APONF= groups/classes of application policies and models

•  &nb= sp;          provide mechanism= s that can accurately map and store the APONF groups/classes of application= policies and models into existing network management and traffic policies.

•  &nb= sp;          specify the proto= col and the required mechanisms that are able  to support the communic= ation between the transport applications and the ABPD entity that maintains= the groups/classes of application policies and models.

•  &nb= sp;          provide the means= to use existing network management and/or traffic conditioning protocols a= nd mechanisms to enforce the  application policies (via the associated= network management and traffic policies) into network entities. Such protocols and mechanism are supporte= d for/by e.g., SNMP/MIB, COPS-PR/PIB, NetCon/Yang, Web Services/MIB, nfvcon= activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NA= T, Firewall, Intserv, Diffsrerv, PCN, MPLS.

•  &nb= sp;          provide authentic= ation and authorization mechanisms to support the communication between the= Transport Application and the ABPD entity.

•  &nb= sp;          provide privacy s= upport for the end users running the applications that make use of the APON= F protocol and mechanisms.

 

Initially, the APONF w= ork will focus on the follow aspects:

•  &nb= sp;          high-level archit= ecture

•  &nb= sp;          Solution requirem= ents

•  &nb= sp;          a set of applicat= ion based policy models for different classes of applications

•  &nb= sp;          a set of use case= s

•  &nb= sp;          analysis of exist= ing protocols that can be reused in the architecture

 

Milestones:<= /b>

•  &nb= sp;          November 2014 Sub= mit I-D 'Use cases' to the IESG for consideration as an Informational RFC.<= /span>

•  &nb= sp;          February 2015 = 211; Submit I-D 'Solution Requirements' to the IESG for consideration as an= Informational RFC.

•  &nb= sp;          March 2015 Submit= I-D 'High level Architecture' to the IESG for consideration as an Informat= ional RFC.-

•  &nb= sp;          July 2015 Submit = I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.-

•  &nb= sp;          Jul y2015 - Evalu= ate the need for further work based on the identified gaps and revise the m= ilestones and/or the charter of the group

 

 

Thank you,=

Tina=

 

From: Openv6 [= mailto:openv6-bounces@ietf.org] On Behalf Of karagian@cs.u= twente.nl
Sent: Tuesday, June 10, 2014 1:28 AM
To: jsaldana@unizar.es; Openv6@ietf.org
Subject: Re: [Openv6] Is there a draft charter for APONF?

 

Hi Jose,

 

 

Thanks for t= he comments!

Yes we are p= lanning to create a APONF BOF charter soon!

 

Best regards= ,

Georgios

 

Van: Openv= 6 [openv6-bounces@ietf.org] namens Jose Saldana [jsaldana@unizar= .es]
Verzonden: maandag 9 juni 2014 17:26
Aan: Openv6@ietf.org
Onderwerp: [Openv6] Is there a draft charter for APONF?<= /o:p>

Hi,

 

I have read the BoF summary of APONF in http://trac.tools.ietf.org/bof/trac/wiki.

 

Is there a draft charter somewhere? In case = not, I would suggest to write a first version and send it to the list. It w= ould be somewhat similar to the BoF summary, but it would also include the go= als and milestones, deliverables of the potential WG, interactions with oth= er WGs, etc.

 

Best regards,

 

Jose Saldana

 

--_000_C0E0A32284495243BDE0AC8A066631A8183BED63szxeml557mbschi_-- From nobody Mon Jun 30 04:14:56 2014 Return-Path: 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 55FD71A0208 for ; Mon, 30 Jun 2014 04:14:54 -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 SyqfSkLPBFc1 for ; Mon, 30 Jun 2014 04:14:52 -0700 (PDT) Received: from out47-ams.mf.surf.net (out47-ams.mf.surf.net [145.0.1.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA611A0202 for ; Mon, 30 Jun 2014 04:14:51 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s5UBEnir018650 for ; Mon, 30 Jun 2014 13:14:49 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 30 Jun 2014 13:14:49 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.31]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Mon, 30 Jun 2014 13:14:49 +0200 From: To: Thread-Topic: New Version Notification for draft-karagiannis-aponf-problem-statement-01.txt Thread-Index: AQHPlFOeeE4if/nGBUyj31F5KXGu45uJf01R Date: Mon, 30 Jun 2014 11:14:48 +0000 Message-ID: References: <20140630110821.1248.76473.idtracker@ietfa.amsl.com> In-Reply-To: <20140630110821.1248.76473.idtracker@ietfa.amsl.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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.48; 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: 0vMkzeNvK - 1ffa152cef04 - 20140630 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/openv6/njwhExYkijvxPhFQYXEhscxSjpI Subject: [Openv6] FW: New Version Notification for draft-karagiannis-aponf-problem-statement-01.txt X-BeenThere: openv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Openv6 discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 11:14:54 -0000 Dear all, Please note that we have used the comments of the IESG and IAB and updated = the APONF problem statement draft accordingly! The 01 version of the APONF problem statement draft has just been submitted= to the IETF, please see the below email. Comments are very welcome! Best regards, Georgios ________________________________________ Van: internet-drafts@ietf.org [internet-drafts@ietf.org] Verzonden: maandag 30 juni 2014 13:08 Aan: Qiong Sun; Karagiannis, G. (EWI); Qiong Sun; Tina Tsou; Will Liu; Tina= Tsou; Diego R. Lopez; Diego Lopez; Karagiannis, G. (EWI); Shucheng LIU (Wi= ll) Onderwerp: New Version Notification for draft-karagiannis-aponf-problem-sta= tement-01.txt A new version of I-D, draft-karagiannis-aponf-problem-statement-01.txt has been successfully submitted by Georgios Karagiannis and posted to the IETF repository. Name: draft-karagiannis-aponf-problem-statement Revision: 01 Title: Problem Statement for Application Policy on Network Functio= ns (APONF) Document date: 2014-06-30 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-karagiannis-aponf= -problem-statement-01.txt Status: https://datatracker.ietf.org/doc/draft-karagiannis-aponf-pr= oblem-statement/ Htmlized: http://tools.ietf.org/html/draft-karagiannis-aponf-problem-= statement-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-karagiannis-aponf-= problem-statement-01 Abstract: As more and more modern network management applications grow in scale and complexity, their demands and requirements on the supporting communication network will increase. In particular, today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than manipulating individual devices. In this context, network management applications can be used to provide the required configuration and application programming interfaces to such service developers. The main goal of APONF is to (1) communicate the up to date abstract view of the network between the network management application systems and network management and controlling systems and (2) map the abstract view of the network into specific network management policies, i.e., device level configuration models. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat=

I remember in an early version, the = problem related to SAVI (source address validation improvement) was = included,

But I found it was removed at this version. =

 

http://tools.ietf.org/id/draft-karagiannis-aponf-problem-statem= ent-00.txt

 

Since the problem still exists, I suggest to include = it.

 

Best Regards,

Jun Bi