Everything is ephemeral if the assumptions of persistence = no longer hold true. E.g. A device config-file is stored in SSD and the SSD= goes bad due to which device boots from a default-config in other persiste= nt storage.

So in the example you gave, the state specified in the confi= g-file is management plane subject to the assumption that the entire system= that creates state from the remote config-file does not have any failure.<= /div>

The time-function I used in my example was to illustrat= e that it is not a given that a static-route is control or mgmt state if we= don't take into context the operational model. It was not to imply tha= t time-function is sufficient to determine which plane it is in. =C2=A0

Sri

On Thu, Mar 6, 2014 at 2:13 AM, Russ White <= span dir=3D"ltr"><russ= w@riw.us> wrote:

The problem is everything is ephemeral for some period of time... It's = all a matter of scale. Time functions generally don't work for differen= tiating control and management, IMHO. You might say, "survives a reboo= t," but there are problems here as well, for instance a lot of boxes b= oot with a configuration that just loads a configuration file from elsewher= e -- does this mean everything is ephemeral?

:-)

Russ

<><
russw@riw.us
Ericsson

> On Mar 6, 2014, at 2:08 AM, Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:
>
> Adding to the discussion at the mic of draft-haleplidis-sdnrg-layer-te= rminology -
>
> The key determining factor between control v/s mgmt is the ephemeral v= /s persistent nature of state.
>
> However the operational model of configuring a network device where st= ate is created (and reflected even in forwarding) and then made persistent = in a separate config-operation can cause confusion in the determination. >
> E.g. If a static-route is configured it is part of the control-plane i= f a second operation is required to makes it persistent ! Only after the se= cond operation does it become part of the management plane.
>
>
> Sri
>

> _______________________________________________
> sdn mailing list
> sdn@irtf.org
> https://www.irtf.org/mailman/listinfo/sdn

_______________________________________________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn

