Subject: Re: [Sdn] sdn Digest, Vol 38, Issue 5

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Wed, 22 Jul 2015 09:10:11 +0000

HI Sandra,

May I make you aware of the NetIDE project http://www.netide.eu where we
are experimenting with conflict resolution using an augmented version of
ONOS and/or OpenDaylight? We have github presence and some of the code is
already available.

Do not hesitate to contact me directly for further questions

Best, /PA
---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ Zurbarán,12
28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

El 22/07/15 11:04, "sdn on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> escribió:

>
>Message: 3
>Date: Wed, 22 Jul 2015 09:03:56 +0000
>From: Sandra Scott-Hayward <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Subject: Re: [Sdn] sdn Digest, Vol 38, Issue 4
>Message-ID:
>       <[email-masked]>
>Content-Type: text/plain; charset="us-ascii"
>
>Hi Pedro,
>
>In response to your application resilience question - yes, this is
>definitely a concern. As identified in our analysis, there is little/no
>investigation on this to date and  in my opinion requires further
>research. From what I've seen, Controller designers are making advances
>in the controller clustering and resilience direction and believe that
>state management for applications could follow the same methodology.
>However, as far as I know, they have not got to that point yet.
>
>If you are interested in this work, I am happy to discuss it further with
>you.
>All the best,
>Sandra
>________________________________________
>From: sdn [[email-masked]] on behalf of [email-masked]
>[[email-masked]]
>Sent: 22 July 2015 09:41
>To: [email-masked]
>Subject: sdn Digest, Vol 38, Issue 4
>
>Send sdn mailing list submissions to
>        [email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.irtf.org/mailman/listinfo/sdn
>or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
>You can reach the person managing the list at
>        [email-masked]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of sdn digest..."
>
>
>Today's Topics:
>
>   1. Review of draft-contreras-sdnrg-layered-sdn-03
>      (Kostas Pentikousis)
>   2. SDN Security (Dirk Kutscher)
>   3. Security in SDN controllers presentation
>      (PEDRO ANDRES ARANDA GUTIERREZ)
>   4. Re: draft-contreras-sdnrg-layered-sdn
>      (LUIS MIGUEL CONTRERAS MURILLO)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 22 Jul 2015 00:24:53 +0200
>From: Kostas Pentikousis <[email-masked]>
>To: "[email-masked]"
>        <[email-masked]>
>Cc: SDN IRTF list <[email-masked]>
>Subject: [Sdn] Review of draft-contreras-sdnrg-layered-sdn-03
>Message-ID:
>        <[email-masked]>
>Content-Type: text/plain; charset="us-ascii"
>
>Dear authors, all,
>
>I read draft-contreras-sdnrg-layered-sdn-03 and I find it quite relevant
>for our work in the FELIX project (to be presented at SDNRG on Wednesday
>morning; see
>https://www.ietf.org/proceedings/93/slides/slides-93-sdnrg-7.pdf).
>Specifically, FELIX independently designed an architecture which has a
>number of common elements with CLAS, at least in my mind. I see certain
>commonalities, for example, between the CLAS transport stratum and the
>FELIX Space (see p. 5 of the slides) on the one hand, and between the
>CLAS service stratum and the (FELIX) User Space. As in CLAS, FELIX
>employs dynamic transport bandwidth on demand using the Network Service
>Interface across heterogeneous multiple domains.
>
>I would have liked to see a bit more details about which resources you
>consider and how are they managed and controlled. The use cases section
>points to NFV as well as abstraction and control of transport networks as
>placeholders. Are you planning to complete this section in -04? As you
>can see in the slides, in FELIX we consider SDN, compute and (on demand)
>transit network resources which can be allocated and used through
>policy-based recursive orchestration (see also
>https://datatracker.ietf.org/doc/draft-felix-nfvrg-recursive-orchestration
>/).
>
>Editorial comments:
>
>I find that Section 1 (Introduction) is practically decoupled from
>Section 3, where CLAS is introduced. In addition, it would be good to
>back these points with references because right now no good explanation
>is given for the bullet list of "issues" on p.3 of the draft.
>
>The goals of CLAS need to be more clearly stated upfront.
>
>Terminology: both strata have an SDN controller which is slightly
>confusing. For example, there seems to be a single SDN controller that
>handles the management, control and resource planes (p. 7-8) in the
>service stratum (ditto for the transport stratum), but no explanation is
>provided why this is the case or, indeed, why there is a need to separate
>the planes if one (logical) controller takes care of everything in each
>stratum. Although you do relate CLAS to RFC 7426, you could also consider
>adopting more explicitly some of the terminology of RFC 7426 in section 2
>of the draft.
>
>Further, can you please provide more details on the interaction of the
>"SDN controllers" between the two strata?
>
>Nits:
>
>s/vertical, tight integrated/vertical, tightly integrated
>
>s/and services that relies/and services that rely
>
>s/capture service requirements of services/capture service requirements
>
>s/can provide transfer functions/can provide transport functions
>
>Capitalization is not consistent throughout the draft, e.g. service
>stratum vs. Service stratum vs. Service Stratum
>
>As this is an informational draft, no need for RFC 2119 terminology, and
>all references should be informative only.
>
>
>Best regards,
>
>Kostas
>
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Wed, 22 Jul 2015 07:22:48 +0000
>From: Dirk Kutscher <[email-masked]>
>To: SDN IRTF list <[email-masked]>
>Subject: [Sdn] SDN Security
>Message-ID:
>        <[email-masked]>
>Content-Type: text/plain; charset="us-ascii"
>
>Hi,
>
>Since we are talking about SDN security today, I just wanted to point you
>to http://sdnsecurity.org/ (KAIST, SRI).
>
>Dirk
>
>
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Wed, 22 Jul 2015 07:42:34 +0000
>From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Subject: [Sdn] Security in SDN controllers presentation
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi Sandra, list
>
>When you speak about app resilience, a question pops up to my mind: so
>you have an app that crashes and you want a new instance of this app to
>take control... this can lead to situations where the new instance sends
>commands to the controller that are in conflict with the ones previously
>installed. Doesn't this call for some sort of 'conflict resolution'
>mechanism, construct, ... in the SDN controller?
>
>Best,
>/PA
>
>---
>Dr. Pedro A. Aranda Guti?rrez
>
>Technology Exploration -
>Network Innovation & Virtualisation
>email: pedroa d0t aranda At telefonica d0t com
>Telef?nica, Investigaci?n y Desarrollo
>C/ Zurbar?n,12
>28010 Madrid, Spain
>
>Fragen sind nicht da, um beantwortet zu werden.
>Fragen sind da, um gestellt zu werden.
>Georg Kreisler
>
>________________________________
>
>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
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://mailarchive.ietf.org/arch/browse/sdn/attachments/20150722/0025904
>9/attachment.html>
>
>------------------------------
>
>Message: 4
>Date: Tue, 21 Jul 2015 22:16:06 +0000
>From: LUIS MIGUEL CONTRERAS MURILLO
>        <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Cc: "[email-masked]"
>        <[email-masked]>, "[email-masked]"
>        <[email-masked]>
>Subject: Re: [Sdn] draft-contreras-sdnrg-layered-sdn
>Message-ID:
>
><[email-masked]
>k.com>
>
>Content-Type: text/plain; charset="utf-8"
>
>Hi Dirk
>
>Thanks for the comments received. Please find my answers in-line.
>
>> -----Mensaje original-----
>> De: [email-masked] [mailto:[email-masked]]
>> Enviado el: viernes, 17 de julio de 2015 14:59
>> Para: [email-masked]
>> CC: [email-masked]
>> Asunto: draft-contreras-sdnrg-layered-sdn
>>
>> Dear authors, all,
>> I had a look at recently updated draft-contreras-sdnrg-layered-sdn.
>> IMO this draft describes future generation highly heterogeneous network
>> concepts' issues and cross-domain aspects with respect to SDN de-
>> compositional abstraction.
>> The addition of required features points towards potential research
>>issues to
>> be detailed in the future.
>> I think it is interesting for and should be discussed in this group.
>
>[lmcm>>] Thanks for the comment. In fact heterogeneous networks are the
>real operator environments found nowadays, and this trend will continue
>happen. On the other hand, a common set of services have to be deployed,
>operated and maintained over such heterogeneous infrastructures. This
>proposal intends to separate both Services and Transport specificities
>allowing for different evolution of both strata or layers in the
>framework of SDN.
>
>>
>> Some minor remarks:
>> Sect. 3.1.3 on 'Recursiveness' and sect. 5.3. on 'Multi-domain
>>scenarios in
>> Transport Stratum' seem to be interrelated which might be pointed out by
>> corresponding references.
>
>[lmcm>>] There is certainly some relationship. This would be the case of
>having a lower Service stratum in charge of composing multi-domain
>transport capabilities to offer them as a single Transport stratum
>capabilities to some higher Service stratum on top of it. Apart of
>composing resources some other rich functionalities could be expected,
>like e.g. SLA maintenance.
>
>I wonder whether also 5.1.2. on 'Single service
>> stratum associated to multiple Transport strata' should be mentioned
>>here -
>> having the orchestrator in service stratum as providing recursiveness,
>>if I
>> have understood it correctly
>>
>
>[lmcm>>] This would be actually two different cases. One single Service
>Stratum associated to multiple Transport Strata is aware of the different
>transport capabilities offered by the different Transport strata, while
>in the recursivenes + multi-domain transport scenario the higher Service
>Stratum is aware (or not necessary aware) of the multiple underlying
>Transport Strata.
>
>
>> p.4
>> o  Service: denote a logical construct that make use of => o  Service:
>>denotes
>> a logical construct that makes use of
>>
>[lmcm>>] Thnaks, noted.
>
>> The SDN intelligence relies on inputs form various => The SDN
>>intelligence
>> relies on inputs from various
>>
>[lmcm>>] Thanks, noted
>
>> SDN intelligence => apart from the definition paragraph this expression
>>is not
>> used throughout the document ... perhaps it should be mentioned for SDN
>> controller functionalities or when talking on service/network
>>intelligence
>> again?
>[lmcm>>] Thanks for pointing it out. One of the pending topics for future
>versions is the fact of describing building blocks for the proposed
>architecture. Some of those components would form such SDN intelligence,
>e.g., path computation capabilities, etc. We will include such
>information for next version of the document.
>
>> p.8
>> The Service SDN controller acts as a client of the Transport SDN
>>controller
>[lmcm>>] Is this comment maybe not complete?
>
>________________________________
>
>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
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>sdn mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/sdn
>
>
>------------------------------
>
>End of sdn Digest, Vol 38, Issue 4
>**********************************
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>sdn mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/sdn
>
>
>------------------------------
>
>End of sdn Digest, Vol 38, Issue 5
>**********************************

________________________________

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