[Sdn] About planes or layering (RE: SDN reading list)

LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com> Sun, 07 August 2016 12:55 UTC

Return-Path: <luismiguel.contrerasmurillo@telefonica.com>
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 DF10012D5D5 for <sdn@ietfa.amsl.com>; Sun, 7 Aug 2016 05:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3PnfmX_Qxdvo for <sdn@ietfa.amsl.com>; Sun, 7 Aug 2016 05:55:50 -0700 (PDT)
Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0884A12D142 for <sdn@irtf.org>; Sun, 7 Aug 2016 05:55:49 -0700 (PDT)
Received: from smtptc.telefonica.com (tgtim3c02.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AB12D6045A; Sun, 7 Aug 2016 14:55:46 +0200 (CEST)
Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP103", Issuer "ESTGVMSP103" (not verified)) by smtptc.telefonica.com (Postfix) with ESMTPS id 91D1C60403; Sun, 7 Aug 2016 14:55:46 +0200 (CEST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.266.1; Sun, 7 Aug 2016 14:55:45 +0200
Received: from AM3PR06MB1379.eurprd06.prod.outlook.com (10.163.187.13) by AM3PR06MB1377.eurprd06.prod.outlook.com (10.163.187.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sun, 7 Aug 2016 12:50:32 +0000
Received: from AM3PR06MB1379.eurprd06.prod.outlook.com ([fe80::84f:b29d:30e9:6c25]) by AM3PR06MB1379.eurprd06.prod.outlook.com ([fe80::84f:b29d:30e9:6c25%14]) with mapi id 15.01.0549.023; Sun, 7 Aug 2016 12:50:32 +0000
From: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
To: Dave Hood <dave.hood@ericsson.com>, Juliano Wickboldt <jwickboldt@inf.ufrgs.br>, "King, Daniel" <d.king@lancaster.ac.uk>
Thread-Topic: About planes or layering (RE: [Sdn] SDN reading list)
Thread-Index: AdHwihe4e9MrNuq8R2+8srYdsGmNUw==
Date: Sun, 7 Aug 2016 12:50:31 +0000
Message-ID: <AM3PR06MB1379E591249F7ACF31B28A219E1A0@AM3PR06MB1379.eurprd06.prod.outlook.com>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=luismiguel.contrerasmurillo@telefonica.com;
x-originating-ip: [176.83.183.78]
x-ms-office365-filtering-correlation-id: 199d6d87-2635-403f-4604-08d3bec16ae9
x-microsoft-exchange-diagnostics: 1; AM3PR06MB1377; 6:QXgdmqTr/eZ7vT7lbrVGS2IQnTXijnDGUBzHkrLRSebXpB0pSUxFoIniwh2aK7eF1yitnRXC+RPJl12SINmO1AnNv9hNA0Caqwdu1/ovN3ClYS6qKeK42NYImS+k3b5680uAsUizDRZMiyh9+LZhAnqld0wH8aE0jcC2zdoNe+NA/z6Qt3HUSZBBdaJVU45WXzismPYeNEoHRrptAU6yqm/WqtGr+tR+EzOpqCM7H/u3BhBelTuoBBCSwkGsNwMYgxeP52tmkS8Jf9xgjaGBxxFy6eKdqw/hKB7o1qzatuY=; 5:n4+PyeMh51a5h8eA5Qggusyp+98Hksi7+r3Xsdn0FKyjalHaO++9icLbJyPkHUuINKt+tPHkbWNxi9PFtzwtRDAKcp3BH4UEM16KiRqGs977MWAecj7Ir51u+cxdPP2BnpsHwC89UYripX84E0x1sw==; 24:R21ru1qVqZGPERgFIr5Oatnt5pSGTwooTHbQL5+UYTM0A/uL6kfE9Y9n53iCAEDkcaRajOO36lSMi15JsqOA7VTQHq78LRUYUK0eG3tkqh4=; 7:SpEhl02qZKaRRKvOAdmtw9qg6Ht5/ny26SY/4O2+BmiR9yem+0KiwIITYy45uyA/texvoTo5fJUFGYXsMBYmkjuiGdt0ZLGCgt9Vs38uIqHm7tvW6BP/HoHvqVkwhHNy5nJpShFEOdkK6VsrOyEwlkynrTJAviOKs7n7l8j+KJMyISvOEqDwPRs5ldjEZteeUpW9y+m8nSshg6zHZcuEyxZ7iTtOvyO1hoIe8HmFKkidTygWUrqrmWqLnqkkVZud
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR06MB1377;
x-microsoft-antispam-prvs: <AM3PR06MB1377FCF079B404A251A16F609E1A0@AM3PR06MB1377.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(76576733993138)(165104125076784)(278428928389397)(111039206520245)(211936372134217)(43874152186217)(21748063052155)(5213294742642);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM3PR06MB1377; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB1377;
x-forefront-prvs: 0027ED21E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(53754006)(24454002)(13464003)(51744003)(199003)(189002)(377454003)(106356001)(74316002)(554214002)(3280700002)(54356999)(9686002)(15975445007)(18206015028)(229853001)(76576001)(3660700001)(189998001)(5002640100001)(92566002)(5250100002)(68736007)(101416001)(2900100001)(586003)(81166006)(87936001)(2906002)(19625215002)(8936002)(6116002)(7736002)(11100500001)(345774005)(81156014)(3846002)(86362001)(16601075003)(97736004)(8676002)(1680700002)(102836003)(861006)(66066001)(31430400001)(50986999)(19580405001)(16865895004)(19580395003)(7906003)(4326007)(33656002)(19300405004)(790700001)(19617315012)(16236675004)(5001770100001)(105586002)(7846002)(7696003)(7099028)(9010500006)(16351025005)(16866105001)(15398625002)(19627235001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB1377; H:AM3PR06MB1379.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM3PR06MB1379E591249F7ACF31B28A219E1A0AM3PR06MB1379eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2016 12:50:31.8648 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB1377
X-OriginatorOrg: telefonica.com
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/sdn/VaI8RVJqt6TUseWmDZZY4nIHT9E>
X-Mailman-Approved-At: Mon, 08 Aug 2016 06:27:27 -0700
Cc: "sdn@irtf.org" <sdn@irtf.org>, "Broadbent, Matthew" <m.broadbent@lancaster.ac.uk>, Cristian Lumezanu <lume@nec-labs.com>
Subject: [Sdn] About planes or layering (RE: SDN reading list)
X-BeenThere: sdn@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List to Discuss SDN Research Group in the IRTF <sdn.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/sdn>, <mailto:sdn-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sdn/>
List-Post: <mailto:sdn@irtf.org>
List-Help: <mailto:sdn-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/sdn>, <mailto:sdn-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Aug 2016 12:55:55 -0000

Hi Dave,

Sorry for jumping late on this, I’m currently on holidays, with sporadic access to the email.

I agree with you on the importance of recursion. However I do not see that as a motivation for discarding the approach of separating concerns in planes or layers. I think there are a number of motivations for that, being some of them (from my point of view):


·         Simpler and easier integration with “legacy” (or conventional) systems. In other words, brownfield scenarios, quite relevant for operators.

·         Risk of lock-in (either vendor or open source lock-in) for closed, monolithic control architectures without clear separation of concerns and not well defined open and extensible interfaces, with difficult (if not impossible) interoperability and interchangeability of functional components

·         Unclear responsibilities for operational matters, e.g. for OAM/FCAPS/inventory/control tasks. But this also applies to service provision/delivery/decommission, where typically different organizations are responsible of different tasks in an operator

·         More complex service/network diagnosis and troubleshooting

My personal view is that planes or layers help to make the problem more tractable and simple. This applies not only to the traditional control/management/resource planes, but also to the separation of end-service provision and operation from connectivity (or transport between service end-points), with separated responsible teams within service providers.

To that respect both RFC7426 and draft-irtf-sdnrg-layered-sdn provide architectural basis, allowing recursions, for sure.

Best regards

Luis

De: sdn [mailto:sdn-bounces@irtf.org] En nombre de Dave Hood
Enviado el: miércoles, 3 de agosto de 2016 20:22
Para: Juliano Wickboldt <jwickboldt@inf.ufrgs.br>br>; King, Daniel <d.king@lancaster.ac.uk>
CC: Broadbent, Matthew <m.broadbent@lancaster.ac.uk>uk>; sdn@irtf.org; Cristian Lumezanu <lume@nec-labs.com>
Asunto: Re: [Sdn] SDN reading list

I thought the list was interesting inasmuch as it did not include anything about SDN architecture. It would surely be worth listing SDN architecture 1.1<https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR-521_SDN_Architecture_issue_1.1.pdf> [note: the 1.1 overview link below really refers to issue 1.0; it is out of date and should probably be removed from the listing], the relationship between SDN and NFV<https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/onf2015.310_Architectural_comparison.08-2.pdf>df>, and the paper on SDN and 5G slicing<https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/Applying_SDN_Architecture_to_5G_Slicing_TR-526.pdf>df>.

Because of heavily interrelated recursion, the idea of planes becomes less and less useful. One man’s data plane is another man’s control plane is another man’s applications plane. Management and control form a continuum, not separable planes. Services and orchestration and other concepts that appear in planar models are likewise relative and recursive. The upshot is that we are moving away from the idea of planes as useful modeling concepts. FWIW.

Dave

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Juliano Wickboldt
Sent: Wednesday, August 03, 2016 9:41 AM
To: King, Daniel <d.king@lancaster.ac.uk<mailto:d.king@lancaster.ac.uk>>
Cc: sdn@irtf.org<mailto:sdn@irtf.org>; Broadbent, Matthew <m.broadbent@lancaster.ac.uk<mailto:m.broadbent@lancaster.ac.uk>>; Cristian Lumezanu <lume@nec-labs.com<mailto:lume@nec-labs.com>>
Subject: Re: [Sdn] SDN reading list

Hi Cristian,

Great job organizing this list!

I would suggest that you add a "Management Plane" section under SDN Building Blocks, since you have "Control Plane" and "Data Plane" there already. I can be responsible for maintaining this section if you like. In ONF's architecture document (https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN-ARCH-Overview-1.1-11112014.02.pdf) the Management Plane is defined. There is also an RFC 7426 that considers the Management Plane in SDN's architecture, a bit differently though (https://tools.ietf.org/html/rfc7426).

For example, design considerations for the management plane of SDN have been presented in "Software-Defined Networking: Management Requirements and Challenges. IEEE Communications Magazine: Network and service management series, Volume 53, Issue 1, January (2015). http://dx.doi.org/10.1109/MCOM.2015.7010546"quot;. There are several other studies published mainly in the network management community, i.e., IEEE-NOMS (ieee-noms.org<http://ieee-noms.org>), IEEE-IM (ieee-im.org<http://ieee-im.org>), and CNSM (cnsm-conf.org<http://cnsm-conf.org>), that can be included in this section.

Best regards

________________________________

[http://www.inf.ufrgs.br/~jwickboldt/wp-content/uploads/inf_email.jpg]

Juliano Araujo Wickboldt
Postdoctoral researcher
http://www.inf.ufrgs.br/~jwickboldt/<http://www.inf.ufrgs.br/%7Ejwickboldt/>


On Mon, Aug 1, 2016 at 8:02 AM, King, Daniel <d.king@lancaster.ac.uk<mailto:d.king@lancaster.ac.uk>> wrote:
The reading list looks great, we will add a link to the site from our SDN RG Wiki page.

BR, Dan.

-----Original Message-----
From: sdn [mailto:sdn-bounces@irtf.org<mailto:sdn-bounces@irtf.org>] On Behalf Of Broadbent, Matthew
Sent: 01 August 2016 11:58
To: Cristian Lumezanu <lume@nec-labs.com<mailto:lume@nec-labs.com>>
Cc: sdn@irtf.org<mailto:sdn@irtf.org>
Subject: Re: [Sdn] SDN reading list

Hello Cristian,

Thank you for your time and effort compiling this reading list. It is certainly comprehensive and covers a number of topics; ideal for newcomers to the area.

I would like to suggest, and also take responsibility for, a new sub-area: “Content Delivery”. This would fit under the “SDN Applications” title, and include work on how SDN can be used to improve and facilitate the delivery of video (and other types of media) across the Internet.

Thanks

Matt

―――――――――
Matthew Broadbent
School of Computing & Communications
Lancaster University, UK

On 27/07/2016, 16:36, "sdn on behalf of Cristian Lumezanu" <sdn-bounces@irtf.org<mailto:sdn-bounces@irtf.org> on behalf of lume@nec-labs.com<mailto:lume@nec-labs.com>> wrote:

    Hi everybody,

    I have been maintaining an SDN reading list (https://sites.google.com/site/sdnreadinglist/) for the last four years. My original goal was to provide a centralized repository of SDN research to better help both newcomers and experienced researchers navigate this rather new research area. The number of hits that the website receives every day makes me think that this effort was not in vain. However, as the field of SDN has grown rapidly in the past few years, so has the number of projects, conferences, and papers that I must keep track of and update. This is slowly taking up more time than I can allocate to it and the freshness of the list suffers.

    Therefore, I would like to turn the SDN reading list into a collaborative project. For this, I am looking for volunteers who would like to take over the task of updating (and keeping up-to-date) small parts of the site. A “part” could be a sub-area of SDN research, such as “verification” or “monitoring and measurement". If it’s your own research area, even better, you are probably following all related work anyway and would need little time to keep your part up-to-date.

    If you can help with this, please send me a personal email with what sub-areas you are comfortable updating and any other constraints that you may have. Even if you don’t have time for this but you have suggestions for how this reading list might better serve the community, please send them along.

    Cristian

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


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


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição