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

From: Sandra Scott-Hayward <[email-masked]>
Date: Wed, 22 Jul 2015 09:03:56 +0000

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/00259049/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]>

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
**********************************