Subject: Re: Requirements for MEF E-Tree Support in VPLS

From: Raymond Key <[email-masked]>
Date: Wed, 15 Sep 2010 11:04:02 +1000

Hi Josh,

This is very good. Thanks for sharing your experience.

Our intention is to explore if some minor extensions to the 
current VPLS standard could bring us a simple solution to 
this small problem. 

We wish to hear from more people about their experiences.

Regards,
Raymond Key

> Rogers, Josh <[email-masked]> wrote:
> 
> We leverage VPLS to provide ETREE (including multi-root) service, and 
> have encountered some of the challenges mentioned in.   If you are 
> looking for some 'in the wild' examples of solutions to the problems 
> mentioned in the draft, let me know.
> 
> My examples will be using BGP-VPLS on JUNOS platform, and may not scale 
> well when involving other vendors (I've never tried!)
> 
> 
> Josh Rogers
> 
> 
> 
> On Sep 13, 2010, at 5:24 AM, Raymond Key wrote:
> 
> > Hi all
> > 
> > I have updated the captioned Internet draft
> > http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-01
> > 
> > A few more people from operators have joined as co-authors.
> > 
> > This is a simple short document, one page Problem Statement 
> > (section 4), one page Requirements (section 5).
> > 
> > Grateful if you could review and let us know what you think.
> > 
> > Best regards,
> > Raymond Key

---

From: "Rogers, Josh" <[email-masked]>
Date: Wed, 15 Sep 2010 23:33:10 -0400

The primary motivator to leveraging VPLS to deliver ETREE is because service (vlan) multiplexing breaks transparency.  We use VPLS-BGP on an entirely JUNOS network (we have some interop with other vendors, but do not use VPLS across to those networks)

The method used is to create a VPLS instance, and use a single import route target for all leaves, and a single RT for all roots.

A JUNOS example for Root PE:

top set routing-instance LOC1 protocols vpls interface-mac-limit no-tunnel-services site LOC1 automatic-site-id
top set routing-instance LOC1 protocols vpls vpls-id 123
top set routing-instance LOC1 vrf-target import target:123:1
top set routing-instance LOC1 vrf-target export target:123:2

And Leaf PE:

top set routing-instance LOC2 protocols vpls  site LOC2 automatic-site-id
top set routing-instance LOC2 protocols vpls vpls-id 123
top set routing-instance LOC2 vrf-target import target:123:1
top set routing-instance LOC2 vrf-target export target:123:2

Basically, leaf sites only import target 123:1 (which is only exported by roots).  there are also a couple knobs in JUNOS that address scenarios where you have a two leafs on a single PE (no-local-switching), and also a leaf and root on the same PE (core-facing)

The one case I haven't figured out yet, is how to get the root sites talking to one another (since they both only import the leaf exported targets).  So far it hasn't been an issue for us, because our ETREE customers with disaster recovery sites, also order a dedicated ELINE between them, and leverage that circuit for communication between root sites.

I'm really pleased to see some work done in this area, as it isn't well documented, and as result I see a lot of networks coming up with solutions that break transparency, or create a great deal of complexity to accomplish the same goal.

-Josh

>>> Grateful if you could review and let us know what you think.

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.