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

[Lou Berger <[e-mail]>]

Joe,

see below

On 7/6/2011 1:14 PM, Joe Touch wrote:
> 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). 

I suspect that a VN is a special case of an overlay, e.g., perhaps in
it's dynamic membership/instantiation properties.

> 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?

I guess the answer depends on your definition of a VN.  Do you have a
good formal definition handy?  I'd love to see one we can all agree to.
 (Which was sort of the aim of the question.)

> 
>> - 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.

Not necessarily, there are lots of overlay types and control
protocols/interfaces to support them.  For example MPLS hierarchy and
ethernet vlans are both examples of overlay technologies that can be
dynamically controlled.

> 
> IMO, "provider" is a term of economics, not architecture. 

Okay, that's a legitimate usage.  I was using more generally to cover
the case to refer to include the mechanisms used to instantiate and
transport/support the overlay.  Do you have an alternate term?  The
ITU-T likes the terms client and network...

> 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.

I may be biased by my other activities, but I don't see a reason why
this can't also include a control plane based interface.

Lou

> 
> 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
>>>
>>>
>>>
>>>
> 
> 
> 
>