Re: [vnrg] Status of the VNRG: Dormant or dead?

Roland Bless <roland.bless@kit.edu> Wed, 06 July 2011 13:10 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: vnrg@ietfa.amsl.com
Delivered-To: vnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8966421F86BF for <vnrg@ietfa.amsl.com>; Wed, 6 Jul 2011 06:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7jSUNLb38yr for <vnrg@ietfa.amsl.com>; Wed, 6 Jul 2011 06:10:03 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id CFBB421F85FB for <vnrg@irtf.org>; Wed, 6 Jul 2011 06:10:00 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1QeRrW-00073Y-56; Wed, 06 Jul 2011 15:09:59 +0200
Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id EAC16A804CD; Wed, 6 Jul 2011 15:09:53 +0200 (CEST)
Message-ID: <4E145EA1.9040601@kit.edu>
Date: Wed, 06 Jul 2011 15:09:53 +0200
From: Roland Bless <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
References: <E84E7B8FF3F2314DA16E48EC89AB49F01CED6E4D@DAPHNIS.office.hd> <4E142E69.5040606@kit.edu> <E84E7B8FF3F2314DA16E48EC89AB49F01CED79D6@DAPHNIS.office.hd>
In-Reply-To: <E84E7B8FF3F2314DA16E48EC89AB49F01CED79D6@DAPHNIS.office.hd>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1309957799.743228000
Cc: "vnrg@irtf.org" <vnrg@irtf.org>
Subject: Re: [vnrg] Status of the VNRG: Dormant or dead?
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2011 13:10:03 -0000

Hi Martin,

On 06.07.2011 12:27, Martin Stiemerling wrote:
>>> One of the areas of discussion was (amongst many others): -
>>> openflow vs. forces - how forces would fit in virtual networks
>> 
>> I see both technologies mainly focused on control plane / data
>> plane separation. This doesn't allow
> 
> What doesn't it allow for? The sentence ends very early.

Yes, sorry that's the problem if you are multi-tasking and not
proof-reading your mail again before hitting "Send" :-)
I wanted to avoid a long discussion but maybe I can explain
it a little bit more. While OpenFlow clearly creates more flexibility,
it is rather static with its possibilities in the forwarding plane.
Though one can "virtualize" an OpenFlow switch by partitioning the
forwarding rules in a switch in combination with a FlowVisor in the
control plane, I suppose that a substrate node with explicit
virtualization support is more flexible.

>>> - do we need tunnel headers for virtual networks on the wi
> Right, and my usage of the word deader is probably wrong, as there
> may be other technologies which use a different light color and not a
> header to distinguish a VN.

Yes. Various multiplex techniques may exist in the substrate
to implicitly address different virtual links. Then one can probably
omit any explicit header encapsulation. Using a different wave length
for a new virtual link is clearly one such mechanism.

> My question wrt the above paragraph: Should the RG run the phase of
> defining terms, concepts and acid tests in parallel to other
> questions? We emphasized on a strong phased operational model for the
> RG until now, but I could imagine a more relaxed operational mode.

I think that parallel activities are not a real problem.
Maybe it's sometimes difficult to discuss things if terminology
isn't agreed upon, but that may also cause synergies, revealing what
concepts or terms are unclear and need more discussion.

Regards,
 Roland