RE: BGP PW inter-provider scalability for VPLS

[email protected] Tue, 17 Jun 2003 12:12:00 +0100
Newsgroups gmane.ietf.ppvpn
Message-ID <B5E87B043D4C514389141E2661D255EC08B5CF@i2km41-ukdy.domain1.systemhost.net>
Having thought about this properly, option A or B from RFC2547 could be used
instead of option C to reduce the number of PWs required. I guess the only
question that remains is what's more important (i) reducing the number of
inter-AS PWs at the expense of placing a heavier workload on the gateway
devices, or (ii) using RRs with EBGP sessions between them to reduce the
workload on ASBRs at the expense of increasing the number of inter-AS
PWs?...

Richard

 > -----Original Message-----
 > From: [email protected] [mailto:[email protected]]
 > Sent: 17 June 2003 09:01
 > To: [email protected]
 > Subject: BGP PW inter-provider scalability for VPLS
 > 
 > 
 > I have a couple of questions regarding the scalability of 
 > the VPLS BGP
 > signalling draft. It seems to me there are two VPLS scaling 
 > issues regarding
 > signalling in the inter-provider case:
 > 
 > i)  Number of BGP/LDP sessions
 > ii) Number of PWs
 > 
 > The BGP signalling draft addresses the first issue as 
 > service providers can
 > use route reflectors with EBGP sessions between them (option C from
 > rfc2547), however it does not address the second issue. For 
 > example, lets
 > say we have an intra-provider network (SP1) with 800 
 > customers, each of
 > which have an average of 10 fully meshed VPN sites, the number of
 > intra-provider PWs required would be:
 > 
 > = m(n*(n-1)/2) - where m is the number of VPLS instances and 
 > n is the number
 > of PEs
 > = 800(10(10-1)/2)
 > = 36,000 PWs
 > 
 > Now lets say SP1 wanted to connect  to another provider 
 > (SP2) to create an
 > inter-provider service, and that 200 customers want to 
 > connect their 10
 > sites in SP1s network 10 sites in SP2s network in a full 
 > mesh giving a total
 > of 20 sites. The number of PWs required would be:
 > 
 > = m(n*(n-1)/2)
 > = 200(20(20-1)/2)
 > = 38,000 PWs
 > 
 > Of these 38,000 PWs, some are SP1s intra-provider PWs, and 
 > some are SP2s
 > intra-provider PWs. SP1s intra-provider PWs can be calculated using:
 > 
 > = m(n*(n-1)/2)
 > = 200(10(10-1)/2)
 > = 9,000 PWs
 > 
 > The calculation for SP2s intra-provider PWs gives the same 
 > number (9,000),
 > which means the total number of inter-provider VPNs required 
 > between SP1 and
 > SP2 is: 38,000 - 9,000 - 9,000 = 20,000.
 > 
 > So, in the inter-provider case, SP1 must now provision and manage its
 > original 36,000 intra-provider VPNs, plus 20,000 
 > inter-provider PWs. This is
 > just over a 55% increase in the number of PWs to provision 
 > and manage, even
 > though only 25% of SP1s customers have inter-provider VPNs.
 > 
 > The LDP VPLS signalling draft addresses this issue by defining a
 > hierarchical model in which two fully meshed VPLS networks 
 > are connected
 > together using a single LSP tunnel between the VPLS gateway 
 > devices. In the
 > above example, only 200 PWs would be required between the 
 > two gateway PEs,
 > as opposed to the 20,000 fully meshed PW in the BGP case. The LDP
 > hierarchical model also addresses issue i) regarding the 
 > number of sessions
 > required as only one LDP session is required between gateway sites.
 > 
 > Although the hierarchical model may not be without its own 
 > problems (e.g.
 > the issue of gateway PEs having to perform MAC address learning when
 > connecting to multiple ASs has been brought up) it does 
 > address the problem
 > regarding the number of PWs required. 
 > 
 > Questions:
 > ==========
 > 
 > I would be grateful if anyone can help with the following:
 > 
 > 1. Are there plans to address the number of PWs scaling 
 > issue in the BGP
 > VPLS draft? (Or perhaps this is addresses in a separate 
 > draft and I've
 > missed it?)
 > 2. I would also be interested to know what people think the 
 > biggest problem
 > in the above example would be: a) MAC address learning at 
 > the gateway PE for
 > 200 PWs, or provisioning and managing an extra 1,800 PWs.
 > 
 > Thanks,
 > 
 > Richard
 > 
 > 
 > 
 > 
 >