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

[Joe Touch <[e-mail]>]

Hi, Lou,

On 7/6/2011 9:49 AM, Lou Berger wrote:
> 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),

Well, my view is that a VN is an overlay (just different names). A VPN 
is a *partial* VN or overlay. I don't know of a kind of overlay I'd say 
wasn't a VN - can you give an example?

> - the requirements for the control interface at the VN/overlay-provider
> boundary.

That implies something like a PPVPN - i.e., a partial overlay setup by a 
provider.

IMO, "provider" is a term of economics, not architecture. I do agree 
that the "interface to configure/control a VN" is interesting, but 
that's just 'yet another network management issue'. It seems, AFAICT, to 
be driven more by net mgt than by VN issues.

Joe

> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/vnrg
>>
>>
>>
>>