Just finished watching a MEF webcast on ethernet backhaul for mobile wireless.

While this is interesting, MEF (as always) doesn’t give you any technical details about how it can be done.  Its refreshing to see that what I’ve been working on is 100% in line with MEF’s vague standards.  😉

On another note, I noticed that they are starting to more predominantly use the term ETREE instead of EVPL.  They should pick one and stick to it.  Also, the diagram for EVPL/ETREE uses a ‘Ethernet LAN’ symbol with dotted lines showing the ‘ROOT’ and ‘LEAF’ relationships.  Seems to me they expect EVPL to be a LAN with some mechanism to prevent LEAVES from seeing one another.

This deviates from what I’ve seen most folks do.  The problem I’ve seen with the EVPL/ETREE service, is most folks approach the problem by stacking multiple EVC’s on the same trunk handoff to a customer.  This breaks transparency and requires tag coordination w/the customer, and breaks L2protocol tunneling, and just causes general headaches for everyone involved.

I thought of an illustration of how to accomplish this at L2 that would help the engineers with more L2 experience.

Its essentially the same notion as Private VLAN’s (the community port is the root, and pvlan ports are leaves)

Roots and Leaves
Roots and Leaves

So, the idea is if the root sends a unknown unicast frame, the switch will tag it with 20 (incoming/outgoing in the diagram is from the switch port’s perspective).  20 can be accepted at the other root, and each of the leafs, so this frame will be flooded at all ports.

If a leaf sends an unknown unicast frame, the switch will tag it with 10.  The switch is configured to send VLAN 10 ONLY to the root ports, so this frame will be flooded at the two ROOT ports, and NOT the leaf ports.

The same principle applies to how we do this using VPLS on the Junipers.  The difference is we’re using the VRF-target to control what traffic is being sent to.  Using the same ID’s for the diagram above, for VPLS with a single root we’d do:

routing-instances Acme {
   // Root
   export target:11427:10;
   // Leaf
   import target:11427:20;

With multiple roots, it gets a little more complex if you want roots to speak to one another:

policy-options {
	//first we define a policy that will bgp tag traffic leaving the root
	policy-statement CUST-Acme_EXPORT {
		term 1 {
			from protocol bgp;
			then {
				community add CUST-Acme_Roots;
		term 2 {
			then reject;
		then accept;
	//next a policy that matches traffic from the other root and leaves (for a leaf site, we'd remove the 'Leafs' community here)
	policy-statement CUST-Acme_IMPORT {
		term 1 {
			from {
				protocol bgp;
				community [ CUST-Acme_Leafs CUST-Acme_Roots ];
	community CUST_Acme_Roots members 123:10;
	community CUST_Acme_Leafs members 123:20;
routing - instances Acme {
	instance-type vpls;
	interface ge-0/0/0.200
	vrf-import CUST-Acme_IMPORT;
	vrf-export CUST-Acme_EXPORT;
	protocols {
		vpls {
			vpls-id 1234;

All, very fun stuff and very flexible.


3 thoughts on “EVPL vs E-TREE”

    1. do you have any more info on evpl/e-tree… i found this the most beneficial information i could find. I’m debating on how to connect a large layer2 network among multiple carriers. I guess not large but the client would like evlan of course. Well, I don’t want to do that between multiple carriers. I figured your e-tree may work however and didn’t really figure out how to configure it through other sites on the net. only negative is you chew up multiple vlans, but make sense from dual root standpoint too.

      1. Really sorry I haven’t replied until now (never noticed the comment), there are several ways to accomplish ETREE, and it depends largely on your network and what underlying transport you use. For example, if you have a largely IP/MPLS network, you can use VPLS. If you use BGP signalled VPLS, you can use two different VRF-Targets (and import and an export) and inverse them for the leaf sites compared to the root sites). If you have a largely layer 2 network, you can accomplish this using PVLAN, or using two different VLANs (one for receiving and one for sending, and inverse them between root and leaf sites).

        regarding ‘other’ info, this RFC may provide some thoughts to consider: http://www.rfc-editor.org/authors/rfc7152.txt

        If you provide a little info about your network, I may be able to provide some pointers, but the short answer is “it depends.” I’ll try to keep an eye out and respond much quicker this time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s