Subject: Re: [Sdn] draft-contreras-sdnrg-layered-sdn

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 21 Jul 2015 22:16:06 +0000

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

---

From: <[email-masked]>
Date: Wed, 22 Jul 2015 10:29:53 +0200

Dear Luis,
thaks for the clarifying answers.
Unfortuantely my mail was obvuiously notcompletely transmited ... so here are my further original comments... although some n´might be already resiólved by your reply. 
Thanks!

p.8
The Service SDN controller acts as a client of the Transport SDN controller.
=> since you describe both multi-service per transport and multi-transport per service I wonder whether it could be also the other way round and suggest to add some thoughts on it here.

   Consistecy is determined
=>   Consistency is determined
Forwarding may not be rely on => Forwarding may not rely on/be dependent on
p.10
(e.g., one database keeping some register for the end user).
Do you mean: => (e.g., one database keeping some register for the end user whereas another register stores transport infrastructure data). ??
    
p.12
This service
   is focused on the provision of transport capabilities, then different
   of the final communication service using such capabilities.
Do you mean: => This service is focused on provisioning a single interface to heterogeneous transport capabilities, so that different final communication services can be using such capabilities.
Or: => This abstraction service denotes one focused on the provision of transport capabilities, and such is totally different from a traditional communication service using the capabilities provided by this abstraction service.

can provide an homogeneous abstract view => can provide a homogeneous abstract view
Thanks a lot!
Best Regards
Dirk 

-----Original Message-----
From: LUIS MIGUEL CONTRERAS MURILLO [mailto:[email-masked]] 
Sent: Mittwoch, 22. Juli 2015 00:16
To: von Hugo, Dirk
Cc: [email-masked]; [email-masked]
Subject: RE: draft-contreras-sdnrg-layered-sdn 

Hi Dirk

> De: [email-masked] [mailto:[email-masked]] Enviado 
> el: viernes, 17 de julio de 2015 14:59
> 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.

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

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

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 22 Jul 2015 20:39:50 +0000

OK Dirk, so please, find my comments in-line

Thanks

Luis

> Enviado el: miércoles, 22 de julio de 2015 10:30
> Para: LUIS MIGUEL CONTRERAS MURILLO
> CC: [email-masked]; [email-masked]
> Asunto: RE: draft-contreras-sdnrg-layered-sdn
>
>
>
> Dear Luis,
> Unfortuantely my mail was obvuiously notcompletely transmited ... so here
> are my further original comments... although some n´might be already
> resiólved by your reply.
> Thanks!
>
> p.8
> => since you describe both multi-service per transport and multi-transport
> per service I wonder whether it could be also the other way round and
> suggest to add some thoughts on it here.

[lmcm>>] Typically is the service stratum the one requesting transport capabilities to connect the service endpoints. However some bidirectional communication can be expected. For instance, in case of congestion or for optimization purposes the Transport Stratum could notify to the Service Stratum the convenience of rearranging the service end points (if possible) in order to avoid congestion or to optimize network resources respectively.

> =>   Consistency is determined

[lmcm>>] Thanks, noted.

> Forwarding may not be rely on => Forwarding may not rely on/be dependent

[lmcm>>] Thanks, noted.

> Do you mean: => (e.g., one database keeping some register for the end user
> whereas another register stores transport infrastructure data). ??

[lmcm>>] The sense of the sentence is to highlight that some resources of the Service Stratum do not necessarily need associated transport resources. For instance a Binding Cache in PMIPv6, a DB for an HLR, etc, do not need to be attached to (WAN) transport resources for service completion. Hoper the examples can be meaningful.

> Do you mean: => This service is focused on provisioning a single interface to
> heterogeneous transport capabilities, so that different final communication
> services can be using such capabilities.
> Or: => This abstraction service denotes one focused on the provision of
> transport capabilities, and such is totally different from a traditional
> communication service using the capabilities provided by this abstraction
> service.

[lmcm>>] The second interpretation is the one correct. I note it to clarify the text and avoid misunderstandings.

> can provide an homogeneous abstract view => can provide a homogeneous

[lmcm>>] noted, thanks

Thanks a lot!
> Dirk
[lmcm>>] Thanks a lot for your comments. I will take care of them on behalf of the co-authors for the next version of the document. Best regards, Luis

> From: LUIS MIGUEL CONTRERAS MURILLO
> [mailto:[email-masked]]
> [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:
> [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.
>
> [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
> [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
> 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