Re: [scale] Third (and final?) call to discuss scaling VPNs

Rob Shakir <> Tue, 07 January 2014 17:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E731F1AE055 for <>; Tue, 7 Jan 2014 09:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pWMoVTh5pN5I for <>; Tue, 7 Jan 2014 09:01:20 -0800 (PST)
Received: from ( [IPv6:2a03:9800:10:4c::cafe:b00c]) by (Postfix) with ESMTP id BBC171AE02E for <>; Tue, 7 Jan 2014 09:01:19 -0800 (PST)
Received: from [] (helo=[]) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1W0a1b-0004Pt-LH; Tue, 07 Jan 2014 17:01:07 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Rob Shakir <>
In-Reply-To: <016901cf0bc6$5a5da370$0f18ea50$>
Date: Tue, 7 Jan 2014 17:01:05 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <00d101cf0b95$aa505de0$fef119a0$> <> <> <016901cf0bc6$5a5da370$0f18ea50$>
To: " Farrel" <>
X-Mailer: Apple Mail (2.1827)
Cc:, "Shah, Himanshu" <>
Subject: Re: [scale] Third (and final?) call to discuss scaling VPNs
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MPLS VPN Scaling <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jan 2014 17:01:25 -0000


As someone who has worked for a few operators, I’ll raise my head above the parapet.

Wes George and I worked on a draft that characterises some of the problems that we have seen in various operational L3VPN deployments. It really speaks to the specific case of control-plane scaling issues on L3VPN PEs. I do not think that this draft intends to speculate on any new work that the IETF should necessarily commence - although there may be various solutions that could be proposed to helping handle some of the scaling behaviours that we discussed.

As such - I think any BoF that is going to be held on this topic really need to consider what causes scaling issues. For me, there are three different areas: 

 1. An individual operator’s policy on how it implements its networks, products, and the features and capabilities that it supports.
 2. Each equipment vendor’s implementation of these features, and their underlying software architecture.
 3. The features and procedures of the underlying protocols running on each device.

Essentially, even though all of these are going to impact the overall scaling of PEs in L3VPN environments, but it is my feeling that both 1. and 2. are somewhat more of a problem than 3. For instance, both 1 and 2 require understanding of how different devices, or features that could be deployed together interact with one another, and the particulars of how that may be handled in the implementation in question - which are clearly going to be discussions which fall outside of the IETF’s scope. IMHO, often the understanding that operators are trying to get to here is not even trying to drive the highest scale per device, but also about determining the level to which a particular deployment will scale given the various different variables (size of RIBs, frequency of RIB updates, type of services provisioned, OAM features deployed…).

My intention in working on the draft-gs-vpn-scaling doc was to try to highlight what some of the scaling pitfalls can be, and provide some motivation (based on experiences) for such multi-dimensional scaling to be something that is actually examined by equipment implementors (typically, the head-line numbers on the spec. sheet are very nice in isolation, but not very good together). On this note, I am looking to update the doc based on some discussions Wes and I had in Berlin — but I have unfortunately not managed to carve out the cycles to do so just yet.

On the lack of response — I would suggest that collecting operator opinions only through the IETF is likely to be something that yields datasets from relatively few parties inherently, perhaps it is worth posing the question to one or more of the operator group lists.

Kind regards,

On 7 Jan 2014, at 16:34, Adrian Farrel <>; wrote:

> Hi Himanshu,
> You may be right. The list shows "only" 75 subscribers, but I figure that the
> list was advertised well enough when created so that those who are concerned did
> sign up (you found it :-).
> I think as you and Ramki indicated, a number of us would be interested in
> hearing what operators would like to achieve as raw numbers in DC VPNs, but to
> date not only do we not have those numbers, we don't have an idea whether they
> would create any issues. Perhaps these are conversations that operators prefer
> to have with their vendors and the scaling issues are more related to
> implementations than to protocols.
> My conclusion (at the moment) is that the I-Ds that currently hint at scaling
> issues for VPNs are providing solutions for speculative problems, or (worse)
> trying to find justifications for protocol extensions without real cause.
> We'll keep stirring, but I am not holding my breath!
> Adrian
>> -----Original Message-----
>> From: Shah, Himanshu []
>> Sent: 07 January 2014 15:17
>> To:;
>> Subject: RE: [scale] Third (and final?) call to discuss scaling VPNs
>> Just thinking - it might be possible that not enough people have signed in to
> this
>> mailing list.
>> Would it be worth sending your email to other mailing lists such as - mpls,
> PWE3,
>> L2VPN and L3VPN,
>> before considering to turn the lights off?
>> Thanks,
>> Himanshu
>> -----Original Message-----
>> From: scale [] On Behalf Of Shah, Himanshu
>> Sent: Tuesday, January 07, 2014 10:14 AM
>> To:;
>> Subject: Re: [scale] Third (and final?) call to discuss scaling VPNs
>> Hi Adrian -
>> Silence is deafening, possibly holidays and diversion to next glittering (SDN)
>> object.. :-)
>> I am interested in scaling and performance requirements of VPNs in data
> centers
>> as well as carrier networks.
>> From vendors (mine) perspective, we need to understand what the realistic
>> expectations are.
>> Like you, I wish as well, that some of the operators participate in this
> discussion
>> so that f2f meeting in London could be more productive.
>> Thanks,
>> himanshu
>> -----Original Message-----
>> From: scale [] On Behalf Of Adrian Farrel
>> Sent: Tuesday, January 07, 2014 5:46 AM
>> To:
>> Subject: [scale] Third (and final?) call to discuss scaling VPNs
>> My previous two emails may have been lost in the vacations.
>> It is now a working week for most people, so let's have one more attempt to
> see
>> whether there is interest in this topic.
>> Thanks,
>> Adrian
>>> -----Original Message-----
>>> From: scale [] On Behalf Of Adrian Farrel
>>> Sent: 03 January 2014 22:21
>>> To:
>>> Subject: [scale] Scaling VPNs in the New Year
>>> Sending this again in the hope of catching some people at their desks
>>> at the start of January.
>>> Adrian
>>>> -----Original Message-----
>>>> From: scale [] On Behalf Of Adrian
>>>> Farrel
>>>> Sent: 25 December 2013 21:42
>>>> To:
>>>> Subject: [scale] Scaling VPNs at Christmas
>>>> Hello Scale Mailing List,
>>>> I'm a bit puzzled by the lack of activity on this list. If there is
>>>> genuine support for the idea of a BoF to discuss scaling VPNs
>>>> (issues, requirements, moving towards solutions) I would have expected to
>> see more traffic.
>>> Certainly,
>>>> if there is no more evidence of enthusiasm to discuss this then I
>>>> don't
>> think
>>> we
>>>> will go ahead with a face-to-face meeting (i.e. a BoF) at the London IETF.
>>>> I had expected to hear a chorus of complaints from operators about
>>>> how they struggle with their deployments today, and how they want to grow
>> them soon.
>>> I
>>>> thought I was going to hear from a number of operators about the VPN
>>>> requirements of data centers. And I had expected a number of vendors
>>>> to be wanting to talk about how they address these problems. My
>>>> expectation had been that we would talk about different scaling
>>>> challenges across the VPN space
>> and
>>>> learn what techniques could be common.
>>>> But it is OK!
>>>> If no-one has scaling concerns or if no-one wants to talk about them
>>>> right
>>> now,
>>>> we can move on.
>>>> Cheers,
>>>> Adrian
>>> _______________________________________________
>>> scale mailing list
>> _______________________________________________
>> scale mailing list
>> _______________________________________________
>> scale mailing list
> _______________________________________________
> scale mailing list