Re: [bess] Comments for evpn-etree draft

[Lucy yong <[e-mail]>]

Hi Jorge,

Please see inline below.

From: Rabadan, Jorge (Jorge) [mailto:[e-mail]]
Sent: Friday, September 18, 2015 7:52 PM
To: Lucy yong; [e-mail]; [e-mail]
Subject: Re: [bess] Comments for evpn-etree draft

Hi Lucy,

EVPN-ETREE allows a MEF compliant implementation, I think there is no doubt about it.
[Lucy] OK, let’s make that clear.
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.
[Lucy] Does this mean EVPN-ETREE offers a new service for such application? If yes, please specify that service first. Then specify how EVPN-ETREE is used to implement such service.

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.
[Lucy] Whatever assumption you made here, it needs be reasonable and has a clear use case. From service perspective, a root/leaf site is a customer site, and the service is provided to a set of customer sites. If customer used the management plane to configure MAC and its root/leaf association, how customer conveys this relationship to the network? there is no such description in the draft. In addition, does the network also need to inform a root/leaf site about a MAC and MAC’s root/leaf association at a remote site? If yes, how? For MEF E-tree service, PE does not need to inform MAC’s root/leaf association to a customer site because the root and leaf role is defined at AC .  Therefore, if you define a new service here, please specify that service first.
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.
[Lucy] Yes, I understand control plane advantage to advertise MAC and its associated role. But we need to describe the service clearly if it does not intent for the MEF E-Tree service.

IMO: the control plane can implement MEF E-Tree service across multiple domains, such as ASes. If each PE site advertises MAC and MAC associated root/leaf role, each ingress PE can filter based on an MAC lookup; egress PE may also filter based on an MAC lookup (i.e. source MAC). An ABR or ASBR just need to distribute the ESI or MAC A-D to make it work across multiple domains.

Even in option A [RFC4364], we have to make clear that each PE site treats the other site as of a CE site, but PE itself is not a CE site; and BGP is used in the option A. Therefore, the root/leaf site in this draft is not clear what it is.

Thanks,
Lucy

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