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

Lou, all,

I do not agree that VPN's are overlay network's alike. 
On the contrary, you have VPNs L2 and L3. The ones provided by each Network
Providers, on which you need to do the provision and the setup on physical
hardware routers. 

Interesting topics for discussing that I would put effort  on:
"How to scale VNs to the order of Thousands"
"How to switch from VPNs to VNs - What's hanging it up on Network Providers"
"How to manage VNs - Centralized vs Distributed"

Best Regards,
Márcio Melo

> -----Original Message-----
> From: vnrg-bounces@irtf.org [mailto:vnrg-bounces@irtf.org] On Behalf Of
> Lou Berger
> Sent: quarta-feira, 6 de Julho de 2011 17:49
> To: Joe Touch
> Cc: vnrg@irtf.org
> Subject: 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
> >
> >
> >
> >
> _______________________________________________
> vnrg mailing list
> vnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/vnrg