Subject: Re: [Sdn] Poll for RG Adoption - draft-contreras-sdnrg-layered-sdn

From: Gert Grammel <[email-masked]>
Date: Sun, 21 Feb 2016 17:43:05 +0000

Dan,

Support

It contributes to abstraction in the context of SDN. In IETF
https://datatracker.ietf.org/doc/draft-ietf-ccamp-interconnected-te-info-ex
change/ discusses such abstraction for the purpose of Traffic Engineering
but doesn¹t deal with the service. Also aspects like QoS have not been
tackled there.

Going forward, the aspect of transport attached services would need to be
worked out more explicitly to harden the abstraction.
1) A DSL service is attached to a particular copper cable that cannot be
virtualised. Moving a home Gateway to another DSL Line wouldn¹t provide a
service. So the transport is an essential part of the service.
2) For a Mobile service, one can move a SIM card between devices (even if
not owned by the same person) and get a service. Whether this service is
the same between devices however depends on the Mobile phone capabilities.
Here the SIM-HW is part of the service, but the transport (Mobile) is not.
3) A VoIP service can be made available on practically any device
connected by any transport to the internet, but access to that service may
be limited by firewall policies and alike. Here no HW is part of the
service but transport influences the quality.

So linking transport related information with service related information
in an efficient and abstracted manner is indeed an issue and worth to look
at. A collaborative architecture seems to be a good sarting point.

Gert

On 2016-15-02 14:26, "sdn on behalf of King, Daniel" <[email-masked]
on behalf of [email-masked]> wrote:

>Greetings SDN Researchers,
>
>At IETF 94 we had a request from the authors of "Cooperating Layered
>Architecture for SDN" to poll the Research Group for adoption of their
>document:
>
>o If you missed their presentation at IETF 94 -
>https://www.ietf.org/proceedings/94/slides/slides-94-sdnrg-2.pdf
>o The current version of the document -
>https://tools.ietf.org/html/draft-contreras-sdnrg-layered-sdn-04
>
>We would like to open a two-week adoption call the document, but
>specifically ask that a "support" or "no support" response be
>substantiated with accompanying comments discussing why the document
>should be adopted, or indeed not.
>
>Kind Regards,
>Dan & Kohei

---

From: Jacek Wytrębowicz <[email-masked]>
Date: Wed, 24 Feb 2016 22:36:09 +0100

Dear All

I support the adoption of this document. 

The document decomposes a complex problem in a logic way, which can help in design of more flexible and maintainable SDN controllers. It is a good starting point for further works. However I would propose to split the architecture into three stratums: Service, Transport and Resource. The Resource Stratum should contain the Control and Management Planes as well. The following functionalities: resource capability discovery, real time control (e.g. providing redundancy for high reliability, dealing with failures) and configuration management, they are logically different from transport or service functionalities. They are instrumental for Transport and Service Stratums.

I agree with all of you who argue for better motivation and convincing use cases. I would argue to provide the use cases with some working code as a proof of concept. Well known SDN use cases can be adopted for this reason, e.g. calendaring for virtual machines migration or multicast streaming of IPTV channels.

Best Regards,
Jacek Wytrębowicz

> At IETF 94 we had a request from the authors of "Cooperating Layered Architecture for SDN" to poll the Research Group for adoption of their document: 
> 
> o If you missed their presentation at IETF 94 - https://www.ietf.org/proceedings/94/slides/slides-94-sdnrg-2.pdf <https://www.ietf.org/proceedings/94/slides/slides-94-sdnrg-2.pdf>
> o The current version of the document - https://tools.ietf.org/html/draft-contreras-sdnrg-layered-sdn-04 <https://tools.ietf.org/html/draft-contreras-sdnrg-layered-sdn-04>
> 
> We would like to open a two-week adoption call the document, but specifically ask that a "support" or "no support" response be substantiated with accompanying comments discussing why the document should be adopted, or indeed not.
> 
> Kind Regards, 
> Dan & Kohei