Re: [bess] Comments for evpn-etree draft

["Rabadan, Jorge (Jorge)" <[e-mail]>]

Hi Lucy,

EVPN-ETREE allows a MEF compliant implementation, I think there is no doubt about it.
The normal use-case would be a leaf/root site per PE or per AC. But simply because it is possible in EVPN, I believe it is good to leave the door open to new applications, and the leaf/root site per MAC is an example.

I don’t think the draft has to specify how a MAC is designated as root or leaf. Although I would say the easiest way would be through the management plane, that is implementation specific. The important thing is that once the MAC is decided to be leaf or root, it is advertised as such by the egress PE, and filtering can now be done at the ingress PE based on an MAC lookup.

Another similar example in RFC7432 is the use of the sticky MACs. It is nowhere specified how MACs are classified as sticky, however it is being proven to be a very useful tool.

My two cents…
Thanks.
Jorge

From: BESS on behalf of Lucy yong
Date: Friday, September 18, 2015 at 11:53 AM
To: "[e-mail]<mailto:[e-mail]>", "[e-mail]<mailto:[e-mail]>"
Subject: [bess] Comments for evpn-etree draft

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