From kurt.baumann@switch.ch Mon Apr 8 09:49:33 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2FB21F86C1 for ; Mon, 8 Apr 2013 09:49:33 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k3vbseQH+XE for ; Mon, 8 Apr 2013 09:49:32 -0700 (PDT) Received: from presunto.switch.ch (presunto.switch.ch [IPv6:2001:620:0:1b::9b]) by ietfa.amsl.com (Postfix) with ESMTP id 65EEE21F84AE for ; Mon, 8 Apr 2013 09:49:32 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:e::69]) by presunto.switch.ch (8.14.3/8.14.3/Debian-9.4) with ESMTP id r38GnTQ2012716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Apr 2013 18:49:30 +0200 Received: from [2001:620:0:25:1427:e198:30d5:5a6a] (helo=baumann.local) by surlej.switch.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UPFG5-0005ch-Aq for sdn@irtf.org; Mon, 08 Apr 2013 18:49:29 +0200 Message-ID: <5162F518.8010704@switch.ch> Date: Mon, 08 Apr 2013 18:49:28 +0200 From: Kurt Baumann Organization: SWITCH User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sdn@irtf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CanIt-Geo: ip=2001:620:0:e::69; country=CH X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [Sdn] GEANT Competitive Open Call for additional beneficiaries X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:49:33 -0000 Dear all, I like to announce the GEANT Competitive Open Calls for additional beneficiaries Link: http://www.geant.net/opencalls/Pages/default.aspx GÉANT Open Calls are structured around three key themes: * /Use cases to run on existing GÉANT production and experimental network facilities./ * /Self-contained Research and Technology Development (RTD) work packages to support on-going project activities./ * /RTD to promote, develop and demonstrate Innovation in a Multi-Domain Research and Education Networking Environment./ Link to the full text: http://www.geant.net/opencalls/Call_Text/Pages/Home.aspx Link to SDN: http://issuu.com/danteprm/docs/open_call_detailed_text_final/11?mode=window All proposals must be received by May 29,2013 (17:00 Brussels Time). Best regards, Kurt Baumann From hadi@mojatatu.com Wed Apr 10 04:42:24 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B966821F9494 for ; Wed, 10 Apr 2013 04:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJxx-vP3xVjT for ; Wed, 10 Apr 2013 04:42:24 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5E91821F944C for ; Wed, 10 Apr 2013 04:42:21 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id ox1so292398veb.21 for ; Wed, 10 Apr 2013 04:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=pQjaPwOTgHUf7WPxLk7AseyicKcnTNorSPKuYYIneE0=; b=AzmQg5IWCopoQwJl8BztIyjL11SMx8xJr55JgzQpuk/vuYMRKQi6bQKliusI+T71uh V1efk3GZqpNI3BZ+6t7Baorqe8XoEAyme+9byD6ZSwA9RwlwPWqYZJiXlDHgMrhxktSd jvk8AYxAcVrQD0qJt3XdA2aRhVBzS4beXsxy+bVfhXDvP57gs2T2A6C/ScHqrVPHHy2F 8cKbAHsMeQ3TsZT2FCnKUxZrtuKwavNbD1k4AhJ3dfrKvFO0iT20IIDuQWSs5QK57ni9 +ld5nfA5POmhxJcNQ5F6pzlDnl2w//kSeSOEF3zBOki/+A9T2JwQZTMrwSRXmXli8bqm sXpg== X-Received: by 10.220.222.8 with SMTP id ie8mr1164427vcb.27.1365594140489; Wed, 10 Apr 2013 04:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.24.137 with HTTP; Wed, 10 Apr 2013 04:41:59 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> From: Jamal Hadi Salim Date: Wed, 10 Apr 2013 07:41:59 -0400 Message-ID: To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmhxjuYC2o+/q0nt+88gV6jBSrDb4gTk5RGQcIO1bF9uXW9Kf6hO7K1Xieum6j3Ki2o9qE0 Cc: forces@ietf.org, "sdn@irtf.org" , JACQUENET Christian OLNC/OLN Subject: Re: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:42:24 -0000 Hi Med, I am finally going to answer the original email you posted instead of talking about IETF liasons ;-> Since i am consuming excellent brew of coffee, I will try to tone it down ;-> On Wed, Mar 20, 2013 at 11:40 AM, wrote: > Dear all, > > We submitted this new I-D. > > Comments and inputs are welcome. while the title is very specific/descriptive, it was a little hard to extract the central message upfront. If i was to sum up your message: This document provides an _operator perspective_ on what SDN needs are; and also serves to offer advice to network operators? The document injects a dose of pragmatism about inter-working with existing infrastructre. It took me a re-read to understand your draft is pushing an SDN theme of automation as the desired end goal. Did i get this right? Maybe your doc needs to break down what programmability aspect is needed from an operator perspective (CLI aka netconf, Policy management, service management, control-datapath separation etc). And, sorry, who is deploying COPS out there? Or perhaps your text on COPS was intended to emphasizw the point that nothing is new here? why not mention SS7 then (which is still in deployment)? Overall, I think theres a lot of words of wisdom as well as a good measure of cynicism against some of the over-marketing of SDN(which i empathize with). Thanks for pointing out that OF is not the end-all-be-all and that Control-datapath separation is merely infrastructure requirement in the larger picture (and, yes ForCES falls under the same umbrella). I have to say i was a little disappointed on the number of bytes you allocated to ForCES on this document. Mentioning ForCES in the same breath as RFC 1383 is rather harsh! from your sections 1 and 2 (it was hard to extract this): The (operator) "network is getting more complex"; ATAWAD is making it worse then you talk about desire from operator perspective is to create and deliver services despite the presence of such complexities in a manner which "evolves easily, remains scalable, robust and available (even in presence of DOS attacks)" But also you ask for "cost effectiveness". 1) On the issue of complexity, an interesting sample was illustrated by slide 6 from D. Meyer here: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf 2) And if i was to correlate Dave's slide to some food analogy: Equipment vendors are in the business of selling cookies (chocolate-chip, vanilla, ginger, etc of different sizes and shapes, etc) created via some well understood "factory" assembly line. Look at all those cookies in the slide. I am reading your view to be: the existing cookie-cut approach is _ok_ as long as the vendors provide you ways to automate and hide that complexity. But if that is the case, isnt it contradictory to also ask for (what i am assuming to be capital) cost effectiveness? more cookies will cost more, no? And more smart people figuring ways to give you atkins diet using cookies is also gonna cost you more. My view of the power of SDN is ability to be able to inject new Network Functions and be able to elongate life times of existing equipment (and all network functions become programmable). i.e in the ideal scenario I should be able to inject a new network function in an existing box without playing acrobatics with how to hack some tables in a distributed system. Whats your view of NFV? One thing you left out as an operator desire is "vendor lock-in". Is this not an important detail to you or it is taboo to talk about? On some of the expressed cynicsm in the document that i disagree with: I think you are under-valuing the control-data separation standardization such as the one pushed forward by ForCES in section 3.1. "tautology" by stating that vendors have been doing for years software based control etc. The SDN emphasis is: a) the control-data path separation is proprietary in those boxes b) tends to run on these tiny cpus (to which you are locked until you buy the next GodBox). My coffee-defined-energy is still high and I could say more - but i think i threw in a lot of text there... cheers, jamal From christian.jacquenet@orange.com Wed Apr 10 05:26:38 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BEB21F92B7 for ; Wed, 10 Apr 2013 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e15SXxYu4ue for ; Wed, 10 Apr 2013 05:26:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4621F95E2 for ; Wed, 10 Apr 2013 05:26:37 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A2FBC22CB37; Wed, 10 Apr 2013 14:26:36 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8266427C058; Wed, 10 Apr 2013 14:26:36 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Wed, 10 Apr 2013 14:26:31 +0200 From: To: Jamal Hadi Salim , BOUCADAIR Mohamed OLNC/OLN Date: Wed, 10 Apr 2013 14:26:29 +0200 Thread-Topic: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt Thread-Index: Ac414HhOYIB3rPg0Tvek/PLjKWCecQAAuPrwAADN9fA= Message-ID: <15335_1365596796_51655A7C_15335_156_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2F@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 Cc: "forces@ietf.org" , "sdn@irtf.org" Subject: Re: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:26:38 -0000 Re-sending, first mail was bounced. -----Message d'origine----- De : JACQUENET Christian OLNC/OLN=20 Envoy=E9 : mercredi 10 avril 2013 14:24 =C0 : 'Jamal Hadi Salim'; BOUCADAIR Mohamed OLNC/OLN Cc : sdn@irtf.org; forces@ietf.org Objet : RE: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt Hello Jamal, Many thanks for your detailed feedback. I'll let my fellow colleague furthe= r comment, but here's a first shot of responses from my side - inline.=20 [snip] while the title is very specific/descriptive, it was a little hard to extra= ct the central message upfront. If i was to sum up your message: This document provides an _operator perspective_ on what SDN needs are; and= also serves to offer advice to network operators? CJ: it's mostly a provider's perspective on current SDN hype (and beyond). = I think the "advice" wording is a bit strong - the draft is rather meant to= list a few things one should not forget when considering the use of SDN te= chniques to improve network service delivery procedures. The document injects a dose of pragmatism about inter-working with existing= infrastructre. It took me a re-read to understand your draft is pushing an SDN theme of au= tomation as the desired end goal. Did i get this right? CJ: automation is a means, not a goal per se. We believe automation is a ke= y benefit that can be brought by the activation of SDN techniques. The auto= mation of complex service delivery is clearly an attractive feature, for th= e sake of cost reduction. Maybe your doc needs to break down what programmability aspect is needed fr= om an operator perspective (CLI aka netconf, Policy management, service man= agement, control-datapath separation etc). And, sorry, who is deploying CO= PS out there? CJ: you'd be surprised by the number of networks that use COPS-PR implement= ations for the sake of bandwidth management in the access...This is a proto= col (along with the related SPPI-formatted information) that is supported b= y at least a couple of vendors and which is deployed in the operational fie= ld (at least a couple of networks operated by some of Orange's affiliates).= As for your suggestion, I'm not sure what you mean as we see programmabili= ty as a feature. Or perhaps your text on COPS was intended to emphasizw the point that nothi= ng is new here? why not mention SS7 then (which is still in deployment)? CJ: I certainly recognize there are plenty of functional components that ha= ve been specified and standardized (for some of them) for quite some time. = And I also recognize we may have not listed your favorite tool :-)=20 Overall, I think theres a lot of words of wisdom as well as a good measure = of cynicism against some of the over-marketing of SDN(which i empathize wit= h). CJ: thank you! That said, the point of the draft is certainly not to adopt = a cynical position towards SDN techniques - beyond the SDN wording, we are = true "SDN believers", provided we keep in mind a few things like this is no= t a one-size-fits-all solution, performance and scalability must be taken i= nto account as a function of the number and the nature of services to be de= livered and that the major technical challenges reside in the ability to co= mbine the 4 meta-functional blocks that we briefly introduce in the documen= t. That is, for example, take the results of a (CCP-based) negotiation of s= ervice parameters between the customer and the service provider as an input= that could gracefully feed a path computation module. Thanks for pointing out that OF is not the end-all-be-all and that Control-= datapath separation is merely infrastructure requirement in the larger pict= ure (and, yes ForCES falls under the same umbrella). I have to say i was a little disappointed on the number of bytes you alloca= ted to ForCES on this document. Mentioning ForCES in the same breath as RFC= 1383 is rather harsh! CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are int= eresting approaches aout there that are probably part of the global SDN lan= dscape. It's up to us to pick the technology that suits best. from your sections 1 and 2 (it was hard to extract this): The (operator) "network is getting more complex"; ATAWAD is making it worse= then you talk about desire from operator perspective is to create and deli= ver services despite the presence of such complexities in a manner which "e= volves easily, remains scalable, robust and available (even in presence of = DOS attacks)" But also you ask for "cost effectiveness". CJ: right. 1) On the issue of complexity, an interesting sample was illustrated by sli= de 6 from D. Meyer here: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf CJ: indeed. 2) And if i was to correlate Dave's slide to some food analogy: Equipment vendors are in the business of selling cookies (chocolate-chip, v= anilla, ginger, etc of different sizes and shapes, etc) created via some we= ll understood "factory" assembly line. Look at all those cookies in the sli= de. CJ: and the factory assembly is precisely where it gets really tricky. I am reading your view to be: the existing cookie-cut approach is _ok_ as l= ong as the vendors provide you ways to automate and hide that complexity. CJ: not exactly. We do not deny complexity, as long as it is hidden to our = *customers*. But if that is the case, isnt it contradictory to also ask for (what i am a= ssuming to be capital) cost effectiveness? more cookies will cost more, no?= And more smart people figuring ways to give you atkins diet using cookies= is also gonna cost you more. CJ: I don't think there is a single answer to your comment. Let me give you= an example: within the context of our current inter-domain VPN service off= ering, we need to request PE resources with peering partners, in a bilatera= l fashion. The corresponding negotiation remains paper- and fax- (yes fax)b= ased, and I can tell you it takes quite some time the get the proprer resou= rces right, let alone the CE-PE connection (especially in a dual homign con= text, depending on the location of the PE routers and the customer premises= ). Based upon an apporpriately-formatted CPP template, we believe that the = inherent complexity should be adequately balanced by a dramatic improvement= of the time-to-deliver the service, from several weeks to a few days, if n= ot hours. This will have a dramatic impact on the overall cost. My view of the power of SDN is ability to be able to inject new Network Fun= ctions and be able to elongate life times of existing equipment (and all ne= twork functions become programmable). i.e in the ideal scenario I should be= able to inject a new network function in an existing box without playing a= crobatics with how to hack some tables in a distributed system. Whats your = view of NFV? CJ: NFV is part of the global SDN landscape from my perspective. This is wh= y we see information models and data (including policy provisioning informa= tion) as a key component of what you call NFV. That said, I'm not convinced= NFV can be applied to each and every network capability you could think of= , depending on the nature of the service and the impact on the amount of (c= onfiguration information) traffic that needs to be exchanged between the co= ntrol and the data planes, for example. One thing you left out as an operator desire is "vendor lock-in". Is this n= ot an important detail to you or it is taboo to talk about? CJ: that's certainly important, this is clearly not a taboo, but this is al= so something tht is not SDN-specific (at least as far asFT Orange is concer= ned). On some of the expressed cynicsm in the document that i disagree with: I think you are under-valuing the control-data separation standardization s= uch as the one pushed forward by ForCES in section 3.1. "tautology" by stating that vendors have been doing for years software based control et= c. The SDN emphasis is: a) the control-data path separation is proprietary in those boxes CJ: correct. b) tends to run on these tiny cpus (to which you are locked until you buy t= he next GodBox). CJ; right, but we were actually discussing the fuzz around separated contro= l and forwarding planes. We understand the SDN approach, but we'd appreciat= e a more specific/accurate wording for the sake of undertsnadability. My coffee-defined-energy is still high and I could say more - but i think i= threw in a lot of text there... CJ: thanks again for this interesting discussion. We're looking forward to = hearing from you all! Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From hadi@mojatatu.com Wed Apr 10 07:15:05 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AD021F9803 for ; Wed, 10 Apr 2013 07:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWkROz0hp+UX for ; Wed, 10 Apr 2013 07:15:04 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 683EC21F97F7 for ; Wed, 10 Apr 2013 07:15:04 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hf12so400332vcb.7 for ; Wed, 10 Apr 2013 07:15:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=XQlXgPAwW+j0ebJyCkExdBkUYBScs+KveWRqC0J4I1g=; b=SP0E4mJtHGFgna3OkGWGp9xqrBxcdj0jlkautnA4f5NRNJmdV+SEY1llrRxrSBrvOe U4ND8kk19Uu97nqcTip3/BfTCNCZXYtqnEPt093oR1CSw9ZymL7vLoyRik+6j1Am61/m WgY8q7wzZzpE3q2f8rbmyYMazSGU7NUTV0IL6OvBK+IU5sAns+GBrwYSUrGZJhodDv9M YqisTs+VMv8idQIrKVOcPxWe0fCuiuJRJIR+jNX/TelW3gF5yQiivoOhIdvYXUPekAn4 TmdDR4VCg+a5ZzQBUYzBiBYHTrTBWcij95ahcRUgtv37pPsShPrpsnjfC+3GDXw47gcY rrgw== X-Received: by 10.58.155.133 with SMTP id vw5mr1598257veb.43.1365603303732; Wed, 10 Apr 2013 07:15:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.24.137 with HTTP; Wed, 10 Apr 2013 07:14:43 -0700 (PDT) In-Reply-To: <14742_1365596634_516559DA_14742_324_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2B@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> <14742_1365596634_516559DA_14742_324_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2B@PUEXCB1C.nanterre.francetelecom.fr> From: Jamal Hadi Salim Date: Wed, 10 Apr 2013 10:14:43 -0400 Message-ID: To: christian.jacquenet@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlPaYK9lm7yb1kRy8o9/6P4RY7UNOx3tEmW3D5uTaE8gxbFx3BsSiFgd4EBSg6Jr55AKED/ Cc: "sdn@irtf.org" , "forces@ietf.org" , BOUCADAIR Mohamed OLNC/OLN Subject: Re: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:15:05 -0000 Hi Christian, On Wed, Apr 10, 2013 at 8:23 AM, wrote: > CJ: it's mostly a provider's perspective on current SDN hype (and beyond)= . I think the >"advice" wording is a bit strong - the draft is rather meant to list a few= things one should >not forget when considering the use of SDN techniques to improve network s= ervice >delivery procedures. > ;-> So it is advice. I think it will make the draft stronger if you invite other providers to co-author. My view of what a provider needs is shaped by some presentation i saw a while back - the emphasis there was on the theme that "each network is different, and SDN allows us to build our network the way we want it without worrying about the boxes". > CJ: automation is a means, not a goal per se. We believe automation is a = key benefit that can be brought by the activation of SDN > techniques. The automation of complex service delivery is clearly an attr= active feature, for the sake of cost reduction. It may help to describe how such cost effectiveness is achieved. I am assuming getting rid of the genius who knows the network is one effective cost-saving. Is fostering competition among vendors another? > CJ: you'd be surprised by the number of networks that use COPS-PR impleme= ntations for the sake of bandwidth management in >the access...This is a protocol (along with the related SPPI-formatted inf= ormation) that is supported by at least a couple of vendors >and which is deployed in the operational field (at least a couple of netwo= rks operated by some of Orange's affiliates). As for your >suggestion, I'm not sure what you mean as we see programmability as a feat= ure. > ok, i take that back. I know COPS went through a lot of battles at IETF and seemed defeated. > CJ: I certainly recognize there are plenty of functional components that = have been specified and standardized (for some of them) >for quite some time. And I also recognize we may have not listed your favo= rite tool :-) > Agreed. My intention was to point out relevance. From a historical perspect= ive SS7 was doing data/control separation before half the IETF population was born ;-> Whereas i had no clue COPS was being used. > CJ: thank you! That said, the point of the draft is certainly not to adop= t a cynical position towards SDN techniques - beyond the > SDN wording, we are true "SDN believers", provided we keep in mind a few = things like this is not a one-size-fits-all solution, I dont think there will ever be a one size fits all. >performance and scalability must be taken into account as a function of th= e number and the nature of services to be delivered and >that the major technical challenges reside in the ability to combine the 4= meta-functional blocks that we briefly introduce in the >document. That is, for example, take the results of a (CCP-based) negotiat= ion of service parameters between the customer and the >service provider as an input that could gracefully feed a path computation= module. > Indeed interesting idea. > I have to say i was a little disappointed on the number of bytes you allo= cated to ForCES on this document. Mentioning ForCES in the same breath as R= FC 1383 is rather harsh! > > CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are i= nteresting approaches aout there that are probably part of the global SDN l= andscape. It's up to us to pick the technology that suits best. > True - but you are writing a generic draft, so I just wanted you to be fair= ;-> We have enough of the big gorilla marketing machine like ONF that is ignoring the facts. It is not even an orange apple comparison to put ForCES and RFC 1383 in the same basket. ForCES is a generic datapath/control separation _architecture_ unlike the basic RFC 1383 specific feature; or OF with a specific datapath or COPS with a specific bandwidth enforcement domain perspective etc. > CJ: not exactly. We do not deny complexity, as long as it is hidden to ou= r *customers*. > That is very interesting perspective. > CJ: I don't think there is a single answer to your comment. Let me give y= ou an example: within the context of our current inter- >domain VPN service offering, we need to request PE resources with peering = partners, in a bilateral fashion. The corresponding >negotiation remains paper- and fax- (yes fax)based, and I can tell you it = takes quite some time the get the proprer resources right, >let alone the CE-PE connection (especially in a dual homign context, depen= ding on the location of the PE routers and the customer >premises). Based upon an apporpriately-formatted CPP template, we believe = that the inherent complexity should be adequately >balanced by a dramatic improvement of the time-to-deliver the service, fro= m several weeks to a few days, if not hours. This will >have a dramatic impact on the overall cost. > Agreed above example as a clear use case with an obvious win. It was eye-opening for me to read. > CJ: NFV is part of the global SDN landscape from my perspective. This is = why we see information models and data (including >policy provisioning info= rmation) as a key component of what you call NFV. That said, I'm not convin= ced NFV can be applied to >each and every network capability you could thin= k of, depending on the nature of the service and the impact on the amount o= f >(configuration information) traffic that needs to be exchanged between the= control and the data planes, for example. I doubt it can be applied to every network capability, but: One thing i didnt comment on earlier was the 5 year "centralized control" plan ;-> I saw somewhere that in data centres it is 1-2 year before hardware is replaced. I would suspect this would affect your approach to "cost customization" would be very different compared to data centres. Wouldnt it then be logical you want your boxes from vendors to allow you to inject more network functions over their lifetime? This is what NFV is suggesting. > CJ: that's certainly important, this is clearly not a taboo, but this is = also something tht is not SDN-specific (at least as far asFT >Orange is con= cerned). > So you dont mind being locked-in as long as the vendor meets those requirements you specify? Vendor lock-in has been considered an SDN motivation from a sales perspecti= ve. The arguement goes something like this (at least for ForCES): allow an architecture that is _standard_ to evolve. It means you can buy different part from different competing vendors (instead of a mainframe from IBM you = buy a PC chasis from Vendor X, VGA card from Y, OS from Z, etc); the consumer being you benefits from cost reduction and no specific lock in (not entirely 100% given some OS vendors could still lock you in). > b) tends to run on these tiny cpus (to which you are locked until you buy= the next GodBox). > CJ; right, but we were actually discussing the fuzz around separated cont= rol and forwarding planes. We understand the SDN approach, but we'd appreci= ate a more specific/accurate wording for the sake of undertsnadability. > I think the way you expressed then sounded like you were dismissing the value of standardizing that part. cheers, jamal From yulei.frank.wu@gmail.com Tue Apr 16 23:01:07 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAFA21F97C2 for ; Tue, 16 Apr 2013 23:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhuY6zAGWjDB for ; Tue, 16 Apr 2013 23:01:07 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9946B21F97C0 for ; Tue, 16 Apr 2013 23:01:06 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id a15so531474eae.15 for ; Tue, 16 Apr 2013 23:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:reply-to:subject:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=WtDnXM9V39Gj5WMbd1W/YvhC6q6fvTiKVG5KhwP0LPE=; b=dLYUYJAl/Ei3pGhRU8c2VCY0GEwLIrgJEe//ubxT5Pc7DdVeXQS370+jhBZS5kSrl+ N6OaldDGLys4kxM1cOkvhuqqzxs7gbFx5B7Cz9MFvzFS4acHenXkAy3+mFzoPJEXzTAP TIk+chWQTNWOQ/zEhEF1l2nL1VtwgFT/KKCQPgdPdlIO6vPlXYiJrIFEZC7cQML+Cg7u aJBVayJDSa7ZC3qjxz8obZJKnJukMVhhnfBF6n1Rt+ZWYN8AhKPwpCtZSvL/Ni8saGNj PMjDCQv6Mwi35jquxt/rlfR6ptY4MEzrUfpXAUpf3mcAxEROOn5mSyykCi1OZmmkTFBo rw1A== X-Received: by 10.15.34.199 with SMTP id e47mr14534739eev.35.1366178465527; Tue, 16 Apr 2013 23:01:05 -0700 (PDT) Received: from ylwu-THINK (host109-88-static.28-87-b.business.telecomitalia.it. [87.28.88.109]) by mx.google.com with ESMTPS id x42sm6596164eee.0.2013.04.16.23.01.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Apr 2013 23:01:04 -0700 (PDT) Date: Wed, 17 Apr 2013 13:59:06 +0800 From: "Yulei Wu" To: sdn X-Priority: 3 X-GUID: 553DEB68-7BAA-4A22-A719-B9DCDA362CBA X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201304171359045217465@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart272457204818_=----" Subject: [Sdn] CFPs of CSS 2013 conference with 4 workshops X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "yulei.frank.wu" List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 06:01:07 -0000 This is a multi-part message in MIME format. ------=_001_NextPart272457204818_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 QXBvbG9naWVzIGlmIHlvdSByZWNlaXZlZCBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBDU1MtMTMg Q0ZQcyB3aXRoIDQgd29ya3Nob3BzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2Fs bCBmb3IgUGFwZXJzIGZvciB0aGUgNXRoIEludGVybmF0aW9uYWwgU3ltcG9zaXVtIG9uDQpDeWJl cnNwYWNlIFNhZmV0eSBhbmQgU2VjdXJpdHkgKENTUyAyMDEzKQ0KDQoNCi0tDQpIaWdobGlnaHQ6 IA0KDQpUaGUgc3ltcG9zaXVtcy93b3Jrc2hvcHMgKFNRQy0xMy9TUlRDLTEzL1RydXN0RGF0YS0x My9ITkNDLTEzKSB3aWxsIGJlIGhlbGQgaW4gY29uanVuY3Rpb24gDQp3aXRoIENTUy0xMy4gTW9y ZSBzeW1wb3NpdW1zL3dvcmtzaG9wcyB3aWxsIGJlIGFkZGVkIGxhdGVyLg0KLS0gDQoNCg0KT3Jn YW5pemVyczoNCkNlbnRyYWwgU291dGggVW5pdmVyc2l0eSwgQ2hpbmENCk5hdGlvbmFsIFVuaXZl cnNpdHkgb2YgRGVmZW5zZSBUZWNobm9sb2d5LCBDaGluYQ0KSHVuYW4gVW5pdmVyc2l0eSwgQ2hp bmENCkppc2hvdSBVbml2ZXJzaXR5LCBDaGluYQ0KDQoNClRlY2huaWNhbCBDby1TcG9uc29yc2hp cDoNCkRlYWtpbiBVbml2ZXJzaXR5LCBBdXN0cmFsaWENClNwcmluZ2VyIExlY3R1cmUgTm90ZXMg aW4gQ29tcHV0ZXIgU2NpZW5jZQ0KU2Nob29sIG9mIEluZm9ybWF0aW9uIFNjaWVuY2UgYW5kIEVu Z2luZWVyaW5nLCBDZW50cmFsIFNvdXRoIFVuaXZlcnNpdHksIENoaW5hDQpTY2hvb2wgb2YgU29m dHdhcmUsIENlbnRyYWwgU291dGggVW5pdmVyc2l0eSwgQ2hpbmENCg0KDQpWZW51ZSAmIERhdGVz Og0KWmhhbmdqaWFqaWUsIENoaW5hLCBOb3ZlbWJlciAxMy0xNSwgMjAxMw0KDQoNCkNvbmZlcmVu Y2UgV2Vic2l0ZToNCmh0dHA6Ly90cnVzdC5jc3UuZWR1LmNuL2NvbmZlcmVuY2UvY3NzMjAxMw0K DQoNCkludHJvZHVjdGlvbg0KDQpBIGxhcmdlIGZyYWN0aW9uIG9mIHRoZSBwb3B1bGF0aW9uIGlu IHRoZSB3b3JsZCBub3cgc3BlbmRzIGEgZ3JlYXQgZGVhbCBvZiB0aW1lIGluIGN5YmVyc3BhY2Uu IEN5YmVyc3BhY2UgaGFzIGJlY29tZSBhIGNyaXRpY2FsIGluZnJhc3RydWN0dXJlIHRoYXQgaXMg ZW1iZWRkZWQgaW4gYWxtb3N0IGFsbCBvdGhlciBjcml0aWNhbCBpbmZyYXN0cnVjdHVyZXMgYW5k IGVuYWJsZXMgZXZlcnkgbW92ZW1lbnQgb2YgaHVtYW4gc29jaWV0eS4gSXQgaXMgdGh1cyB2ZXJ5 IG11Y2ggaW4gdGhlIHB1YmxpYyBpbnRlcmVzdCB0byBoYXZlIGEgc2FmZSBhbmQgc2VjdXJlIGN5 YmVyc3BhY2UuIA0KDQpJbiB0aGUgcGFzdCBzZXZlcmFsIHllYXJzLCB0aGVyZSBoYXMgYmVlbiBh IGxhcmdlIG51bWJlciBvZiBhdHRhY2tzIGluIGN5YmVyc3BhY2UsIHN1Y2ggYXMgYXR0YWNrcyBv biB0aGUgSW50ZXJuZXQsIGF0dGFja3Mgb24gZW1iZWRkZWQvcmVhbC10aW1lIGNvbXB1dGluZyBh bmQgY29udHJvbCBzeXN0ZW1zLCBhbmQgYXR0YWNrcyBvbiBkZWRpY2F0ZWQgY29tcHV0aW5nIGZh Y2lsaXRpZXMuIE1hbnkgcmVzZWFyY2ggZWZmb3J0cyBoYXZlIGJlZW4gbWFkZSB0byBhY2hpZXZl IGN5YmVyc3BhY2Ugc2FmZXR5IGFuZCBzZWN1cml0eSwgc3VjaCBhcyBibG9ja2luZyBhbmQgbGlt aXRpbmcgdGhlIGltcGFjdCBvZiBjb21wcm9taXNlLCBlbmFibGluZyBhY2NvdW50YWJpbGl0eSwg cHJvbW90aW5nIGRlcGxveW1lbnQgb2YgZGVmZW5zZSBzeXN0ZW1zLCBhbmQgZGV0ZXJyaW5nIHBv dGVudGlhbCBhdHRhY2tlcnMgYW5kIHBlbmFsaXppbmcgYXR0YWNrZXJzLiANCg0KSW4gdGhpcyBj b250ZXh0LCB3ZSB3aWxsIGZvY3VzIG91ciBwcm9ncmFtIG9uIGN5YmVyc3BhY2Ugc2FmZXR5IGFu ZCBzZWN1cml0eSwgc3VjaCBhcyBhdXRoZW50aWNhdGlvbiwgYWNjZXNzIGNvbnRyb2wsIGF2YWls YWJpbGl0eSwgaW50ZWdyaXR5LCBwcml2YWN5LCBjb25maWRlbnRpYWxpdHksIGRlcGVuZGFiaWxp dHkgYW5kIHN1c3RhaW5hYmlsaXR5IGlzc3VlcyBvZiBjeWJlcnNwYWNlLiBUaGUgYWltIG9mIHRo aXMgc3ltcG9zaXVtIGlzIHRvIHByb3ZpZGUgYSBsZWFkaW5nIGVkZ2UgZm9ydW0gdG8gZm9zdGVy IGludGVyYWN0aW9uIGJldHdlZW4gcmVzZWFyY2hlcnMgYW5kIGRldmVsb3BlcnMgd2l0aCB0aGUg Y3liZXJzcGFjZSBzYWZldHkgYW5kIHNlY3VyaXR5IGNvbW11bml0aWVzLCBhbmQgdG8gZ2l2ZSBh dHRlbmRlZXMgYW4gb3Bwb3J0dW5pdHkgdG8gbmV0d29yayB3aXRoIGV4cGVydHMgaW4gdGhpcyBh cmVhLiBUaGUgc3ltcG9zaXVtIHdpbGwgYmUgYSBoaWdobHkgZm9jdXNlZCwgcHJvZmVzc2lvbmFs LCBoaWdoIHF1YWxpdHksIGFuZCBzb2NpYWwgZXZlbnQuIA0KDQpJbiB0aGUgcGFzdCwgQ1NTIGhh cyBiZWVuIGhlbGQgaW4gTWVsYm91cm5lLCBBdXN0cmFsaWEgKDIwMTIpLCBNaWxhbiwgSXRhbHkg KDIwMTEpLCBDaGVuZ2R1LCBDaGluYSAoMjAwOSksIGFuZCBTeWRuZXksIEF1c3RyYWxpYSAoMjAw OCkuIA0KDQoNClNjb3BlIGFuZCBJbnRlcmVzdHMNCg0KVGhlIENTUy0xMyBjb25mZXJlbmNlIHdp bGwgcHJvdmlkZSBhIGZvcnVtIGZvciBlbmdpbmVlcnMgYW5kIHNjaWVudGlzdHMgaW4gYWNhZGVt aWEsIGluZHVzdHJ5LCBhbmQgZ292ZXJubWVudCB0byBhZGRyZXNzIGFsbCBjaGFsbGVuZ2VzIGlu Y2x1ZGluZyB0ZWNobmljYWwsIHNhZmV0eSwgc29jaWFsLCBhbmQgbGVnYWwgaXNzdWVzIHJlbGF0 ZWQgdG8gQ3liZXJzcGFjZSBTYWZldHkgYW5kIFNlY3VyaXR5IGFuZCB0byBwcmVzZW50IGFuZCBk aXNjdXNzIHRoZWlyIGlkZWFzLCByZXN1bHRzLCB3b3JrLWluLXByb2dyZXNzIGFuZCBleHBlcmll bmNlIG9uIGFsbCBhc3BlY3RzIG9mIEN5YmVyc3BhY2UgU2FmZXR5IGFuZCBTZWN1cml0eS4gVG9w aWNzIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3QgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0 bzogDQoNCigxKSBEYXRhIGFuZCBBcHBsaWNhdGlvbnMgU2VjdXJpdHkNCjEuIERpZ2l0YWwgUmln aHRzIE1hbmFnZW1lbnQNCjIuIFNlY3VyZSBJbmZvcm1hdGlvbiBJbnRlZ3JhdGlvbiBhbmQgVHJh bnNhY3Rpb24gUHJvY2Vzc2luZw0KMy4gU2VjdXJlIFNlbWFudGljIFdlYiBhbmQgV2ViIFNlcnZp Y2VzDQo0LiBTZWN1cml0eSBpbiBFLUNvbW1lcmNlIGFuZCBNLUNvbW1lcmNlDQo1LiBTZWN1cmUg T3BlcmF0aW5nIFN5c3RlbXMNCjYuIFdhdGVybWFya2luZw0KNy4gUHJpdmFjeSBhbmQgRGF0YSBQ cm90ZWN0aW9uDQo4LiBFbWVyZ2luZyBUZWNobm9sb2dpZXMgYW5kIEFwcGxpY2F0aW9ucw0KOS4g RGF0YWJhc2UgU2VjdXJpdHkNCjEwLiBEYXRhIE1pbmluZyBTZWN1cml0eQ0KDQooMikgTmV0d29y ayBhbmQgQ29tbXVuaWNhdGlvbnMgU2VjdXJpdHkNCjEuIEF0dGFjayBDb250YWlubWVudA0KMi4g QWN0aXZlIERlZmVuc2UgVGVjaG5pcXVlcyBhbmQgU3lzdGVtcw0KMy4gQXR0YWNrIFJlY292ZXJ5 DQo0LiBJbnRlbGxpZ2VudCBEZWZlbnNlIFN5c3RlbXMNCjUuIEludGVybmV0IGFuZCBOZXR3b3Jr IEZvcmVuc2ljcw0KNi4gU3BhbSBEZXRlY3Rpb24gYW5kIFByZXZlbnRpb24NCjcuIFNlY3VyaXR5 IGZvciBBZC1Ib2MgYW5kIFNlbnNvciBOZXR3b3Jrcw0KOC4gU2VjdXJlIE5ldHdvcmsgQXJjaGl0 ZWN0dXJlcw0KOS4gRGlzdHJpYnV0ZWQgSW50cnVzaW9uIERldGVjdGlvbiAvIFByZXZlbnRpb24g U3lzdGVtcw0KMTAuIERlbmlhbC1vZi1TZXJ2aWNlIEF0dGFja3MgYW5kIENvdW50ZXJtZWFzdXJl cyANCg0KKDMpIFNvZnR3YXJlIGFuZCBTeXN0ZW1zIFNlY3VyaXR5DQoxLiBTb2Z0d2FyZSBhbmQg U3lzdGVtcyBBc3N1cmFuY2UNCjIuIFNlY3VyZSBEZXNpZ24gYW5kIFRlc3RpbmcNCjMuIFZpcnVz ZXMsIFdvcm1zLCBhbmQgT3RoZXIgTWFsaWNpb3VzIENvZGUNCjQuIFNlY3VyaXR5IFRoZW9yeSBh bmQgVG9vbHMNCjUuIFNlY3VyaXR5IGluIFBlcnZhc2l2ZSBhbmQgRW1iZWRkZWQgU3lzdGVtcw0K Ni4gQWNjZXNzIENvbnRyb2wNCjcuIFNlY3VyaXR5IGZvciBMYXJnZS1zY2FsZSBTeXN0ZW1zIGFu ZCBDcml0aWNhbCBJbmZyYXN0cnVjdHVyZXMNCjguIFNlY3VyaXR5IEF1ZGl0aW5nDQo5LiBJbnRy dXNpb24gRGV0ZWN0aW9uIFN5c3RlbSANCjEwLiBSaXNrIEFzc2Vzc21lbnQgYW5kIFJpc2sgTWFu YWdlbWVudA0KDQooNCkgQ2xvdWQgU2VjdXJpdHkNCjEuIFByYWN0aWNhbCBDcnlwdG9ncmFwaGlj IFByb3RvY29scyBmb3IgQ2xvdWQgU2VjdXJpdHkNCjIuIE11bHRpLXRlbmFuY3kgYW5kIFJlbGF0 ZWQgU2VjdXJpdHkgSXNzdWVzDQozLiBTZWN1cmUgQ2xvdWQgUmVzb3VyY2UgVmlydHVhbGl6YXRp b24gTWVjaGFuaXNtcw0KNC4gU2VjdXJlIERhdGEgTWFuYWdlbWVudCBhbmQgQ29tcHV0YXRpb24g T3V0c291cmNpbmcNCjUuIFRydXN0IGFuZCBQb2xpY3kgTWFuYWdlbWVudCBpbiBDbG91ZHMNCjYu IFNhbmRib3hpbmcgYW5kIFZNLWJhc2VkIEVuZm9yY2VtZW50cyANCjcuIE1hbmFnaW5nIFNlY3Vy aXR5IEJlbmVmaXRzIGFuZCBSaXNrcyBvZiBDbG91ZCBDb21wdXRpbmcNCjguIE5ldyBDbG91ZC1h d2FyZSBXZWIgU2VydmljZSBTZWN1cml0eSBQYXJhZGlnbXMgYW5kIE1lY2hhbmlzbXMNCjkuIE5l dHdvcmsgU2VjdXJpdHkgTWVjaGFuaXNtcyBmb3IgQ2xvdWQgQ29udGV4dHMNCjEwLiBOZXcgQXJj aGl0ZWN0dXJlcyBhbmQgRGVzaWduIE1ldGhvZHMgZm9yIERldmVsb3BpbmcgQ2xvdWQgU2Vydmlj ZXMgDQoNCig1KSBDeWJlcnNwYWNlIFNhZmV0eQ0KMS4gSWRlbnRpdHkgTWFuYWdlbWVudCBhbmQg QXV0aGVudGljYXRpb24NCjIuIFNlY3VyaXR5IGFuZCBVc2FiaWxpdHkNCjMuIFNlY3VyaXR5IGFu ZCBQcml2YWN5IGluIFNvY2lhbCBOZXR3b3Jrcw0KNC4gUHJpdmFjeSBNb2RlbHMNCjUuIFByaXZh Y3kgRW5oYW5jaW5nIFRlY2hub2xvZ2llcw0KNi4gSHVtYW4gRmFjdG9ycyBpbiBDb21wdXRlciBT ZWN1cml0eQ0KNy4gTW9kZWxpbmcgYW5kIEFuYWx5emluZyBPbmxpbmUgVXNlciBCZWhhdmlvcg0K OC4gUmlzayBBc3Nlc3NtZW50IGluIEN5YmVyIFNlY3VyaXR5DQo5LiBCZW5jaG1hcmssIEFuYWx5 c2lzIGFuZCBFdmFsdWF0aW9uIG9mIEN5YmVyIFNlY3VyaXR5DQoxMC4gSW1wbGVtZW50YXRpb24s IERlcGxveW1lbnQgYW5kIE1hbmFnZW1lbnQgb2YgQ3liZXIgU2VjdXJpdHkNCg0KDQpTdWJtaXNz aW9uIGFuZCBQdWJsaWNhdGlvbiBJbmZvcm1hdGlvbg0KDQpUaGUgYWNjZXB0ZWQgcGFwZXJzIGZy b20gdGhpcyBjb25mZXJlbmNlIHdpbGwgYmUgcHVibGlzaGVkIGJ5IFNwcmluZ2VyIExlY3R1cmUg Tm90ZXMgaW4gQ29tcHV0ZXIgU2NpZW5jZSAoRUkgaW5kZXhlZCkuIFN1Ym1pdHRlZCBwYXBlcnMg bXVzdCBub3Qgc3Vic3RhbnRpYWxseSBvdmVybGFwIHdpdGggcGFwZXJzIHRoYXQgaGF2ZSBiZWVu IHB1Ymxpc2hlZCBvciB0aGF0IGFyZSBzaW11bHRhbmVvdXNseSBzdWJtaXR0ZWQgdG8gYSBqb3Vy bmFsIG9yIGEgY29uZmVyZW5jZSB3aXRoIHByb2NlZWRpbmdzLiBQYXBlcnMgbXVzdCBiZSBjbGVh cmx5IHByZXNlbnRlZCBpbiBFbmdsaXNoLCBtdXN0IG5vdCBleGNlZWQgMTUgcGFnZXMgIChvciAy MCBwYWdlcyB3aXRoIHRoZSBvdmVyIGxlbmd0aCBjaGFyZ2UpLCBpbmNsdWRpbmcgdGFibGVzLCBm aWd1cmVzLCByZWZlcmVuY2VzIGFuZCBhcHBlbmRpeGVzLCBpbiBTcHJpbmdlciBMTkNTIEZvcm1h dCB3aXRoIFBvcnRhYmxlIERvY3VtZW50IEZvcm1hdCAoLnBkZikuIFBsZWFzZSBzdWJtaXQgeW91 ciBwYXBlciBhdCBodHRwczovL3d3dy5lYXN5Y2hhaXIub3JnL2NvbmZlcmVuY2VzLz9jb25mPWNz czIwMTMuDQoNClBhcGVycyB3aWxsIGJlIHNlbGVjdGVkIGJhc2VkIG9uIHRoZWlyIG9yaWdpbmFs aXR5LCB0aW1lbGluZXNzLCBzaWduaWZpY2FuY2UsIHJlbGV2YW5jZSwgYW5kIGNsYXJpdHkgb2Yg cHJlc2VudGF0aW9uLiBEaXN0aW5ndWlzaGVkIHBhcGVycywgYWZ0ZXIgZnVydGhlciByZXZpc2lv bnMsIHdpbGwgYmUgY29uc2lkZXJlZCBmb3IgcG9zc2libGUgcHVibGljYXRpb24gaW4gc2V2ZXJh bCBTQ0kgJiBFSSBpbmRleGVkIHNwZWNpYWwgaXNzdWVzIG9mIHByZXN0aWdpb3VzIGludGVybmF0 aW9uYWwgam91cm5hbHMuIFRoZSBwcm9ncmFtIGNvbW1pdHRlZSB3aWxsIHNlbGVjdCBhbmQgYXdh cmQgdHdvICJCZXN0IFBhcGVyIEF3YXJkcyIgZm9yIHRoaXMgY29uZmVyZW5jZS4gQnkgc3VibWl0 dGluZyBhIHBhcGVyIHRvIHRoZSBjb25mZXJlbmNlLCBhdXRob3JzIGFzc3VyZSB0aGF0IGlmIHRo ZSBwYXBlciBpcyBhY2NlcHRlZCwgYXQgbGVhc3Qgb25lIGF1dGhvciB3aWxsIGF0dGVuZCB0aGUg Y29uZmVyZW5jZSBhbmQgcHJlc2VudCB0aGUgcGFwZXIuIEZvciBuby1zaG93IGF1dGhvcnMsIHRo ZWlyIHBhcGVycyB3aWxsIGJlIHJlbW92ZWQgZnJvbSB0aGUgZGlnaXRhbCBsaWJyYXJ5IGFmdGVy IHRoZSBjb25mZXJlbmNlIGFuZCB0aGVpciBhZmZpbGlhdGlvbnMgd2lsbCBiZSBub3RpZmllZC4N Cg0KDQpJbXBvcnRhbnQgRGF0ZXMNCg0KKDEpIFBhcGVyIFN1Ym1pc3Npb24gRHVlOiAgICAgICBK dW5lIDE1LCAyMDEzIA0KKDIpIE5vdGlmaWNhdGlvbiBvZiBEZWNpc2lvbjogICBBdWd1c3QgMTUs IDIwMTMNCigzKSBDYW1lcmEtcmVhZHkgUGFwZXJzIER1ZTogICAgU2VwdGVtYmVyIDE1LCAyMDEz DQoNCg0KU3RlZXJpbmcgQ28tQ2hhaXJzDQoNCllhbmcgWGlhbmcsIERlYWtpbiBVbml2ZXJzaXR5 LCBBdXN0cmFsaWENCldhbmxlaSBaaG91LCBEZWFraW4gVW5pdmVyc2l0eSwgQXVzdHJhbGlhDQoN Cg0KR2VuZXJhbCBDby1DaGFpcnMNCg0KR3VvanVuIFdhbmcsIENlbnRyYWwgU291dGggVW5pdmVy c2l0eSwgQ2hpbmENClZpamF5IFZhcmFkaGFyYWphbiwgTWFjcXVhcmllIFVuaXZlcnNpdHksIEF1 c3RyYWxpYQ0KR3JlZ29yaW8gTWFydGluZXosIFVuaXZlcnNpdHkgb2YgTXVyY2lhLCBTcGFpbg0K DQoNClByb2dyYW0gQ28tQ2hhaXJzDQoNCkluZHJha3NoaSBSYXksIENvbG9yYWRvIFN0YXRlIFVu aXZlcnNpdHksIFVTQQ0KRGVuZ2d1byBGZW5nLCBJbnN0aXR1dGUgb2YgU29mdHdhcmUsIENoaW5l c2UgQWNhZGVteSBvZiBTY2llbmNlcywgQ2hpbmENCk11dHR1a3Jpc2huYW4gUmFqYXJhamFuLCBD aXR5IFVuaXZlcnNpdHkgTG9uZG9uLCBVSw0KDQoNClByb2dyYW0gVmljZSBDby1DaGFpcnMNCg0K KDEpIERhdGEgYW5kIEFwcGxpY2F0aW9ucyBTZWN1cml0eSBUcmFjaw0KRGkgTWEsIFVuaXZlcnNp dHkgb2YgTWljaGlnYW4tRGVhcmJvcm4sIFVTQQ0KUmFtYW4gQWRhaWtrYWxhdmFuLCBJbmRpYW5h IFVuaXZlcnNpdHkgU291dGggQmVuZCwgVVNBDQoNCigyKSBOZXR3b3JrIGFuZCBDb21tdW5pY2F0 aW9ucyBTZWN1cml0eSBUcmFjaw0KUm9iaW4gRG9zcywgRGVha2luIFVuaXZlcnNpdHksIEF1c3Ry YWxpYQ0KWXVsZWkgV3UsIENoaW5lc2UgQWNhZGVteSBvZiBTY2llbmNlcywgQ2hpbmENCg0KKDMp IFNvZnR3YXJlIGFuZCBTeXN0ZW1zIFNlY3VyaXR5IFRyYWNrDQpSb3NlIEdhbWJsZSwgVW5pdmVy c2l0eSBvZiBUdWxzYSwgVVNBDQpKaWFueHVuIExpdSwgSHVuYW4gVW5pdmVyc2l0eSBvZiBTY2ll bmNlIGFuZCBUZWNobm9sb2d5LCBDaGluYQ0KDQooNCkgQ2xvdWQgU2VjdXJpdHkgVHJhY2sNCkh1 YSBXYW5nLCBVbml2ZXJzaXR5IG9mIFNvdXRoZXJuIFF1ZWVuc2xhbmQsIEF1c3RyYWxpYQ0KRGhp cmVuIFBhdGVsLCBOSVQgU3VyYXQsIEluZGlhDQoNCig1KSBDeWJlcnNwYWNlIFNhZmV0eSBUcmFj aw0KU3RldmVuIEZ1cm5lbGwsIFBseW1vdXRoIFVuaXZlcnNpdHksIFVLDQpBdmluYXNoIFNyaW5p dmFzYW4sIEdlb3JnZSBNYXNvbiBVbml2ZXJzaXR5LCBVU0ENCg0KDQpXb3Jrc2hvcCBDby1DaGFp cnMNCg0KSmVtYWwgSC5BYmF3YWp5LCBEZWFraW4gVW5pdmVyc2l0eSwgQXVzdHJhbGlhDQpKaW4t SGVlIENobywgVS5TLiBBcm15IFJlc2VhcmNoIExhYm9yYXRvcnksIFVTQQ0KWWFuamlhbmcgWWFu ZywgSW5zdGl0dXRlIGZvciBJbmZvY29tbSBSZXNlYXJjaCwgU2luZ2Fwb3JlDQpZZW9uZy1EZW9r IEtpbSwgV29vc29uZyBVbml2ZXJzaXR5LCBLb3JlYQ0KDQoNClN5bXBvc2l1bXMvV29ya3Nob3Bz IGluIGNvbmp1bmN0aW9uIHdpdGggQ1NTIDIwMTMNCg0KKDEpIFRoZSAzcmQgSW50ZXJuYXRpb25h bCBTeW1wb3NpdW0gb24gU2VjdXJpdHkgYW5kIFF1YW50dW0gQ29tbXVuaWNhdGlvbnMgKFNRQyAy MDEzKQ0KaHR0cDovL3RydXN0LmNzdS5lZHUuY24vY29uZmVyZW5jZS9TUUMyMDEzLw0KDQooMikg VGhlIDIwMTMgSW50ZXJuYXRpb25hbCBXb3Jrc2hvcCBvbiBTZWN1cml0eSBhbmQgUmVsaWFiaWxp dHkgaW4gVHJhbnNwYXJlbnQgQ29tcHV0aW5nIChTUlRDIDIwMTMpIA0KaHR0cDovL3RydXN0LmNz dS5lZHUuY24vY29uZmVyZW5jZS9zcnRjMjAxMy8NCg0KKDMpIFRoZSAyMDEzIEludGVybmF0aW9u YWwgV29ya3Nob3Agb24gVHJ1c3QsIFNlY3VyaXR5IGFuZCBQcml2YWN5IGZvciBCaWcgRGF0YSAo VHJ1c3REYXRhIDIwMTMpIA0KaHR0cDovL3RydXN0LmNzdS5lZHUuY24vY29uZmVyZW5jZS9UcnVz dERhdGEyMDEzLw0KDQooNCkgU3BlY2lhbCBTZXNzaW9ucyBvbiBDeWJlcnNwYWNlIFNhZmV0eSBh bmQgU2VjdXJpdHkgb2YgdGhlIDIwMTMgSENGIEh1bmFuIENvbXB1dGVyIENvbmZlcmVuY2UgKEhO Q0MgMjAxMykNCg0KDQpPcmdhbml6aW5nIENvLUNoYWlycw0KDQpaaGlnYW5nIENoZW4sIENlbnRy YWwgU291dGggVW5pdmVyc2l0eSwgQ2hpbmENClpoaXlpbmcgV2FuZywgTmF0aW9uYWwgVW5pdmVy c2l0eSBvZiBEZWZlbnNlIFRlY2hub2xvZ3ksIENoaW5hDQpDaGVuZ3pob25nIFh1LCBIdW5hbiBV bml2ZXJzaXR5LCBDaGluYQ0KQmluIEh1LCBKaXNob3UgVW5pdmVyc2l0eSwgQ2hpbmENCg0KDQpQ dWJsaWNpdHkgQ28tQ2hhaXJzDQoNClBldGVyIE11ZWxsZXIsIElCTSBadXJpY2ggUmVzZWFyY2gs IFN3aXR6ZXJsYW5kIA0KWXVsZWkgV3UsIENoaW5lc2UgQWNhZGVteSBvZiBTY2llbmNlcywgQ2hp bmENClNjb3R0IEZvd2xlciwgTGlua29waW5nIFVuaXZlcnNpdHksIFN3ZWRlbg0KDQoNClB1Ymxp Y2F0aW9uIENvLUNoYWlycw0KDQpXYW5nIFlhbmcsIENlbnRyYWwgU291dGggVW5pdmVyc2l0eSwg Q2hpbmENClpoZSBUYW5nLCBDZW50cmFsIFNvdXRoIFVuaXZlcnNpdHksIENoaW5hDQoNCg0KRmlu YW5jZSBDby1DaGFpcnMNCg0KR3VpaHVhIER1YW4sIENlbnRyYWwgU291dGggVW5pdmVyc2l0eSwg Q2hpbmENCkppbiBaaGVuZywgQ2VudHJhbCBTb3V0aCBVbml2ZXJzaXR5LCBDaGluYQ0KDQoNCkxv Y2FsIEFycmFuZ2VtZW50IENoYWlyDQoNCkd1b21pbiBDYWksIEppc2hvdSBVbml2ZXJzaXR5LCBD aGluYQ0KDQoNClNlY3JldGFyaWF0cw0KDQpGYW5nIFFpLCBDZW50cmFsIFNvdXRoIFVuaXZlcnNp dHksIENoaW5hDQpUYW8gUGVuZywgQ2VudHJhbCBTb3V0aCBVbml2ZXJzaXR5LCBDaGluYQ0KDQoN CldlYm1hc3Rlcg0KDQpCaWFvIERlbmcsIENlbnRyYWwgU291dGggVW5pdmVyc2l0eSwgQ2hpbmEg DQoNCg0KQ29udGFjdA0KDQpQbGVhc2UgZW1haWwgaW5xdWlyaWVzIGNvbmNlcm5pbmcgQ1NTIDIw MTMgdG86IA0KUHJvZi4gR3VvanVuIFdhbmc6IGNzZ2p3YW5nIEFUIGdtYWlsIERPVCBjb20gYW5k IHRoZSBjb25mZXJlbmNlIG9yZ2FuaXplcnMgKGNzczIwMTN6aGFuZ2ppYWppZSBBVCBnbWFpbCBE T1QgY29tKS4NCg0KQ29weXJpZ2h0IEAgVHJ1c3RlZCBDb21wdXRpbmcgSW5zdGl0dXRlLCBDU1UN Cmh0dHA6Ly90cnVzdC5jc3UuZWR1LmNuLw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0= ------=_001_NextPart272457204818_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Apologies if you received multiple copies&nb= sp;of this CSS-13 CFPs with 4 workshops.
 
