Uncategorized

EVPL vs E-TREE

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
	no-local-switching;
	vrf-import CUST-Acme_IMPORT;
	vrf-export CUST-Acme_EXPORT;
	protocols {
		vpls {
			vpls-id 1234;
		}
	}
}

All, very fun stuff and very flexible.

Advertisements