--047d7b10cb890a770b04f3ede0d8-- From nobody Thu Mar 6 02:53:42 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC31A0249 for ; Thu, 6 Mar 2014 02:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 qNbIRXr7zImF for ; Thu, 6 Mar 2014 02:53:37 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 210D01A0233 for ; Thu, 6 Mar 2014 02:53:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DC714106F90; Thu, 6 Mar 2014 11:53:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhMuJx98E4Ms; Thu, 6 Mar 2014 11:53:32 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id BEEA5106E91; Thu, 6 Mar 2014 11:53:22 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 6 Mar 2014 11:53:01 +0100 From: Dirk Kutscher To: Roland Bless , "sdn@irtf.org" Thread-Topic: [Sdn] Reference Layer Model Thread-Index: AQHPOSWlFCwv3QMeqU+ezJyBVH4oFJrT3tcg Date: Thu, 6 Mar 2014 10:53:00 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249639D09B1@PALLENE.office.hd> References: <53184BA7.8050209@kit.edu> In-Reply-To: <53184BA7.8050209@kit.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.211] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/wWbDdLn3W6SrPD8Nc0WPHlQXO3I Subject: Re: [Sdn] Reference Layer Model X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 10:53:40 -0000 Hi, For illustrating the different and relationship of control and management p= lane, wouldn't the approach in figure 1 of https://www.opennetworking.org/images/stories/downloads/sdn-resources/techn= ical-reports/SDN-architecture-overview-1.0.pdf be applicable here? Best regards, Dirk > -----Original Message----- > From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Roland Bless > Sent: Donnerstag, 6. M=E4rz 2014 11:19 > To: sdn@irtf.org > Subject: [Sdn] Reference Layer Model >=20 > Hi, >=20 > some remarks w.r.t. slide 7 of > http://www.ietf.org/proceedings/89/slides/slides-89-sdnrg-6.pdf >=20 > 1.) (related to Scott Brim's comment) > I guess what cause slight confusion was the fact that two boxes in the mi= ddle > (control/management) are labeled Control Plane and Management Plane. > They are rather (logical) entities residing in the respective planes, e.g= ., the > Control Plane is made up of a set of Control Entities working together. S= o > Control Plane and Management Plane should not be written _into_ the > boxes (maybe beneath). > Even more confusing are the blocks "Forwarding Plane" and "Operational > Plane" inside the network device, their are rather entities/functional bl= ocks > belonging to these planes. >=20 > 2.) (related to Dirk Kutscher's comment) Sometimes Management Plane > actions may trigger related control actions, so some (optional) horizonta= l > interaction between the two boxes in the middle is missing IMHO, too. >=20 > Regards, > Roland >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From nobody Thu Mar 6 03:12:20 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1F01A0297 for ; Thu, 6 Mar 2014 03:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 43B2pNKxqW5Z for ; Thu, 6 Mar 2014 03:12:08 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0D1A025F for ; Thu, 6 Mar 2014 03:12:07 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id jx11so2478796veb.3 for ; Thu, 06 Mar 2014 03:12:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=C4O0pADsdiRQ+KTBOv2UAVIZdXNLA7GhpZIwJm4LZ7Y=; b=akodNxSpYW/Pi7/nSdtcuA1JzGwIPEPerDxFGvPQDWcITR9OzRb6GR5/yuOPGb8MA/ hc9dkHiciJYKkoAloyDngFcrJY1TisVF7sBJdjXdoeLi9UAikjEsk4VBpyPbvK2VpkXM xgCryECGXHF4oCeyFmAibdvgqjMsnyGOqcE1zeEkIOOrfMz8H//Ygg/6vN38DcrrBODN x33belH5OmJ8ZAg4DNmkcMNj55KwBEe9qZs9jtIisxL8dJybjQ2iG7uoMWkqyCg7Q7xm zCD/qykt5KWJEwpBtyX3qrJKGjLMDitE2zVKa+Xgz9NRZBccbOS4bW+TJ95KsDr7/YUI 987A== X-Gm-Message-State: ALoCoQmXN6xhTPH27HYjZ84MqZtk3dw/YK+pmnYjRUz9IpLgFdesBTJviT6JoUZvujVm9TZZLy03 X-Received: by 10.58.200.229 with SMTP id jv5mr4668504vec.15.1394104323737; Thu, 06 Mar 2014 03:12:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.2.196 with HTTP; Thu, 6 Mar 2014 03:11:43 -0800 (PST) In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249639D09B1@PALLENE.office.hd> References: <53184BA7.8050209@kit.edu> <82AB329A76E2484D934BBCA77E9F5249639D09B1@PALLENE.office.hd> From: Jamal Hadi Salim Date: Thu, 6 Mar 2014 06:11:43 -0500 Message-ID: To: Dirk Kutscher Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/hgOJBYkzjMEIhxMBRh-bpjI9JI0 Cc: Roland Bless , "sdn@irtf.org" Subject: Re: [Sdn] Reference Layer Model X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 11:12:11 -0000 To Roland's point: The boxes on management and control are abstractions. One could implement management using control interfaces. I believe this is one of the disclaimers in the draft and one of the slides Evangelos put up. I think this is one of the challenges that needs to be addressed to have some coherency as to what control vs management boundary is. The current theme on the list seems to be: ephemeral state vs config. Response to Dirk inline. On Thu, Mar 6, 2014 at 5:53 AM, Dirk Kutscher wro= te: > Hi, > > For illustrating the different and relationship of control and management= plane, wouldn't the approach in figure 1 of > https://www.opennetworking.org/images/stories/downloads/sdn-resources/tec= hnical-reports/SDN-architecture-overview-1.0.pdf > > be applicable here? > I think this document is mentioned in the latest release of the draft. Looks similar conceptually but in my view not abstract enough; example leaving out Management may be a good fit for ONF but not IETF. cheers, jamal > Best regards, > Dirk > > > > > >> -----Original Message----- >> From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Roland Bless >> Sent: Donnerstag, 6. M=E4rz 2014 11:19 >> To: sdn@irtf.org >> Subject: [Sdn] Reference Layer Model >> >> Hi, >> >> some remarks w.r.t. slide 7 of >> http://www.ietf.org/proceedings/89/slides/slides-89-sdnrg-6.pdf >> >> 1.) (related to Scott Brim's comment) >> I guess what cause slight confusion was the fact that two boxes in the m= iddle >> (control/management) are labeled Control Plane and Management Plane. >> They are rather (logical) entities residing in the respective planes, e.= g., the >> Control Plane is made up of a set of Control Entities working together. = So >> Control Plane and Management Plane should not be written _into_ the >> boxes (maybe beneath). >> Even more confusing are the blocks "Forwarding Plane" and "Operational >> Plane" inside the network device, their are rather entities/functional b= locks >> belonging to these planes. >> >> 2.) (related to Dirk Kutscher's comment) Sometimes Management Plane >> actions may trigger related control actions, so some (optional) horizont= al >> interaction between the two boxes in the middle is missing IMHO, too. >> >> Regards, >> Roland >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From nobody Thu Mar 6 03:33:04 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D74E1A02A2 for ; Thu, 6 Mar 2014 03:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 xXZKgfi1xM3H for ; Thu, 6 Mar 2014 03:33:00 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5371A0272 for ; Thu, 6 Mar 2014 03:33:00 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id B332B1FF5E; Thu, 6 Mar 2014 12:32:55 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id C35311FF58; Thu, 6 Mar 2014 12:32:54 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 24C4C378378; Thu, 6 Mar 2014 12:32:54 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 6 Mar 2014 12:32:53 +0100 From: Kostas Pentikousis To: "Mcdysan, David E" , "sdn@irtf.org" Date: Thu, 6 Mar 2014 12:32:52 +0100 Thread-Topic: [Sdn] FW: New Version Notification for draft-haleplidis-sdnrg-layer-terminology-04.txt Thread-Index: Ac85KZydnrvMbd6eR0eqL3zmtYGMXwABFiVA Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C33763C@SBS2008.eict.local> References: <017f01cf3705$6309bb20$291d3160$@com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/tTAyAY-pK5cLb3xwK3GMdpbG6kk Subject: Re: [Sdn] FW: New Version Notification for draft-haleplidis-sdnrg-layer-terminology-04.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 11:33:02 -0000 | - Construct a table of related SDO, interoperability, Open | Source, research/prototyping consortia etc work related to the | (current) version of (one or more) abstract architectural views (Some | of this is in the document, but a hyper linkable version and summary in | a presentation for subsequent meetings would help folks who have not | read the entire document) Wouldn't the SDNRG wiki (http://trac.tools.ietf.org/group/irtf/trac/wiki/sd= nrg) be a better place for this kind of a hyper-linkable catalogue? I think it makes sense to have a _short_ summary of activities in other SDO= s (perhaps even as an appendix to the current draft) with pointers to their= literature. But having an always up-to-date version of the proposed catalo= gue is better served through an wiki, imo. Best regards, Kostas =20 From nobody Thu Mar 6 06:36:57 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BA71A0140 for ; Thu, 6 Mar 2014 06:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 KZ5S5ZFIH64p for ; Thu, 6 Mar 2014 06:36:49 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 062E31A03D9 for ; Thu, 6 Mar 2014 06:36:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AA32D106F9A; Thu, 6 Mar 2014 15:36:41 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na3kHwkUwW4G; Thu, 6 Mar 2014 15:36:41 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 8296E106F90; Thu, 6 Mar 2014 15:36:26 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 6 Mar 2014 15:36:26 +0100 From: Dirk Kutscher To: Kostas Pentikousis , "Mcdysan, David E" , "sdn@irtf.org" Thread-Topic: [Sdn] FW: New Version Notification for draft-haleplidis-sdnrg-layer-terminology-04.txt Thread-Index: Ac83BWqb0v9g/48BTm+CSCpg1u3GDgAAGDVgAIUjXAAAA0UlAAAHH0yg Date: Thu, 6 Mar 2014 14:36:26 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249639D0C7A@PALLENE.office.hd> References: <017f01cf3705$6309bb20$291d3160$@com> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C33763C@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C33763C@SBS2008.eict.local> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/o6X5-fEXtgo9fxbkhvX6fMUnq40 Subject: Re: [Sdn] FW: New Version Notification for draft-haleplidis-sdnrg-layer-terminology-04.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 14:36:51 -0000 > Wouldn't the SDNRG wiki > (http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg) be a better place= for > this kind of a hyper-linkable catalogue? >=20 > I think it makes sense to have a _short_ summary of activities in other S= DOs > (perhaps even as an appendix to the current draft) with pointers to their > literature. But having an always up-to-date version of the proposed > catalogue is better served through an wiki, imo. +1 In general, I'd prefer to base the terminology / architecture description o= n knowledge about how actual SDN implementations work. =20 Best regards, Dirk From nobody Thu Mar 6 07:34:23 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D111A0083 for ; Thu, 6 Mar 2014 07:34:20 -0800 (PST) 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 YsCwywHiK2xa for ; Thu, 6 Mar 2014 07:34:15 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DCC431A0064 for ; Thu, 6 Mar 2014 07:34:14 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wn1so2698446obc.11 for ; Thu, 06 Mar 2014 07:34:10 -0800 (PST) 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=Qef+r7d9G7gcOdKkC36CTpLqCvqAos7tlco/TDJqe8I=; b=i89iDYDjP61lCQZfQ3fb69R+CAW7ch7v9CP/HoutSaPDwswVAnw4CyZXUFsiuYtxYQ S/R6SyLX/FCrgYvnp1wzv3GnxJQDZKhjneaCUcjsCmiw3RdcgpPR3l4cWfTvY6ctOe7B MbrUCbD+QI1XcVLG717NdLfElQ803Qje254LeZpDAS7tVI4vz2JpYyWtvncHTjRqyxhr qajVvXm16Q7T1A2j8EQUBukelkcfy4rjGGJW44czGh81AfJu6hCaxCzWAkr+XFZTGDPo Rbm6radwOXtusqiZ6bnBMd3dSO1uSM5kQsidM7b4cZyJbRSck4vmb1bdyGe2KAINWkk6 mvmQ== X-Received: by 10.60.165.72 with SMTP id yw8mr1074309oeb.71.1394120050881; Thu, 06 Mar 2014 07:34:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Thu, 6 Mar 2014 07:33:50 -0800 (PST) In-Reply-To: References: <81656F04-D6AB-4172-8963-06AACA016D25@riw.us> From: Scott Brim Date: Thu, 6 Mar 2014 15:33:50 +0000 Message-ID: To: Sriganesh Kini Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/-Vpd5mL91g7iYTO5wYdx6cclR44 Cc: Russ White , SDN IRTF list Subject: Re: [Sdn] Static-route - control or mgmt plane? X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 15:34:20 -0000 What is the value in distinguishing between management and control? From nobody Thu Mar 6 08:03:34 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF901A00AA for ; Thu, 6 Mar 2014 08:03:33 -0800 (PST) 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 Wo_5STuWTCHL for ; Thu, 6 Mar 2014 08:03:31 -0800 (PST) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id AE0981A0165 for ; Thu, 6 Mar 2014 08:03:31 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n16so2793351oag.13 for ; Thu, 06 Mar 2014 08:03:27 -0800 (PST) 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=AViteQOnCcMqc//TU61OITPrP5SXL3EuloXnbtsxZ7I=; b=LjvNcImsU/tf8XvNo9PtjLSC+5LrK8qJ+2EVyYjcGMU25Iez8l4/Mfqycq/XwrJGEA cu3Wol7kU46d8BqIoiQdj87ZEQUeQQrhJaSoZRIwD9Pm/WL2gI8wsR1n6N2BCWEXTCrw HN+HUW2p9RkiBW5XsHHnsPsgfZXh2joCLqdlsYYeDl9NaErh3jvVLqjqlo5llZFjVvR8 z5tz8cnCALJbW+qb2+yvnrIVg6qTfpnrKqs8XamD9dx7B3glyaU0CBoO+feVPKzvTSN9 MbH6IZ09i74sK4mVPhdzdP2dJGSE94k0VenZ6dqdUCbKVtuzo7BC2G40qnOdk1c9EOBt e/jw== X-Received: by 10.182.128.138 with SMTP id no10mr10625998obb.32.1394121807741; Thu, 06 Mar 2014 08:03:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Thu, 6 Mar 2014 08:03:06 -0800 (PST) In-Reply-To: <53184BA7.8050209@kit.edu> References: <53184BA7.8050209@kit.edu> From: Scott Brim Date: Thu, 6 Mar 2014 16:03:06 +0000 Message-ID: To: Roland Bless Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/U4S_9FjoTgEAp5koA47CQollzc8 Cc: SDN IRTF list Subject: Re: [Sdn] Reference Layer Model X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 16:03:33 -0000 On Thu, Mar 6, 2014 at 10:19 AM, Roland Bless wrote: > some remarks w.r.t. slide 7 of > http://www.ietf.org/proceedings/89/slides/slides-89-sdnrg-6.pdf > > 1.) (related to Scott Brim's comment) > I guess what cause slight confusion was the fact that two boxes > in the middle (control/management) are labeled Control Plane and > Management Plane. They are rather (logical) entities residing > in the respective planes, e.g., the Control Plane is made up of > a set of Control Entities working together. So Control Plane > and Management Plane should not be written _into_ the boxes > (maybe beneath). > Even more confusing are the blocks "Forwarding Plane" and "Operational > Plane" inside the network device, their are rather entities/functional > blocks belonging to these planes. I believe it's okay to have the management and control planes in abstract small boxes in the center of the diagram. At this level of abstraction that works just fine. It's also okay to have the forwarding plane in such a box. I believe it's fine to have the forwarding plane below the control plane, since there is a clear relationship along that axis BUT the DAL is for both management and control, so don't let the diagram imply that forwarding interacts only with the control plane. The problem comes from trying to create symmetry in the diagram by inserting an operational "plane" below the management plane. It's not. But neither is it just a piece of the management plane. I recommend considering the operational functions to be terminations of either/or/both of the management and control planes. It's not one in particular, it's an aggregate, a high level abstraction. Just call that box something like "operations" -- something that doesn't imply which particular plane it's associated with, and fix the associated text and slides. That way, the abstraction is all on the same level, and works. Scott From nobody Thu Mar 6 08:03:40 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053CD1A01C2 for ; Thu, 6 Mar 2014 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 ieeUHMdQ2_Td for ; Thu, 6 Mar 2014 08:03:36 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF861A0074 for ; Thu, 6 Mar 2014 08:03:36 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so2718822pde.15 for ; Thu, 06 Mar 2014 08:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3aQyvzUMbVyONE/w5YMyVBfX14amNyqygLOJywmgpeM=; b=R5wVIZeVbagLLNMU0LyOPE1ojOwiEaj+pOIcUKPskMTct+m6begrnPBAzLl+P1VSl8 Kgrl2h2HGT7lQW+a9eMpjsDETRDToMCDeMislkvalcr762Lr1F6nOEYB2bbfWo2Vtuo+ HWuZhlyMNAmT27drG2O1aQwPP772IWrso1MJXRGrtI9lVPOt0xsbKG03P8eFovYQfl/A nfDTTDgDWN9ONTAuFs8SbodHMrBQBMYb5Y29Rk8lEV3OxKs/xNV5T7UjvuYgPbeixrxq ahrpjKA0gKOfTHPUKSWedx3NFYHIQTrqBdZH39V5kEPdOXQ9ZCTG9VVx5nA8H1hUKuWG 1MQA== X-Received: by 10.66.218.234 with SMTP id pj10mr15451338pac.156.1394121812686; Thu, 06 Mar 2014 08:03:32 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.84.165 with HTTP; Thu, 6 Mar 2014 08:03:02 -0800 (PST) In-Reply-To: References: <81656F04-D6AB-4172-8963-06AACA016D25@riw.us>

From: Sriganesh Kini Date: Thu, 6 Mar 2014 08:03:02 -0800 X-Google-Sender-Auth: 9G6Ce3kQB8vHubkvcO7IpE0E5-U Message-ID: To: Scott Brim Content-Type: multipart/alternative; boundary=047d7b5dba946b3e3c04f3f2478a Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/g-Os4oEkWIv6jh73nSRq7S3gt_o Cc: Russ White , SDN IRTF list Subject: Re: [Sdn] Static-route - control or mgmt plane? X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 16:03:38 -0000 --047d7b5dba946b3e3c04f3f2478a Content-Type: text/plain; charset=UTF-8 Good question. I will let the draft authors answer that. I was looking at it from the I2RS perspective where we scoped the modeling exercise to not include device management objects. Sri On Thu, Mar 6, 2014 at 7:33 AM, Scott Brim wrote: > What is the value in distinguishing between management and control? > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --047d7b5dba946b3e3c04f3f2478a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Good question. I will let the draft authors answer that.

I was looking at it from the I2RS perspective where we sc= oped the modeling exercise to not include device management objects.

Sri=C2=A0

On Thu, Mar 6, 2014 at 7:33 AM, = Scott Brim <scott.brim@gmail.com> wrote:

What is the value in distinguishing between = management and control?

_______________________________________________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn

--047d7b5dba946b3e3c04f3f2478a-- From nobody Thu Mar 6 09:14:56 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAD41A01FD for ; Thu, 6 Mar 2014 09:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 zyrXau4haPjX for ; Thu, 6 Mar 2014 09:14:51 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 410991A01F3 for ; Thu, 6 Mar 2014 09:14:51 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id 833281FF6B; Thu, 6 Mar 2014 18:14:46 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id B03D91FF69; Thu, 6 Mar 2014 18:14:45 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 2D498378378; Thu, 6 Mar 2014 18:14:45 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 6 Mar 2014 18:14:44 +0100 From: Kostas Pentikousis To: Sriganesh Kini , Scott Brim Date: Thu, 6 Mar 2014 18:14:43 +0100 Thread-Topic: [Sdn] Static-route - control or mgmt plane? Thread-Index: Ac85ValMn3FE9hpRTOWFslZy3SWKIwACbSvA Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C3376A0@SBS2008.eict.local> References: <81656F04-D6AB-4172-8963-06AACA016D25@riw.us>

In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/gaE-tSpGVeP-XDcBX0oCd7EJHq8 Cc: Russ White , SDN IRTF list Subject: Re: [Sdn] Static-route - control or mgmt plane? X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Thu, 06 Mar 2014 17:14:53 -0000 SGkgU3JpLA0KDQp8IEkgd2FzIGxvb2tpbmcgYXQgaXQgZnJvbSB0aGUgSTJSUyBwZXJzcGVjdGl2 ZSB3aGVyZSB3ZSBzY29wZWQNCnwgdGhlIG1vZGVsaW5nIGV4ZXJjaXNlIHRvIG5vdCBpbmNsdWRl IGRldmljZSBtYW5hZ2VtZW50IG9iamVjdHMuDQoNCldoYXQgbW90aXZhdGVkIHRoaXMgZGVjaXNp b24/DQoNCkJlc3QgcmVnYXJkcywNCg0KS29zdGFzDQo= From nobody Fri Mar 7 02:40:34 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC31A024B for ; Fri, 7 Mar 2014 02:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 X8ugGZ93UCGf for ; Fri, 7 Mar 2014 02:40:28 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB581A021E for ; Fri, 7 Mar 2014 02:40:28 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id up15so3972214pbc.6 for ; Fri, 07 Mar 2014 02:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QtNkjqjMu6uyeXxZVPZ1NpVA8Zgn6gHKv9VwK0bEJYo=; b=MfOtoN7TSWsaPtrieHCJ7Z/pJpFr22UAvaoxjiVHBQoksIMlFB4Ihhf35NX/wsT+C6 Ep6UXsmNM40Yv8L4J3lDD6LbkyWRkl1su3c+y1D+uS8QW6lZ1gnVEcdiB0/cTCFf0m17 EC01jOyD+SQKsJ6cZWTlPrNch4U9F67eJo7j3sdR9WwGLQ0QhxivUqp0hYIzu0gjm6Rm +8F8KVBfOVtlRvB6oM1tUsUCAb4Cl7NXhmNR0hAT786nAAd49rkOk7/uggUbP5TF704U Ronf5xp1SxNbRRp2zZjfV9ND9aJNJJ60WoDg2U2B+K9RlJsGNVDU4JynnIJWFEuIPY4M 9DxQ== X-Received: by 10.66.250.202 with SMTP id ze10mr21165013pac.153.1394188824008; Fri, 07 Mar 2014 02:40:24 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.84.165 with HTTP; Fri, 7 Mar 2014 02:39:53 -0800 (PST) In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C3376A0@SBS2008.eict.local> References: <81656F04-D6AB-4172-8963-06AACA016D25@riw.us>

<0C7EDCF89AB9E2478B5D010026CFF4AEA10C3376A0@SBS2008.eict.local> From: Sriganesh Kini Date: Fri, 7 Mar 2014 02:39:53 -0800 X-Google-Sender-Auth: UQugVAuGaDH-NJNJ253IyhSsagI Message-ID: To: Kostas Pentikousis Content-Type: multipart/alternative; boundary=047d7b15aeed9adeb604f401e151 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/z5NRKU3LQYEe8HBlwUpOgseTH30 Cc: Russ White , SDN IRTF list , Scott Brim Subject: Re: [Sdn] Static-route - control or mgmt plane? X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Mar 2014 10:40:30 -0000 --047d7b15aeed9adeb604f401e151 Content-Type: text/plain; charset=UTF-8 Hi Kostas, The charter of the I2RS group was to develop a standardized interface to the "routing system". The device management models are vendor specific and considered as outside of the "routing system", and the I2RS WG was not chartered to look into that. Sri On Thu, Mar 6, 2014 at 9:14 AM, Kostas Pentikousis wrote: > Hi Sri, > > | I was looking at it from the I2RS perspective where we scoped > | the modeling exercise to not include device management objects. > > What motivated this decision? > > Best regards, > > Kostas > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --047d7b15aeed9adeb604f401e151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Kostas,

The charter of the I2RS grou= p was to develop a standardized interface to the "routing system"= . The device management models are vendor specific and considered as outsid= e of the "routing system", and the I2RS WG was not chartered to l= ook into that.

Sri

=

On Thu, Mar 6, 2014 at 9:14 AM, Kostas Pentikous= is <k.pentikousis@eict.de> wrote:

Hi Sri,

| I was looking at it from the I2RS perspective where we scoped
| the modeling exercise to not include device management objects.

What motivated this decision?

Best regards,

Kostas

___________________________________= ____________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn

--047d7b15aeed9adeb604f401e151-- From nobody Fri Mar 7 07:01:41 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4411A0290 for ; Fri, 7 Mar 2014 07:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iJBetGhnBLVt for ; Fri, 7 Mar 2014 07:01:35 -0800 (PST) Received: from rad.co.il (mailrelay01-ib2.rad.com [91.143.228.146]) by ietfa.amsl.com (Postfix) with ESMTP id 621DA1A0285 for ; Fri, 7 Mar 2014 07:01:15 -0800 (PST) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with RC4-SHA encrypted SMTP; 7 Mar 2014 16:59:02 +0200 Received: from EXRAD6.ad.rad.co.il (2002:c072:18be::c072:18be) by exrad6.ad.rad.co.il (2002:c072:18be::c072:18be) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 7 Mar 2014 17:00:56 +0200 Received: from EXRAD6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0]) by exrad6.ad.rad.co.il ([fe80::f157:6202:5fc8:a4f0%12]) with mapi id 15.00.0775.031; Fri, 7 Mar 2014 17:00:56 +0200 From: Yaakov Stein To: Scott Brim , Sriganesh Kini Thread-Topic: [Sdn] Static-route - control or mgmt plane? Thread-Index: AQHPOSQoQbStmt/7Fk65KKJvNlEzhZrTtbuAgAAJfACAAE/rAIAAdR1A Date: Fri, 7 Mar 2014 15:00:55 +0000 Message-ID: References: <81656F04-D6AB-4172-8963-06AACA016D25@riw.us>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.188.160.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A010203.5319DF2E.0180, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 (Unknown) Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/fsyjumtF20dLAYk9lEtNEY3ts9A Cc: Russ White , SDN IRTF list Subject: Re: [Sdn] Static-route - control or mgmt plane? X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Mar 2014 15:01:38 -0000 > What is the value in distinguishing between management and control? Scott, The importance of the existence of both control and management planes is th= at they enable explicit selection of CAP tradeoffs. I think that I have explained the CAP theorem here before. Quick review -=20 There are three characteristics of distributed systems that are universally= desirable: * Consistency, meaning that the system responds identically to a query no m= atter which node receives the request (or does not respond at all); * Availability, i.e., that the system always responds to a request (althoug= h the response may not be consistent or correct); and * Partition tolerance, namely that the system continues to function even wh= en nodes or the communications network fail. Brewer conjectured that a distributed system can satisfy any two of these g= uarantees at the same time, but not all three. This conjecture was later pr= oven by Gilbert and Lynch. SDN teaches us that packet forwarding is simply a computational problem. Th= is is the major abstraction that SDN posits - all packet based network elem= ents (Ethernet switches, IP routers, NAT, firewalls, etc.) are computationa= l resources that perform a single computational task with 5 steps: 1) input= a packet, 2) inspect fields in the packet, 3) decide how to handle the pac= ket, 4) optionally edit the packet, and 5) forward or drop the packet. The = difference between the different network elements is the decision logic in = step 3.=20 Since the task of forwarding a packet from network ingress to network egres= s is obviously carried out by a large number of forwarding elements, the ne= twork of packet forwarding devices is a distributed computational system. H= ence, the CAP theorem applies. So which two of the three desirable characteristics of distributed systems = do we want to achieve, and more importantly, which one are we willing to fo= rego? Conventional networks explicitly perform CAP tradeoffs by using a combinati= on of control plane and management plane operations. Management plane opera= tions are initiated from a central management site (e.g., a NOC) and are us= ed for relatively slow, infrequent operations, such as configuration, setup= of new services, collection of monitoring data, etc. Control plane operati= ons are usually local and are used when rapid response is required (e.g., a= utomatic protection switching). The combination of the two is required to s= atisfy a service provider's needs.=20 While commissioning a new service, conventional networks use the management= plane, which stresses consistency and forgoes availability. Consistency is= important since a customer will be billed for the service, and new service= s are not allowed to interfere with existing services. The price is a compr= omise regarding availability - while commissioning the service is not avail= able for an extended amount of time. Commissioning testing (e.g., using Y.1= 564) is typically from 2 to 24 hours. In addition, while commissioning a se= rvice it is assumed that there are no communications failures. Once a service is set up, conventional routed networks exploit the control = plane and basically forego consistency in order to obtain availability (e.g= ., 5 nines) and partition tolerance (e.g., 50 msec. to correct failures). E= ach router has its own local Forwarding Information Base (FIB), which is lo= cally created and only weakly tied to the FIBs of the others. Lack of forwa= rding consistency means that packets can sometimes become misrouted or "bla= ck-holed" (go around in circles until they are dropped). That is the reason= the IP packet header has a TTL field, and the reason TCP is layered over I= P to retransmit lost packets. IP routing can be shown to be eventually cons= istent (i.e., attain consistency after a very long time if nothing further = happens in the network), but deployed networks frequently operate with cons= iderably less time between network events (new services or failures) than r= equired to achieve consistency. On the other hand, IP service unavailabili= ty is almost always due to a local break that physically disconnects the ho= st from the IP network, and, as previously discussed, IP networks are extre= mely tolerant to partition failures.=20 On the other hand SDN has a single plane which it calls "control" (indeed, = SDN enthusiasts believe they invented the separation of forwarding and cont= rol operations), but being based on a centralized controller is similar to = the conventional management plane. SDN networks stress consistency, but hav= e no flexibility to adapt to forgo consistency for availability when the ne= ed arises.=20 Since transport networks typically have SLAs regarding availability (5 nine= s) and partition tolerance (50 msec)=20 but are less stringent concerning consistency (packet loss, billing correct= ness) such tradeoffs are needed. Y(J)S From nobody Fri Mar 7 10:38:05 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C411A02BD for ; Fri, 7 Mar 2014 10:38:03 -0800 (PST) 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 Tk8H6Dt0gUSN for ; Fri, 7 Mar 2014 10:37:58 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07B1A019A for ; Fri, 7 Mar 2014 10:37:58 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id up15so4531918pbc.20 for ; Fri, 07 Mar 2014 10:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VnSmq7IiCJpwe0nu4v/rIOqQ/XQR0+ecI3fpj/Cu1RA=; b=KbAFeMFMyqdgIrujo4QtRIe2sglM8Hjpb2p00hCu1ts1FN6bvECQkCAZDfsAUgk2/b onVG50zcJSPKOJwkGVXfNL7U2mlVIsKcnypRjYPovxBi7J/azAw7OzeWUfNGv8CjZ2x2 J50XmsSEqMRvo3nJ24OJ7Mbhj0gi+GrDTjvGeM4RwWuwaBKQGtI6WLfklA2B4VZCxqw2 MADc6/8C752izycstmAeNNqZGc99sEE7hA95v3srsNgee+FKFQNsrYPHbOE7dryY4v9F jSLOx7hR+ZegnwzeGNYhilt0NiP7eETrMuQb/HCIIMhM+sixv4OZxEziOuw+ZL3Bf3KH TPxw== X-Received: by 10.66.148.134 with SMTP id ts6mr23334580pab.113.1394217473984; Fri, 07 Mar 2014 10:37:53 -0800 (PST) Received: from [10.10.120.249] (50-197-184-177-static.hfc.comcastbusiness.net. [50.197.184.177]) by mx.google.com with ESMTPSA id n6sm39554857pbj.22.2014.03.07.10.37.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 10:37:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Fri, 7 Mar 2014 10:37:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81656F04-D6AB-4172-8963-06AACA016D25@riw.us>