---------------------------------------------------------------------= --------------
Call for Papers for the 5th Internation= al Symposium on
Cyberspace Safety and Security (CSS 2013)
 
 
--
Highlight: 
 
The symposiums/workshops (SQC-13/SRTC-13/TrustData-13/HNCC-= 13) will be held in conjunction 
with CSS-13. More symposiums/workshops will = be added later.
-- 
 
 
Organizers:
Central South University, China
National University of Defense Technology, C= hina
Hunan University, China
Jishou University, China
 
 
Technical Co-Sponsorship:
Deakin University, Australia
Springer Lecture Notes in Computer Science
School of Information Science and Engineerin= g, Central South University, China
School of Software, Central South University= , China
 
 
Venue & Dates:
Zhangjiajie, China, November 13-15, 2013
 
 
Conference Website:
http://trust.csu.edu.cn/conference/css2013
 
 
Introduction
 
A large fraction of the population in&n= bsp;the world now spends a great deal o= f time in cyberspace. Cyberspace has become&= nbsp;a critical infrastructure that is embedded&n= bsp;in almost all other critical infrastructures&= nbsp;and enables every movement of human soc= iety. It is thus very much in the = public interest to have a safe and secu= re cyberspace. 
 
In the past several years, there has&nb= sp;been a large number of attacks in cy= berspace, such as attacks on the Internet,&n= bsp;attacks on embedded/real-time computing and c= ontrol systems, and attacks on dedicated com= puting facilities. Many research efforts have&nbs= p;been made to achieve cyberspace safety and=  security, such as blocking and limiting&nbs= p;the impact of compromise, enabling accountabili= ty, promoting deployment of defense systems, = ;and deterring potential attackers and penalizing=  attackers. 
 
