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 at irtf.org > https://www.irtf.org/mailman/listinfo/vnrg > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.