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

"George, Wes" <wesley.george@twcable.com> Tue, 25 October 2011 14:57 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: l3vpn@ietfa.amsl.com
Delivered-To: l3vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DC221F8AF4; Tue, 25 Oct 2011 07:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bhfsOn9IvH6; Tue, 25 Oct 2011 07:57:33 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87B21F8AF6; Tue, 25 Oct 2011 07:57:33 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,403,1315195200"; d="scan'208";a="289331584"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2011 10:53:43 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 25 Oct 2011 10:57:32 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "robert@raszuk.net" <robert@raszuk.net>
Date: Tue, 25 Oct 2011 10:57:35 -0400
Subject: RE: Comment reg draft-gs-vpn-scaling-00.txt
Thread-Topic: Comment reg draft-gs-vpn-scaling-00.txt
Thread-Index: AcySus946TmyRpWZQaqQKi6GeDuXhgAaljbw
Message-ID: <DCC302FAA9FE5F4BBA4DCAD465693779145148805A@PRVPEXVS03.corp.twcable.com>
References: <DCC302FAA9FE5F4BBA4DCAD4656937791451487CA0@PRVPEXVS03.corp.twcable.com> <4EA619CE.80408@raszuk.net>
In-Reply-To: <4EA619CE.80408@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Rob Shakir <rjs@cw.net>, "grow@ietf.org" <grow@ietf.org>, "l3vpn@ietf.org" <l3vpn@ietf.org>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 14:57:34 -0000

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


> -----Original Message-----
> From: Robert Raszuk [mailto:robert@raszuk.net]
> Sent: Monday, October 24, 2011 10:07 PM
> To: George, Wes
> Cc: l3vpn@ietf.org; grow@ietf.org; Rob Shakir; Michael Ko
> Subject: Comment reg draft-gs-vpn-scaling-00.txt
>
> 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: internet-drafts@ietf.org
> > [mailto:internet-drafts@ietf.org] Sent: Monday, October 24, 2011 5:20
> > PM To: George, Wes Cc: rjs@cw.net; 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.


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.