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

Jacek Wytrębowicz <> Wed, 24 February 2016 21:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA61F1B41DD for <>; Wed, 24 Feb 2016 13:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.479
X-Spam-Level: *
X-Spam-Status: No, score=1.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T5vsZRj5oWjh for <>; Wed, 24 Feb 2016 13:36:14 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70C8F1B3371 for <>; Wed, 24 Feb 2016 13:36:13 -0800 (PST)
Received: from pc3.home ( []) by (AIX5.3/8.13.4/1.2.3) with ESMTP id u1OLaAI3856222 for <>; Wed, 24 Feb 2016 22:36:10 +0100
From: =?utf-8?Q?Jacek_Wytr=C4=99bowicz?= <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_67CCB0EB-880B-414E-8733-F0E51E771FBD"
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Wed, 24 Feb 2016 22:36:09 +0100
References: <>
In-Reply-To: <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Subject: Re: [Sdn] Poll for RG Adoption - draft-contreras-sdnrg-layered-sdn
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List to Discuss SDN Research Group in the IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2016 21:36:17 -0000

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

> 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 - <>
> o The current version of the document - <>
> 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