In this context, we will focus our = ;program on cyberspace safety and security, = such as authentication, access control, availabil= ity, integrity, privacy, confidentiality, dependabilit= y and sustainability issues of cyberspace. T= he aim of this symposium is to provide&= nbsp;a leading edge forum to foster interact= ion between researchers and developers with = the cyberspace safety and security communities,&n= bsp;and to give attendees an opportunity to&= nbsp;network with experts in this area. The&= nbsp;symposium will be a highly focused, pro= fessional, high quality, and social event. <= /DIV>
 
In the past, CSS has been held in&= nbsp;Melbourne, Australia (2012), Milan, Italy (2= 011), Chengdu, China (2009), and Sydney, Aus= tralia (2008). 
 
 
Scope and Interests
 
The CSS-13 conference will provide a fo= rum for engineers and scientists in academia= , industry, and government to address all&nb= sp;challenges including technical, safety, social,&nbs= p;and legal issues related to Cyberspace Saf= ety and Security and to present and dis= cuss their ideas, results, work-in-progress and&n= bsp;experience on all aspects of Cyberspace = Safety and Security. Topics of particular in= terest include, but are not limited to: = ;
 
(1) Data and Applications Security
1. Digital Rights Management
2. Secure Information Integration and Transa= ction Processing
3. Secure Semantic Web and Web Services=
4. Security in E-Commerce and M-Commerce
5. Secure Operating Systems
6. Watermarking
7. Privacy and Data Protection
8. Emerging Technologies and Applications
9. Database Security
10. Data Mining Security
 
