Subject: IETF82 L3VPN minutes now available

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 23 Nov 2011 17:23:07 +0000

Colleagues,

We just posted the draft minutes for the L3VPN/VPN4DC session at IETF last week.

You can view them here:

http://www.ietf.org/proceedings/82/minutes/l3vpn.txt

Thanks to Daniel King for scribing the session.

Please send any corrections/omissions/etc to the chairs and/or the mailing list.

Thanks
Ben

---

From: Derick Winkworth <[email-masked]>
Date: Fri, 25 Nov 2011 03:00:43 -0800 (PST)

All:

(a) I understand that MPLS L3VPN is not used, favored, or even approved of, by many folks.  

This does not change the fact that MPLS is a widely used technology that solves problems and generates revenue for organizations.  Its not unreasonable to seek to integrate MPLS VPNs with virtual-server technologies.  It *is* unreasonable to say that MPLS shouldn't be part of the discussion.  These networks aren't going away and the driver behind the VPN4DC discussion is that many customers are asking for this type of integration (between VMs and MPLS VPN instances).  

(b) I also understand that some people have scale problems so great that it amounts to a problem that 99% of the world does not have.  

Not everyone has 2 or 3 million VMs in a datacenter and the requirement to migrate 200k of them at a time.   I think that trying to come up with a one-size-fits-all solution that scales this large for those cases is not reasonable.  MPLS is perfectly acceptable for smaller numbers of VMs/tenants.

(c) Some people think that this amounts to something like private cloud and this is the wrong direction (on principle, or philosophically) for the technology industry to go in.  We should be pushing towards public-cloud solutions that use IPSec VPN or vCider.  

I don't think this objection is relevant to this discussion.  I think this amounts to religion.  I think also this objection might have something to do with the business some people are in... the business of being a public cloud provider.  A standardized protocol that would allow VMs to be automatically stitched up via some kind of path isolation to a VRF or VPLS instance would represent a competitive threat to existing public-cloud services.

(d) Some people think (on principle, or philosophically) that we should start solutioning everything with SDN.  

I strongly disagree.  SDN is quite fascinating, but things like OpenFlow and Openstack are tools.  They are not solutions.  Some of us *have* used a collection of APIs already to automate the provisioning we are speaking of.  As soon as you change any vendor in the chain, you have to start re-coding against a new API (assuming such an API is even exposed).  It sure would be nice if there was some kind of standards body that we could work within the framework of to create some kind of standard.  These APIs do not directly address the problem we are trying to solve.

----

1. There are potentially [enterprise <-> SP] protocols that do things like signal for the creation of a VM or change operating characteristics of the VM or storage associated with the VM.  These protocols could be generalized and should probably be XML based.

2. Then there are protocols internal to the MPLS SP's DC that stitch up the VM to an L3VPN/L2VPN instance.  These exist further down the workflow from #1.  I think this is a specific problem requiring specific mechanisms separate from the ones mentioned in the previous paragraph.  It could also be XML based, but I could see it being otherwise based on some of the drafts already submitted that address this.

Perhaps the scope of VPN4DC should be limited to #2 and exclude #1?  

Derick

________________________________
 From: Ben Niven-Jenkins <[email-masked]>
To: "[email-masked] mailing list" <[email-masked]> 
Sent: Wednesday, November 23, 2011 11:23 AM
Subject: IETF82 L3VPN minutes now available
 
Colleagues,

You can view them here:

Thanks
Ben