To: Yaakov Stein Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/XJZ48igz9sU6WeQyl31YiJLgmww Cc: Russ White , SDN IRTF list , Scott Brim , Sriganesh Kini Subject: Re: [Sdn] Static-route - control or mgmt plane? X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Fri, 07 Mar 2014 18:38:03 -0000 Yaakov, Very good backgrounder but I think not fully accurate interpretation= of the situation. If SDN targets dynamic flows as the interface to forwarding, ie it is not a= bout static circuits, then it is targeting innovative control without compromising performance, no= t just management.=20 Centralization doesn't mean much unless single sequential process can scale c= ontrol of any network.=20 Since this is not the case for most networks then we have to further evolve t= he SDN distinction. Best bet on the table right now, picking up de-facto momentum in the market i= s- Combination of SDN control-forward separation with NVO identity-location sep= aration. =20 This effectively reduces the network-CAP problem to be a database-CAP proble= m, e.g. While each overlay node contains the flow interface, the CAP strain is on th= e underlay mapping authority. Mapping turns the discrete nodes into a distributed system. Since as you said you need to pick your trade offs and "choose your poison",= =20 then it's best to pick an NVO solution that lets you choose your mapping tec= hnology. LISP had been able to offer that flexibility, and hopefully so will other NV= O standards. --szb On Mar 7, 2014, at 7:00, Yaakov Stein wrote: >> What is the value in distinguishing between management and control? >=20 > Scott, >=20 > The importance of the existence of both control and management planes is t= hat they enable explicit selection of CAP tradeoffs. >=20 > I think that I have explained the CAP theorem here before. > Quick review -=20 > There are three characteristics of distributed systems that are universall= y desirable: > * Consistency, meaning that the system responds identically to a query no m= atter which node receives the request (or does not respond at all); > * Availability, i.e., that the system always responds to a request (althou= gh the response may not be consistent or correct); and > * Partition tolerance, namely that the system continues to function even w= hen nodes or the communications network fail. > Brewer conjectured that a distributed system can satisfy any two of these g= uarantees at the same time, but not all three. This conjecture was later pro= ven by Gilbert and Lynch. >=20 > SDN teaches us that packet forwarding is simply a computational problem. T= his is the major abstraction that SDN posits - all packet based network elem= ents (Ethernet switches, IP routers, NAT, firewalls, etc.) are computational= resources that perform a single computational task with 5 steps: 1) input a= packet, 2) inspect fields in the packet, 3) decide how to handle the packet= , 4) optionally edit the packet, and 5) forward or drop the packet. The diff= erence between the different network elements is the decision logic in step 3= .=20 >=20 > Since the task of forwarding a packet from network ingress to network egre= ss is obviously carried out by a large number of forwarding elements, the ne= twork of packet forwarding devices is a distributed computational system. He= nce, the CAP theorem applies. >=20 > So which two of the three desirable characteristics of distributed systems= do we want to achieve, and more importantly, which one are we willing to fo= rego? >=20 > Conventional networks explicitly perform CAP tradeoffs by using a combinat= ion of control plane and management plane operations. Management plane opera= tions are initiated from a central management site (e.g., a NOC) and are use= d for relatively slow, infrequent operations, such as configuration, setup o= f new services, collection of monitoring data, etc. Control plane operations= are usually local and are used when rapid response is required (e.g., autom= atic protection switching). The combination of the two is required to satisf= y a service provider's needs.=20 >=20 > While commissioning a new service, conventional networks use the managemen= t plane, which stresses consistency and forgoes availability. Consistency is= important since a customer will be billed for the service, and new services= are not allowed to interfere with existing services. The price is a comprom= ise regarding availability - while commissioning the service is not availabl= e for an extended amount of time. Commissioning testing (e.g., using Y.1564)= is typically from 2 to 24 hours. In addition, while commissioning a service= it is assumed that there are no communications failures. >=20 > Once a service is set up, conventional routed networks exploit the control= plane and basically forego consistency in order to obtain availability (e.g= ., 5 nines) and partition tolerance (e.g., 50 msec. to correct failures). Ea= ch router has its own local Forwarding Information Base (FIB), which is loca= lly created and only weakly tied to the FIBs of the others. Lack of forwardi= ng consistency means that packets can sometimes become misrouted or "black-h= oled" (go around in circles until they are dropped). That is the reason the I= P packet header has a TTL field, and the reason TCP is layered over IP to re= transmit lost packets. IP routing can be shown to be eventually consistent (= i.e., attain consistency after a very long time if nothing further happens i= n the network), but deployed networks frequently operate with considerably l= ess time between network events (new services or failures) than required to a= chieve consistency. On the other hand, IP service unavailability is almost a= lways due > to a local break that physically disconnects the host from the IP network= , and, as previously discussed, IP networks are extremely tolerant to partit= ion failures.=20 >=20 > On the other hand SDN has a single plane which it calls "control" (indeed,= SDN enthusiasts believe they invented the separation of forwarding and cont= rol operations), but being based on a centralized controller is similar to t= he conventional management plane. SDN networks stress consistency, but have n= o flexibility to adapt to forgo consistency for availability when the need a= rises.=20 >=20 > Since transport networks typically have SLAs regarding availability (5 nin= es) > and partition tolerance (50 msec)=20 > but are less stringent concerning consistency (packet loss, billing correc= tness) > such tradeoffs are needed. >=20 > Y(J)S >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From nobody Fri Mar 7 17:35:25 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CEC1A032C for ; Fri, 7 Mar 2014 17:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] 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 u1iNT3YgsVe6 for ; Fri, 7 Mar 2014 17:35:21 -0800 (PST) Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by ietfa.amsl.com (Postfix) with ESMTP id E64841A0328 for ; Fri, 7 Mar 2014 17:35:20 -0800 (PST) Received: from [10.0.1.37] (c-67-160-86-141.hsd1.wa.comcast.net [67.160.86.141]) (authenticated bits=0) by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id s281ZEFo020673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Mar 2014 19:35:15 -0600 From: Aditya Akella Content-Type: multipart/alternative; boundary="Apple-Mail=_E5291C1A-D5DA-4C3A-A1B2-FD4E5EA3CF92" Date: Fri, 7 Mar 2014 17:35:14 -0800 Message-Id: To: sdn@irtf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/ePDcgpltdSlCnPLejc0CWbhc_l8 Cc: Albert Greenberg Subject: [Sdn] HotSDN'14 Call For Papers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Aditya Akella 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: Sat, 08 Mar 2014 01:35:23 -0000 --Apple-Mail=_E5291C1A-D5DA-4C3A-A1B2-FD4E5EA3CF92 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN) Co-located with ACM SIGCOMM'14 August 18, 2014 Chicago, IL Software Defined Networking (SDN) refactors the relationship between network devices and the software that controls them. Opening up the interfaces to programming the network enables more flexible and predictable network control, and makes it easier to extend the network with new functionality. SDN is being employed in a large and growing number of experimental and production settings spanning campus networks, telcos, clouds, and online service provider networks. A variety of new applications have been developed, including network virtualization, responsive traffic engineering, dynamic access control, seamless mobility support, etc. HotSDN aims to bring together industry and academia to jointly explore and debate recent developments related to all aspects of SDN. We invite researchers and practitioners to submit short papers. Such papers could, for example, present new ideas for designing switch hardware and APIs that offer greater flexibility without compromising performance; describe new software platforms for better control and management of software defined networks; shed light on experiences deploying software defined networks in the wild; describe novel SDN use cases; present novel ideas for inter-operating SDNs with legacy equipment; and so on. Topics of Interest We encourage submission of short previously unpublished papers on Software Defined Networking. We particularly encourage position papers and radical ideas that challenge state-of-the-art in SDN. Topics of interest include, but are not limited to, the following: * SDN applications to home, wireless, cellular, enterprise, data-center, and backbone networks * SDN applications to network management, monitoring, security, etc. * Security of SDN infrastructure * Virtualization in SDNs * Switch designs for SDN * Application programming interfaces for SDNs * Control and management software for SDNs * Programming languages, verification techniques, and tools for SDNs * Performance evaluation of SDN switches and controllers * Experiences deploying SDN technology and applications in operational networks * Transitioning existing networks to SDN * Placement and factoring of SDN control logic * SDN-like control applied to other settings, e.g., transport, physical layer, wireless, etc. Important Dates Abstract registration: March 18, 2014 Submissions due: March 25, 2014 Notification: April 30, 2014 Camera ready versions due: May 31, 2014 Workshop date: August 18, 2014 PC Co-chairs Aditya Akella, UW-Madison Albert Greenberg, Microsoft Program Committee Najam Ahmad, Facebook Paul Barford, Wisconsin Marco Canini, UCL Diego Crupnicoff, Mellanox Dan Daly, Intel Dinesh Dutt, Cumulus Tom Edsal, Insieme Ali Ghodsi, Berkeley Arjun Guha, UMass Ariel Hendel, Broadcom Vimalkumar Jeyakumar, Stanford Sachin Katti, Stanford Eric Keller, Colorado Teemu Koponen, Nicira Dejan Kostic, IMDEA TV Lakshman, Bell Labs Dave Maltz, Microsoft Jeff Mogul, Google Pere Monclus, Plumgrid Guru Parulkar, Stanford Vyas Sekar, CMU Anees Shaikh, Google Hakim Weatherspoon, Cornell Minlan Yu, USC Submission instructions Each submission must be a single PDF file no longer than six (6) pages in length (in two-column, 10-point format) including references, following the LaTeX style file. Papers should be submitted electronically via the submission site: https://hotsdn14.cs.wisc.edu/hotcrp/. Papers must include the author name and affiliation for single-blind peer reviewing by the program committee. Accepted papers will be published in the ACM Digital Library. Publication at HotSDN is not intended to preclude later publication. Authors of accepted papers are expected to present their papers at the workshop. --Apple-Mail=_E5291C1A-D5DA-4C3A-A1B2-FD4E5EA3CF92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://hotsdn14.cs.wisc.edu= /hotcrp/. Papers must include the author
name and affiliation for = single-blind peer reviewing by the program
committee.

