Comment reg draft-gs-vpn-scaling-00.txt

[Robert Raszuk <[e-mail]>]

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.
>
> http://tools.ietf.org/html/draft-gs-vpn-scaling-00
>
> Thanks,
>
> Wes George
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] Sent: Monday, October 24, 2011 5:20
> PM To: George, Wes Cc: [e-mail]; 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.