(2) Network and Communications Security
1. Attack Containment
2. Active Defense Techniques and Systems
3. Attack Recovery
4. Intelligent Defense Systems
5. Internet and Network Forensics
6. Spam Detection and Prevention
7. Security for Ad-Hoc and Sensor Netwo= rks
8. Secure Network Architectures
9. Distributed Intrusion Detection / Prevent= ion Systems
10. Denial-of-Service Attacks and Countermeasures=  
 
(3) Software and Systems Security
1. Software and Systems Assurance
2. Secure Design and Testing
3. Viruses, Worms, and Other Malicious = Code
4. Security Theory and Tools
5. Security in Pervasive and Embedded S= ystems
6. Access Control
7. Security for Large-scale Systems and = ;Critical Infrastructures
8. Security Auditing
9. Intrusion Detection System 
10. Risk Assessment and Risk Management
 
(4) Cloud Security
1. Practical Cryptographic Protocols for Clo= ud Security
2. Multi-tenancy and Related Security Issues=
3. Secure Cloud Resource Virtualization Mech= anisms
4. Secure Data Management and Computation&nb= sp;Outsourcing
5. Trust and Policy Management in Cloud= s
6. Sandboxing and VM-based Enforcements 
7. Managing Security Benefits and Risks = ;of Cloud Computing
8. New Cloud-aware Web Service Security = ;Paradigms and Mechanisms
9. Network Security Mechanisms for Cloud&nbs= p;Contexts
10. New Architectures and Design Methods&nbs= p;for Developing Cloud Services 
 
