[j-nsp] VPLS scalability question.. OTV answer?

[Chris Evans]

An Enhanced FPC is required, this is what was throwing me off. I guess I
don't know what is enhanced and what isn't, its not very clear.

I'm testing on m7i/m10i's using the non eCFEB, but I guess they are still
new enough as it seems to work without it..  As this seems to work is the
VPLS bandwidth capability now fully port-speed? Meaning I'm not limited to
any tunnel services PIC limitations?

On Sun, Mar 27, 2011 at 8:46 PM, Julien Goodwin
<jgoodwin at studio442.com.au>wrote:

> The short answer is:
>
> http://www.juniper.net/techpubs/software/junos/junos92/swconfig-vpns/configuring-vpls-without-a-tunnel-services-pic.html
>
> This is meant to just need recent-ish pic's facing the MPLS cloud.
>
> On 28/03/11 09:53, Chris Evans wrote:
> > All the communication that we've received from Juniper is that they
> perceive
> > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching
> VPLS
> > on the Juniper platforms and I cannot find any definite information as to
> > how much it can scale performance/bandwidth wise. VPLS requires either a
> VT
> > interface or a LSI interface on that hardware. The VT interfaces can only
> be
> > obtained by hardware that can do tunnel services, and the LSI interface
> is
> > only on the MX platforms from what I can read.
> >
> > As tunnel PICs have limited performance and LSI interfaces 'steal'
> physical
> > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE
> blades)
> > how does Juniper expect to be able to provide high bandwidth VPLS while
> > still providing high port density? The TRIO cards have some inline
> services,
> > but does they offer these services? It seems like Juniper is expecting to
> > throw another half baked solution out there to compete with Cisco and I'm
> > not sure how they're going to scale the infrastructure. The Cisco
> solution
> > uses the built in ASIC hardware to do this and do not require ports to be
> > stolen, etc.. It really bothers me that you have to lose interfaces
> and/or
> > install special hardware to do inline services, which only increases the
> > cost of the platforms drastically.
>
>