Accepted = papers will be published in the ACM Digital
Library. Publication at = HotSDN is not intended to preclude later
publication. Authors of = accepted papers are expected to present their
papers at the = workshop.

= --Apple-Mail=_E5291C1A-D5DA-4C3A-A1B2-FD4E5EA3CF92-- From nobody Sat Mar 15 09:49:19 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E11A0165 for ; Sat, 15 Mar 2014 09:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 1HWqhxxvY-b1 for ; Sat, 15 Mar 2014 09:49:16 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 830C31A00C3 for ; Sat, 15 Mar 2014 09:49:16 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so4082678veb.15 for ; Sat, 15 Mar 2014 09:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=0hDRJrMdGCu/0JnzpZtVmy9uh0FLEjuYkrNNoGSKAkY=; b=EuNlSOFec2tPznBl0s/arxxPrg+6JiHqdQlE+EgS16uBiDp/XRsy6u2pft1KhHBtff BWjU91t/FPNTy0pyprbG7DFXs6xhMara92d0czIF+C9/CdpA6wlAaODOQSpV/WcEkNnW 95IKtLnvbLdV5gHL6lRFvq2ru7e5RpWElFrDMTiLG0GYtauLGwVY6ZFfTknEewODPWsM Hpu5tk1nJBhaTTbQ8BTcVvI/NiUgPqKthBV/u5qKqLfx20TDanzmMzkomjkzX+HmfuzD st9S0CNZVJFjNaIRaE9OS96WtX11VHzsxa9tKrN9H+G0zNxgzM0XRdwPlslPKdXYAtrq BNEg== X-Received: by 10.58.57.67 with SMTP id g3mr11772312veq.3.1394902149069; Sat, 15 Mar 2014 09:49:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.27.4 with HTTP; Sat, 15 Mar 2014 09:48:28 -0700 (PDT) From: mark higgs Date: Sat, 15 Mar 2014 16:48:28 +0000 Message-ID: To: sdn@irtf.org Content-Type: multipart/alternative; boundary=001a1136b2b217830b04f4a7f736 Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/DoAhWXVCaj5SN4eI_yx0ljFojE0 Subject: [Sdn] Creating virtual labs for comparison experiements X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Sat, 15 Mar 2014 16:49:18 -0000 --001a1136b2b217830b04f4a7f736 Content-Type: text/plain; charset=ISO-8859-1 Hello, I am looking for some guidance and hope this audience can help. I am hoping to do some experiments comparing configuration required on Cisco against a SDN installation. I have to created a virtual network with mininet on which to conduct the experiments. However, I am having difficulties configuring the controller in POX. Python is not my strongest skill. Does anyone have any good references, websites, notes that can help me? I have tried the openflow tutorial, but it seems to expect me to supervised by a tutor and doesnt give the final expected results. Any assistance, referrals, guidance, advice of any kind will be greatly received. Thank you. Kind regards, Mark Higgs --001a1136b2b217830b04f4a7f736 Content-Type: text/html; charset=ISO-8859-1