(5) Cyberspace Safety
1. Identity Management and Authentication
2. Security and Usability
3. Security and Privacy in Social Netwo= rks
4. Privacy Models
5. Privacy Enhancing Technologies
6. Human Factors in Computer Security
7. Modeling and Analyzing Online User B= ehavior
8. Risk Assessment in Cyber Security
9. Benchmark, Analysis and Evaluation of&nbs= p;Cyber Security
10. Implementation, Deployment and Management&nbs= p;of Cyber Security
 
 
Submission and Publication Information
 
The accepted papers from this conference&nbs= p;will be published by Springer Lecture Note= s in Computer Science (EI indexed). Submitte= d papers must not substantially overlap with=  papers that have been published or tha= t are simultaneously submitted to a journal&= nbsp;or a conference with proceedings. Papers&nbs= p;must be clearly presented in English, must=  not exceed 15 pages  (or 20 pages=  with the over length charge), including&nbs= p;tables, figures, references and appendixes, in&= nbsp;Springer LNCS Format with Portable Document&= nbsp;Format (.pdf). Please submit your paper = ;at https://www.easychair.org/conferences/?conf=3Dcss2013.
 
Papers will be selected based on their&= nbsp;originality, timeliness, significance, relevance, = ;and clarity of presentation. Distinguished paper= s, after further revisions, will be consider= ed for possible publication in several SCI&n= bsp;& EI indexed special issues of prest= igious international journals. The program commit= tee will select and award two "Best Pap= er Awards" for this conference. By submittin= g a paper to the conference, authors as= sure that if the paper is accepted, at&= nbsp;least one author will attend the confer= ence and present the paper. For no-show = ;authors, their papers will be removed from&= nbsp;the digital library after the conference&nbs= p;and their affiliations will be notified.
 
 
Important Dates
 
(1) Paper Submission Due:     = ;  June 15, 2013 
(2) Notification of Decision:   August&= nbsp;15, 2013
(3) Camera-ready Papers Due:    Se= ptember 15, 2013
 
 
Steering Co-Chairs
 
Yang Xiang, Deakin University, Australia
Wanlei Zhou, Deakin University, Australia
 
 
General Co-Chairs
 
Guojun Wang, Central South University, China=
Vijay Varadharajan, Macquarie University, Austral= ia
Gregorio Martinez, University of Murcia, Spa= in
 
 
Program Co-Chairs
 
Indrakshi Ray, Colorado State University, US= A
Dengguo Feng, Institute of Software, Chinese=  Academy of Sciences, China
Muttukrishnan Rajarajan, City University London,&= nbsp;UK
 
 
Program Vice Co-Chairs
 
(1) Data and Applications Security Track
Di Ma, University of Michigan-Dearborn, USA<= /DIV>
Raman Adaikkalavan, Indiana University South = ;Bend, USA
 
(2) Network and Communications Security Trac= k
Robin Doss, Deakin University, Australia
Yulei Wu, Chinese Academy of Sciences, = China
 
(3) Software and Systems Security Track
Rose Gamble, University of Tulsa, USA
Jianxun Liu, Hunan University of Science&nbs= p;and Technology, China
 
