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

[Roland Bless <roland.bless at kit.edu>]

Hi Joe and all,

On 06.07.2011 17:51, Joe Touch wrote:
> I agree, and don't see either as particularly relevant to VNs. They're
> implementation issues, AFAICT. The more relevant technology to me is
> router virtualization.

Yep, agree.

>> That depends on the substrate technology, some allow to embed a "VNet
>> Tag" to identify different virtual links, e.g., VLAN-Tags in Ethernet
>> headers.
> 
> Again, this is an implementation issue. I would expect some sort of
> indicator of VN, which can be buried inside an existing header or can
> require an additional header.

Correct, I just provided an example.

> IMO, a VPN extends an existing network to add a new node, or ties two
> existing networks together, i.e., it's a way to add a single private
> link to a new node.

> Further, VPN nodes are always a member of exactly one VPN.

Usually, yes, though one can think of VPN concentrators providing
access to several different VPNs

> A PPVPN is a network provided by another party (the provider) so that
> users can join it via basically conventional VPN methods.
> 
> I don't think of VPNs as addressing either link or router multi-use,
> either.

Yep.

> None of this is true of VNs, IMO - a VN is a complete E2E network, can
> coexist with many other VNs (even to the same endpoint nodes), etc.

Agree.

>> How do OpenFlow concepts fit
>> into the classification?
> 
> IMO, Openflow is a tool; it does not define a network architecture. It
> can be useful in moving some network issues elsewhere (e.g., allowing a
> non-VPN capable node to join a VPN, or helping to implement router
> virtualization outside a router that doesn't support it). I don't see
> Openflow as anything other than one of many tools here - and one I've
> never needed to develop VNs (if others do, I'd be glad to hear why).

Agree.

>>> What do you see is important for the RG right now or what is missing?
>>
>> See above, but maybe we should also consider questions such as
>> what interfaces and protocols are needed for creating inter-provider
>> virtual networks.
> 
> That seems to presume we know what an intra-provider VN is, and I'm not
> sure we're all on a single page there... ;-)

Ok, I meant a VN spanning several substrate providers (or to use
4WARD terminology: Infrastructure Providers - InPs) in
contrast to a VN inside a single InP, which can be provided
by using proprietary protocols.

Regards,
 Roland