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:[email protected]] En nombre de Dave Hood Enviado el: miércoles, 3 de agosto de 2016 20:22 Para: Juliano Wickboldt <[email protected]>; King, Daniel <[email protected]> CC: Broadbent, Matthew <[email protected]>; [email protected]; Cristian Lumezanu <[email protected]> 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>, 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>. 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:[email protected]] On Behalf Of Juliano Wickboldt Sent: Wednesday, August 03, 2016 9:41 AM To: King, Daniel <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Broadbent, Matthew <[email protected]<mailto:[email protected]>>; Cristian Lumezanu <[email protected]<mailto:[email protected]>> 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";. 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 <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] On Behalf Of Broadbent, Matthew Sent: 01 August 2016 11:58 To: Cristian Lumezanu <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> 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" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.irtf.org/mailman/listinfo/sdn _______________________________________________ sdn mailing list [email protected]<mailto:[email protected]> https://www.irtf.org/mailman/listinfo/sdn _______________________________________________ sdn mailing list [email protected]<mailto:[email protected]> 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
_______________________________________________ sdn mailing list [email protected] https://www.irtf.org/mailman/listinfo/sdn