(4) Cloud Security Track
Hua Wang, University of Southern Queensland,=  Australia
Dhiren Patel, NIT Surat, India
 
(5) Cyberspace Safety Track
Steven Furnell, Plymouth University, UK
Avinash Srinivasan, George Mason University, = ;USA
 
 
Workshop Co-Chairs
 
Jemal H.Abawajy, Deakin University, Australia
Jin-Hee Cho, U.S. Army Research Laboratory,&= nbsp;USA
Yanjiang Yang, Institute for Infocomm Resear= ch, Singapore
Yeong-Deok Kim, Woosong University, Korea
 
 
Symposiums/Workshops in conjunction with CSS = ;2013
 
(1) The 3rd International Symposium on = Security and Quantum Communications (SQC 2013)
http://trust.csu.edu.cn/conference/SQC2013/
 
(2) The 2013 International Workshop on = Security and Reliability in Transparent Computing=  (SRTC 2013) 
http://trust.csu.edu.cn/conference/srtc2013/
 
(3) The 2013 International Workshop on = Trust, Security and Privacy for Big Data&nbs= p;(TrustData 2013) 
http://trust.csu.edu.cn/conference/TrustData2013/
 
(4) Special Sessions on Cyberspace Safety&nb= sp;and Security of the 2013 HCF Hunan C= omputer Conference (HNCC 2013)
 
 
Organizing Co-Chairs
 
