Subject: [Sdn] Review of draft-contreras-sdnrg-layered-sdn-03

From: Kostas Pentikousis <[email-masked]>
Date: Wed, 22 Jul 2015 00:24:53 +0200

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 22 Jul 2015 21:17:44 +0000

Hi Kostas

Thanks for your comments. Please, see my comments in-line

Best regards

Luis

> -----Mensaje original-----
> De: Kostas Pentikousis [mailto:[email-masked]]
> Enviado el: miércoles, 22 de julio de 2015 0:25
> Para: [email-masked]
> CC: SDN IRTF list
> Asunto: Review of draft-contreras-sdnrg-layered-sdn-03
>
> 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.

[lmcm>>] My understanding from the slide 5 of your presentation is that FELIX Space represents a multi-domain transport scenario, focused on providing transport capabilities to connect service end-points determined by the User Space. If such understanding is correct, the architecture shows commonalties with CLAS. Different SDN environments are used in the distinct spaces, and I wonder (not clear to me from the slides) that there is interaction between both environments to provide the final service to the end user. From that perspective, FELIX architecture fits CLAS architecture proposal.

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

[lmcm>>] Yes, that is the intention. For instance, some progress have been done in NFV with contribution to ETSI NFV EVE working group based on CLAS architecture. Our intention is to describe in this document such ideas. For ACTN case we have also some on-going work. More use cases will be explored. FELIX could be also an study case, in my understanding.

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/).
>

[lmcm>>] Thanks for the pointer. I will take a look to understand commonalties.

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

[lmcm>>] Noted. We will try to provide more consistency and more arguments for the identified issues.

> The goals of CLAS need to be more clearly stated upfront.

[lmcm>>] Noted. In line with your previous comment, probably a more clear motivation section is required.

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

[lmcm>>] Different planes have different responsibilities. Real implementation could consider to integrate all (or part) of those planes on the same box or application. From a carrier/operator perspective I think is necessary for operational reasons to have clear differentiation of the three planes.

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.

[lmcm>>] Noted. I agree it could be convenient to adopt more terminology already presented on RFC 7426. I take the action of providing that for next document version.

> controllers" between the two strata?

[lmcm>>] This is an on-going work. Some ideas are already presented (but not well structured) in section 4: monitoring, accounting, orchestration, secure communication, etc. More details should come in future versions. I guess that input from FELIX experience can benefit the draft.

> references should be informative only.
[lmcm>>] Thanks for all of these nits. Noted.
> Kostas

________________________________

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