Subject: [GROW] FW: New Version Notification for draft-gs-vpn-scaling-00.txt

From: "George, Wes" <[email-masked]>
Date: Mon, 24 Oct 2011 17:41:16 -0400

Hi-

Rob Shakir and I have been working on a draft that discusses some scaling considerations for L3VPN networks. We posted this today in order to meet the 00 deadline, but it's still most definitely a work in progress, and we are not necessarily looking to present it at Taipei unless there is definite interest from the group in having at least an initial F2F discussion.
We were mainly just looking for some initial feedback on whether this is work the group thinks would be useful, since we weren't certain exactly where something like this fits. L3VPN seems logical given the subject matter, but often scaling considerations with an operational focus like this end up in GROW. But, GROW focuses on internet routing and therefore might not be a good fit other than being a place where folks with ideas that might be helpful to this draft tend to hang out, hence the cross-post.

We're also looking for folks willing to help us flesh out some of the sections that are still missing info, especially as far as multicast is concerned, give us other suggestions. Please have a look.

http://tools.ietf.org/html/draft-gs-vpn-scaling-00

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 24, 2011 5:20 PM
To: George, Wes
Cc: [email-masked]; George, Wes
Subject: New Version Notification for draft-gs-vpn-scaling-00.txt

A new version of I-D, draft-gs-vpn-scaling-00.txt has been successfully submitted by Wesley George and posted to the IETF repository.

Filename:        draft-gs-vpn-scaling
Revision:        00
Title:           IP VPN Scaling Considerations
Creation date:   2011-10-24
WG ID:           Individual Submission
Number of pages: 20

Abstract:
   This document discusses scaling considerations unique to
   implementation of Layer 3 (IP) Virtual Private Networks, discusses a
   few best practices, and identifies gaps in the current tools and
   techniques which are making it more difficult for operators to cost-
   effectively scale and manage their L3VPN deployments.

The IETF Secretariat

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Oct 2011 04:07:10 +0200

Hi Wes,

What a perfect timing ...

I very much agree with the scaling aspects of L3VPN service model you
have described in the draft. Clearly more hardware is not the answer ..
well at least for the operator side - considering that such hardware is
not a commodity one especially when our customers continue to expect
more for less.

The lack of scaling of L3VPNs has been the topic of discussions for some
time now among many operation teams of service providers.

There are two main concerns that arise - route scaling and platform scaling.

My observation is that there are two main issues which are major
contributors to the problem:

- the aspect of directly attaching a VPN site's CE to service provider
   PE

- the aspect of converting all customer routes to one common VPNv4/v6
   container which becomes too heavy to carry around

Originally I was personally investigating the idea of at least
eliminating the latter by converting the L3VPN model to be more of CSC
type (even for regular CE sites which would not run MPLS). However that
type of approach still carries the inflexibility issue of directly
attachment of sites which while for some sites are just fine, but for
others are usually beyond the local reach of the L3VPN SP provider.

 From that point I and few other colleagues of mine have started to think
about completely new way to accomplish L2 or L3VPN services ranging from
mobile smartphone as CE to large site as CE. Moreover such VPN service
can be provided not essentially by locally present network operator.

The name I invented for it is VaaS (VPN-as-a-Service) which especially
now could be easily offered as a new type of cloud application.

In a nut shell the fundamental problems are solved by removing the
requirement to attach customer to any PE box - VaaS control plane server
can be accessed by any means of user internet connection.

It also completely removes the need to combine VPN site's routing
information .. you keep routes of each VPN sites in a separate routing
slice - also residing on the control plane server or VM. With dynamic
allocation of compute and storage which is becoming a commodity in any
modern data center one could easily observe that scaling aspects of such
a service model becomes very much shifted from vendor devices to
commodity computing and storage managed by intelligent and very dynamic
data centers' job distribution tools.

Also while this is still very much work in progress I would encourage
anyone concerned with today's L3VPN scale to read and provide comments
and opinions on the below document.

http://www.ietf.org/internet-drafts/draft-ko-vaas-problem-statement-00.txt

As a matter of fact I am still adding some framework text reg routing
information exchange to this draft this week so perhaps next week (if I
manage to find enough time) there would be a -01 version posted.

By bringing this to the IETF we are presenting the idea for open
contribution by anyone interested both in the architecture space as well
as possible open source implementations.

Best regards,
R.

> Hi-
>
> Rob Shakir and I have been working on a draft that discusses some
> scaling considerations for L3VPN networks. We posted this today in
> order to meet the 00 deadline, but it's still most definitely a work
> in progress, and we are not necessarily looking to present it at
> Taipei unless there is definite interest from the group in having at
> least an initial F2F discussion. We were mainly just looking for some
> initial feedback on whether this is work the group thinks would be
> useful, since we weren't certain exactly where something like this
> fits. L3VPN seems logical given the subject matter, but often scaling
> considerations with an operational focus like this end up in GROW.
> But, GROW focuses on internet routing and therefore might not be a
> good fit other than being a place where folks with ideas that might
> be helpful to this draft tend to hang out, hence the cross-post.
>
> We're also looking for folks willing to help us flesh out some of the
> sections that are still missing info, especially as far as multicast
> is concerned, give us other suggestions. Please have a look.
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Monday, October 24, 2011 5:20
> PM To: George, Wes Cc: [email-masked]; George, Wes Subject: New Version
> Notification for draft-gs-vpn-scaling-00.txt
>
> A new version of I-D, draft-gs-vpn-scaling-00.txt has been
> successfully submitted by Wesley George and posted to the IETF
> repository.
>
> Filename:        draft-gs-vpn-scaling Revision:        00 Title:
> IP VPN Scaling Considerations Creation date:   2011-10-24 WG ID:
> Individual Submission Number of pages: 20
>
> Abstract: This document discusses scaling considerations unique to
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 25 Oct 2011 10:57:35 -0400

Robert - thanks. Indeed Rob and my hope in posting this draft was to have a good solid discussion about problems and gaps so that we were clearly articulating some of the issues we're facing, with the goal that folks within the IETF could come up with some creative solutions to help out, even possibly adapting some of the things that are being proposed within GROW to help with Internet Route scaling in order for them to help with VPN route scaling.
I'm of the mind that it makes sense to limit the scope of the current document to discussing problems/gaps and best practices. Then, either the solutions drafts can use that as a framework to cite specific items that they are working to resolve, or perhaps there is a follow-on draft that catalogs/surveys some potential solutions, pros/cons, etc.

Meantime, since you've been thinking about this problem as well, we'd welcome feedback to improve the text of the draft! :-)

Wes George

> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Monday, October 24, 2011 10:07 PM
> To: George, Wes
> Cc: [email-masked]; [email-masked]; Rob Shakir; Michael Ko
> Subject: Comment reg draft-gs-vpn-scaling-00.txt
>
> Hi Wes,
>