Zhigang Chen, Central South University, Chin= a
Zhiying Wang, National University of Defense=  Technology, China
Chengzhong Xu, Hunan University, China
Bin Hu, Jishou University, China
 
 
Publicity Co-Chairs
 
Peter Mueller, IBM Zurich Research, Switzerl= and 
Yulei Wu, Chinese Academy of Sciences, = China
Scott Fowler, Linkoping University, Sweden
 
 
Publication Co-Chairs
 
Wang Yang, Central South University, China
Zhe Tang, Central South University, China
 
 
Finance Co-Chairs
 
Guihua Duan, Central South University, China=
Jin Zheng, Central South University, China
 
 
Local Arrangement Chair
 
Guomin Cai, Jishou University, China
 
 
Secretariats
 
Fang Qi, Central South University, China
Tao Peng, Central South University, China
 
 
Webmaster
 
Biao Deng, Central South University, China&n= bsp;
 
 
Contact
 
Please email inquiries concerning CSS 2013&n= bsp;to: 
Prof. Guojun Wang: csgjwang AT gmail DO= T com and the conference organizers (css2013= zhangjiajie AT gmail DOT com).
 
Copyright @ Trusted Computing Institute, CSU=
http://trust.csu.edu.cn/
---------------------------------------------------------------------= --------------
------=_001_NextPart272457204818_=------ From christian.jacquenet@orange.com Wed Apr 10 05:23:57 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6961021F93BB for ; Wed, 10 Apr 2013 05:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GrhQM7POorN for ; Wed, 10 Apr 2013 05:23:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D021F8A4E for ; Wed, 10 Apr 2013 05:23:55 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0687522CA54; Wed, 10 Apr 2013 14:23:55 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D8E3727C069; Wed, 10 Apr 2013 14:23:54 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 10 Apr 2013 14:23:51 +0200 From: To: Jamal Hadi Salim , BOUCADAIR Mohamed OLNC/OLN Date: Wed, 10 Apr 2013 14:23:49 +0200 Thread-Topic: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt Thread-Index: Ac414HhOYIB3rPg0Tvek/PLjKWCecQAAuPrw Message-ID: <14742_1365596634_516559DA_14742_324_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A7C596F2B@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB9CFC424@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421 X-Mailman-Approved-At: Mon, 22 Apr 2013 08:01:20 -0700 Cc: "forces@ietf.org" , "sdn@irtf.org" Subject: Re: [Sdn] TR: I-D Action: draft-sin-sdnrg-sdn-approach-00.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:23:57 -0000 Hello Jamal, Many thanks for your detailed feedback. I'll let my fellow colleague furthe= r comment, but here's a first shot of responses from my side - inline.=20 [snip] while the title is very specific/descriptive, it was a little hard to extra= ct the central message upfront. If i was to sum up your message: This document provides an _operator perspective_ on what SDN needs are; and= also serves to offer advice to network operators? CJ: it's mostly a provider's perspective on current SDN hype (and beyond). = I think the "advice" wording is a bit strong - the draft is rather meant to= list a few things one should not forget when considering the use of SDN te= chniques to improve network service delivery procedures. The document injects a dose of pragmatism about inter-working with existing= infrastructre. It took me a re-read to understand your draft is pushing an SDN theme of au= tomation as the desired end goal. Did i get this right? CJ: automation is a means, not a goal per se. We believe automation is a ke= y benefit that can be brought by the activation of SDN techniques. The auto= mation of complex service delivery is clearly an attractive feature, for th= e sake of cost reduction. Maybe your doc needs to break down what programmability aspect is needed fr= om an operator perspective (CLI aka netconf, Policy management, service man= agement, control-datapath separation etc). And, sorry, who is deploying CO= PS out there? CJ: you'd be surprised by the number of networks that use COPS-PR implement= ations for the sake of bandwidth management in the access...This is a proto= col (along with the related SPPI-formatted information) that is supported b= y at least a couple of vendors and which is deployed in the operational fie= ld (at least a couple of networks operated by some of Orange's affiliates).= As for your suggestion, I'm not sure what you mean as we see programmabili= ty as a feature. Or perhaps your text on COPS was intended to emphasizw the point that nothi= ng is new here? why not mention SS7 then (which is still in deployment)? CJ: I certainly recognize there are plenty of functional components that ha= ve been specified and standardized (for some of them) for quite some time. = And I also recognize we may have not listed your favorite tool :-)=20 Overall, I think theres a lot of words of wisdom as well as a good measure = of cynicism against some of the over-marketing of SDN(which i empathize wit= h). CJ: thank you! That said, the point of the draft is certainly not to adopt = a cynical position towards SDN techniques - beyond the SDN wording, we are = true "SDN believers", provided we keep in mind a few things like this is no= t a one-size-fits-all solution, performance and scalability must be taken i= nto account as a function of the number and the nature of services to be de= livered and that the major technical challenges reside in the ability to co= mbine the 4 meta-functional blocks that we briefly introduce in the documen= t. That is, for example, take the results of a (CCP-based) negotiation of s= ervice parameters between the customer and the service provider as an input= that could gracefully feed a path computation module. Thanks for pointing out that OF is not the end-all-be-all and that Control-= datapath separation is merely infrastructure requirement in the larger pict= ure (and, yes ForCES falls under the same umbrella). I have to say i was a little disappointed on the number of bytes you alloca= ted to ForCES on this document. Mentioning ForCES in the same breath as RFC= 1383 is rather harsh! CJ: ha, ha! Well again, we don't mean to be rude or cynical - there are int= eresting approaches aout there that are probably part of the global SDN lan= dscape. It's up to us to pick the technology that suits best. from your sections 1 and 2 (it was hard to extract this): The (operator) "network is getting more complex"; ATAWAD is making it worse= then you talk about desire from operator perspective is to create and deli= ver services despite the presence of such complexities in a manner which "e= volves easily, remains scalable, robust and available (even in presence of = DOS attacks)" But also you ask for "cost effectiveness". CJ: right. 1) On the issue of complexity, an interesting sample was illustrated by sli= de 6 from D. Meyer here: http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-0.pdf CJ: indeed. 2) And if i was to correlate Dave's slide to some food analogy: Equipment vendors are in the business of selling cookies (chocolate-chip, v= anilla, ginger, etc of different sizes and shapes, etc) created via some we= ll understood "factory" assembly line. Look at all those cookies in the sli= de. CJ: and the factory assembly is precisely where it gets really tricky. I am reading your view to be: the existing cookie-cut approach is _ok_ as l= ong as the vendors provide you ways to automate and hide that complexity. CJ: not exactly. We do not deny complexity, as long as it is hidden to our = *customers*. But if that is the case, isnt it contradictory to also ask for (what i am a= ssuming to be capital) cost effectiveness? more cookies will cost more, no?= And more smart people figuring ways to give you atkins diet using cookies= is also gonna cost you more. CJ: I don't think there is a single answer to your comment. Let me give you= an example: within the context of our current inter-domain VPN service off= ering, we need to request PE resources with peering partners, in a bilatera= l fashion. The corresponding negotiation remains paper- and fax- (yes fax)b= ased, and I can tell you it takes quite some time the get the proprer resou= rces right, let alone the CE-PE connection (especially in a dual homign con= text, depending on the location of the PE routers and the customer premises= ). Based upon an apporpriately-formatted CPP template, we believe that the = inherent complexity should be adequately balanced by a dramatic improvement= of the time-to-deliver the service, from several weeks to a few days, if n= ot hours. This will have a dramatic impact on the overall cost. My view of the power of SDN is ability to be able to inject new Network Fun= ctions and be able to elongate life times of existing equipment (and all ne= twork functions become programmable). i.e in the ideal scenario I should be= able to inject a new network function in an existing box without playing a= crobatics with how to hack some tables in a distributed system. Whats your = view of NFV? CJ: NFV is part of the global SDN landscape from my perspective. This is wh= y we see information models and data (including policy provisioning informa= tion) as a key component of what you call NFV. That said, I'm not convinced= NFV can be applied to each and every network capability you could think of= , depending on the nature of the service and the impact on the amount of (c= onfiguration information) traffic that needs to be exchanged between the co= ntrol and the data planes, for example. One thing you left out as an operator desire is "vendor lock-in". Is this n= ot an important detail to you or it is taboo to talk about? CJ: that's certainly important, this is clearly not a taboo, but this is al= so something tht is not SDN-specific (at least as far asFT Orange is concer= ned). On some of the expressed cynicsm in the document that i disagree with: I think you are under-valuing the control-data separation standardization s= uch as the one pushed forward by ForCES in section 3.1. "tautology" by stating that vendors have been doing for years software based control et= c. The SDN emphasis is: a) the control-data path separation is proprietary in those boxes CJ: correct. b) tends to run on these tiny cpus (to which you are locked until you buy t= he next GodBox). CJ; right, but we were actually discussing the fuzz around separated contro= l and forwarding planes. We understand the SDN approach, but we'd appreciat= e a more specific/accurate wording for the sake of undertsnadability. My coffee-defined-energy is still high and I could say more - but i think i= threw in a lot of text there... CJ: thanks again for this interesting discussion. We're looking forward to = hearing from you all! Cheers, Christian. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you.