Hello,

I am looking for some guidance and hope this audience can help.

I am hoping to do some experiments comparing configuration required on Cisco against a SDN installation.

I have to created a virtual network with mininet on which to conduct the experiments.

However, I am having difficulties configuring the controller in POX.

Python is not my strongest skill.

Does anyone have any good references, websites, notes that can help me?

I have tried the openflow tutorial, but it seems to expect me to supervised by a tutor and doesnt give the final expected results.

Any assistance, referrals, guidance, advice of any kind will be greatly received.

Thank you.

Kind regards,

Mark Higgs

--001a1136b2b217830b04f4a7f736-- From nobody Fri Mar 28 05:37:08 2014 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6E91A0552 for ; Fri, 28 Mar 2014 05:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 RjlS0BOjYx5C for ; Fri, 28 Mar 2014 05:37:01 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A95F41A0323 for ; Fri, 28 Mar 2014 05:37:00 -0700 (PDT) Received: from [192.168.1.107] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 7E6A92749E01 for ; Fri, 28 Mar 2014 08:36:58 -0400 (EDT) From: Thomas Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_7FC8F0F9-111F-41C1-AC3E-0EADDBEF133E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <156C7D0E-5600-42FC-8E9D-7B908531D385@lucidvision.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) Date: Fri, 28 Mar 2014 08:36:58 -0400 References: To: SDN IRTF list In-Reply-To: X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sdn/tVy9tPA7zTETQw9xVLbNg_RtJfY Subject: [Sdn] SDN/MPLS 2014 CFP Announcement X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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: Fri, 28 Mar 2014 12:37:03 -0000 --Apple-Mail=_7FC8F0F9-111F-41C1-AC3E-0EADDBEF133E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SDN/MPLS 2014 CFP Announcement =20 The SDN/MPLS 2014 International Conference will be held on November 2 - = 5, in Washington, DC, at the Marriott Wardman Park hotel. This event is = the 17th annual conference organized by Isocore on Internet, MPLS, SDN, = NFV, Cloud, and Related Technologies. =20 The Technical Program Committee of SDN/MPLS 2014 is soliciting = presentation proposals for the conference. The committee seeks original = and unpublished work to continue the tradition initiated by this = conference in 1998 of covering cutting-edge topics. Presentations = addressing new technologies and operational experience are solicited = from network equipment vendors, network and cloud service providers, the = research community, government agencies, and enterprise users. =20 In 2014, the overarching themes of the conference will be on = Virtualization, SDN, Cloud Evolution, Datacenter/Cloud Interconnection, = Mobility, Security, and Service Resiliency. =20 The deadline for submission of presentation proposals is April 29, 2014. =20 Please submit your abstracts to cfp2014@isocore.com =20 For further information on the SDN/MPLS 2014 conference and additional = details on how to submit an abstract, please visit the following URL: =20 http://www.isocore.com/sdn-mpls/cfp.htm =20 =20 --Apple-Mail=_7FC8F0F9-111F-41C1-AC3E-0EADDBEF133E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTNWzqAAoJEPcO+I7eiUJZgAoP/iADUHwB5Tv9N/pie6U0kBZ0 H1ovU7Mj2p5lp7IDYh1bP2T8c6SinqV6rTeka4rCOvEfkNsCBr4Y/YsYwlLyJeJk iebSKEcSBtJ2qYzaQkxFoat+cEzpc5RZbE5HlEKv8CdPsHCxj1v0xdyOkedA2Q/J O/86u17JSymNehoNkRVQhCzj0us+CioP81mOqBoR2KVcGGhDVFOY2cWRnUYOyw0Z 1BoBVInPmIcVhTIaJmglapTtdiCIGAn7WBEGkCJ9/Qw2Zl158FXywza+yTwcQfm2 E7p86HxtgWVOb7yRQ+SglhpTXcMrSds54/uyVVztO4pkPR4SujbL8PkulQwTRjkB VDIxn7T91UBofo2gfMOOOlcYZSuQ19Hila814VALoanVKNeG7oOAvq7vQZOYlmiK Q4piWmkpQ9y8ZH/c0gcUxiZy2Fanr7t1eyShIJM0GZpaXaBSvIJmYMwV5v7mObAD BjgtT5cOGRCByOTskV/WiEOt+3m/ZXuhibrkm8QtvGn11FxlZzuzQkVWs271D4RN IyH8tYV04+o7sU482wrQmt1ZvhzinZspWkmyJ8kgTJI9T/v/+9NK15a9dqA5nAAK F2EnIFFKShMhhrW/SQ4XQIMZVJ1R5Hfin0VtRiXzukC882trqZG9kcpoItq/54Zf JyoQCO49HCDCpKr2wF+r =flEA -----END PGP SIGNATURE----- --Apple-Mail=_7FC8F0F9-111F-41C1-AC3E-0EADDBEF133E--