L3VPN @ IETF82 in Taipei VPN4DC session 1. Agenda bashing & introduction Ð 3mins 2. VPN4DC Background & Problem space (Ping Pan) - 10mins [Holding Questions till End] 3. VPN4DC Requirements (Ning So) - 10mins [Holding Questions till End] 4. VPN4DC Proposed scope of work (Luyuan Fang) - 10mins [Session open for questions] [Ben Ð Co-Chair] You discuss hybrid solutions (hybrid VPN), can you elaborate. [Luyuan Fang] There may be different hybrid solutions. There could also be stitching of VPNs. [Dave McDysan] One consideration is that the DCs move hosts around, the resources are virtualized, there are architecture alternatives. You want to leverage the existing VPN technology, but stability is a key issue. [Luyuan Fang] We will not reinvent the wheel. [Paul Unbehagen] That list of names, points to SPs, these requirements are also reflected by enterprise customers. [Igor] Three clarifying questions, are you including xLAN, GRE, et al? [Luyuan Fang] If there are L3 enhancements, then yes. [Igor] Re: Resource allocation. Are we talking about L3VPNs to manage resources? [Ning So] When I compiled the requirements, we did not envision L3 performing this. These can be viewed as an attached VRF- storage, this provides the capability to attach storage resources to VPNs(?). [Igor] Various technologies exist to solve these problems, like OpenStack. Are we saying we need alternatives? [Ning So] We are aware of those solutions, but these (over-the-top solutions) make things difficult. Actually, many solutions are proprietary. From enterprise to providers, which required significant internetworking. [Igor - Operator] Actually, I strongly disagree. They have near infinite ram, they are not slow or not scalable. [Luyuan Fang] We do not exclude over-the-top. We are not excluding L3 technologies, IP, MPLS, et al. in the widest possible sense. [Who? Mark L?] I am not sure decoupling solutions, this may make sense, especially as some are L2 and others are L3. [Luyuan Fang] Our goal is scalability. [Stewart Bryant] We are not going to make the decision today, we are going to take this off and later figure out how whether this is done in zero one or several WG [Everet (Google)] - Over the top is slow is as a canard. It need not be [Ed Crabbe] Over-the-top is good. [Craig White] Does this include VM to VM? [Ning So] Two comments, the hybrid solution is a likely case for implementation. 2) OSS/Over-the-top, compare this to SPs internetworking with enterprise customers, cause ÒissuesÓ. They is a problem with inter-connection, we do not state how we can inter-connect. [Chris Liljenstolpe (ex-Telstra)] I disagree, my view I can use meta-data (over-the-top) far faster and far more scalable than a control plane. [Paul] I feel we are overreaching, the work in this was simplifying the MPLS cloud into the DC. This does not solve the problem in ÒotherÓ places. There are vast customers who want a VRF-DC. This is much broader. L2 is integral to L3. [Kiretti Kompella] We have a problem. We are trying to squeeze this into the wrong WG. [Stewart] We are gathering information to structure the right WG [Igor] We are trying to solve the problem from bottom up, instead of top down. People can do this with OpenFlow. We should not phrase the problem in the way of a solution. [Ron Bonica] When I walked into this room, I thought we would be talking about 4334 updates, we are not. We are talking about how a bunch of DCs might do business. We should probably bring this into Ops Area. Here we should only be dealing with Routing issues. [Dave Harrington] We had a BoF request and the IESG, we brought it here because we wanted to know if this was applicable to L3VPN or a much wider discussion. [Tom Nadeu] There is an SDN BoF that will discuss these problems from the over-the-top angle. [Chris] You mentioned L2 was out of scope from day 1. If you asked DCs you would find they want to fix L2 first. [Tomas Morin] I want to define to the bigger problem. A reply to Igor and Christopher, the goal is not to say VPNs are the solution. We have operational cases where L3VPN is the starting point. [Ben] Raise your hand if you have read the problem statement drafts. Approx 66% of the room raised their hand. [Ben] Raise you hand if you think there is some problem(s) that need solving Approx 66% of the room raised their hand. [Ben] Raise you hand if you think the problem space is well understood. No-one raised their hand [Ben] Raise you hand if you think this is a problem space IETF should work on. Approx 66% of the room raised their hand. [Ben] Raise you hand if you are prepared to actively work on this. Approx 50% of the room raised their hand. [Out of time, co-chairs requested further discussion on the list]