Subject: [bess] Comments for evpn-etree draft

From: Lucy yong <[email-masked]>
Date: Fri, 18 Sep 2015 18:53:29 +0000

Hi Ali and co-authors,

MEF defined E-Tree service in MEF6.1 in which each end point in the service must have either root or leaf role (but not both); and forwarding rules among e-tree service endpoints are specified according the endpoint role.

In order to make E-tree service across multiple SP domains, MEF26.1 further specifies a Trunk end point role at NNI interface, requires that a UNI can only has either root or leaf role, specifies the forwarding rule amount root, leaf and trunk end point, and requires that a trunk endpoint egress MUST encode a tag on the frame to indicate if the frame was originated from root or leaf. The trunk end point can handle unicast and BUM frames.

Evpn-etree draft allows a site that may have both root and leaf role, which is not compliant with MEF E-tree service. Does it intend to provide another service among the sites that have one of root, leaf, or root/leaf roles?

Furthermore, it is not clear that, if a PE with an attached root/leaf site, how does PE know a MAC destination in the site associating to root or leaf? Is it learned from data plane or control plane?  When the PE sends a frame to the site, does it need to tell the site if the frame was originated from a root or leaf site? If yes, how it is done? In addition, it is odd that the draft requires the root/leaf site can not have BUM traffic. I am not clear what service it provides.

EVPN can use the control plane for PE to advertise a MAC at a site and associated site role, which can facilitate ingress PE to perform filtering based on the destination MAC on the frame from a site and egress PE to perform filtering based on source MAC on the frame (BUM) from remote PE, right?  Thus, E-VPN can easily support MEF defined E-Tree service.

Regards,
Lucy