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

Joe,
	I really like & agree with much of what you say, particularly WRT
openflow, forces, and VPNs.

I think some potentially interesting topics for discussion would be:
- the differences (in requirements) between a VN and an overlay network
  (VPNs are just one type of overlay network after all),
- the requirements for the control interface at the VN/overlay-provider
boundary.

Lou

On 7/6/2011 11:51 AM, Joe Touch wrote:
> Hi, all,
> 
> (speaking as an individual participant)
> 
> On 7/6/2011 2:44 AM, Roland Bless wrote:
> ...
>>> We had the last meeting at the Beijing IETF meeting and also some lively discussion afterwards.
>>>
>>> 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.
> 
> 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.
> 
>>> - do we need tunnel headers for virtual networks on the wire or not?
>>
>> 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.
> 
>>> - definition of acid tests
>>
>> Not only definition of acid tests, but also definition of
>> terms. For instance, how differ traditional VPNs from Virtual
>> Networks in the context of network virtualization? IMHO current
>> VPN solutions concentrate mainly on virtual links, advanced concepts
>> consider virtual nodes as active elements.
> 
> 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.
> 
> 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.
> 
> 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.
> 
>  > 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).
> 
>>> 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... ;-)
> 
> Joe
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg
> 
> 
> 
>