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
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
