Re: 答复: Two comments about draft-rabadan-l2vpn-evpn-optimized-ir-00

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

Hi Weiguo,

Thank you for your comments.
Your proposal for the per-evi mode (advertising evi-to-AR in BGP) IMHO might be good in a topology with very centralized ar-replicators, however I personally don’t see a big benefit in more distributed ar-replicator topologies and it does complicate things in the control plane (e.g. what to do if the ar-replicator receives a traffic from a non-expected leaf for an <evi, eth-tag>, what if the ranges in the ar-replicators are not in synch, failure scenarios, etc.). We see more benefit in the leaf choosing its ar-replicator based on proximity, capabilities, or multicast volume. I still think the current draft allows a uniform per-evi load-balancing.

Thank you.
Jorge

From: Haoweiguo <[e-mail]<mailto:[e-mail]>>
Date: Sunday, July 27, 2014 at 8:15 PM
To: Jorge Rabadan <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 答复: Two comments about draft-rabadan-l2vpn-evpn-optimized-ir-00


Hi Jorge,

In per-VN mode, in your draft, loadbalancing is decided locally on each Leaf Node. In my opinion, loadbalancing should be decided by REPLICATOR based on unified algorithm among all REPLICATORs, then each REPLICATOR notifies all leaf node the VNs whose BUM traffic can be locally processed.Because each REPLICATOR has global network wide  <VN,Leaf Node> association information, so  it can achieve better loadbalancing than Leaf node local decision method.  For example if there are two REPLICATORs and 100 VN in NVO3 network, REPLICATOR1 can be responsible for VNI 1-50 multicast traffic forwarding, REPLICATOR2 is responsible for VNI 51-100. When a leaf receives multicast traffic from local connecting TS, if the TS belongs to VNI 1-50, the traffic will be sent to REPLICATOR1;If the TS belongs to VNI 51-100, the traffic will be sent to REPLICATOR2.

For multicast group loadbalancing, the method is similar, loadbalancing(i.e., multicast groups and corresponding REPLICATOR mapping information) is decided by each REPLICATOR, then each REPLICATOR notifies each Leaf node the multicast groups that are processed.

Thanks

weiguo

________________________________
发件人: Rabadan, Jorge (Jorge) [[e-mail]<mailto:[e-mail]>]
发送时间: 2014年7月26日 4:19
收件人: Haoweiguo
抄送: [e-mail]<mailto:[e-mail]>
主题: Re: Two comments about draft-rabadan-l2vpn-evpn-optimized-ir-00

Hi Weiguo,

Thank you for your comments.
Please see in-line.

From: Haoweiguo <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 24, 2014 at 11:25 AM
To: Jorge Rabadan <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Two comments about draft-rabadan-l2vpn-evpn-optimized-ir-00


Hi Jorge,

I have two comments:
1. More than one REPLICATOR scenario:
In a service where there is more than one or more REPLICATORs,
In per-flow loadbalancing mode:
Relies on LEAF’s local traffic HASH algorithm, a packet can be sent to any one of the REPLICATOR and replicated to destinations.Multicast traffic can be fully dispersed among all REPLICATORs.

OK. This is implementation-specific and compatible with the current draft.

In per-VNI mode:
To ensure traffic loadbalancing among multiple REPLICATORs,each REPLICATOR should announce VNI List or multicast group range to all leafs, the VN List or multicast group on each REPLICATOR is configured by operators in beforehand. For example if there are two REPLICATORs and 100 VN in NVO3 network, REPLICATOR1 can be responsible for VNI 1-50 multicast traffic forwarding, REPLICATOR2 is responsible for VNI 51-100. When a leaf receives multicast traffic from local connecting TS, if the TS belongs to VNI 1-50, the traffic will be sent to REPLICATOR1;If the TS belongs to VNI 51-100, the traffic will be sent to REPLICATOR2.
EVPN protocol should be extended to support VNI List or multicast group range advertisement.

The per-VNI mode is already possible with the current revision of the draft. The LEAF can already build a list of AR-REPLICATORs for each <evi, eth-tag> and decide how to balance. As for the multicast groups, if you refer to IP multicast streams, this is possible in the per-flow balancing mode.



2. Hierarchical REPLICATOR-LEAF:
Hierarchical REPLICATOR-LEAF should be supported, i.e, a device can be REPLICATOR and LEAF at the same time, for lower LAYER network, its REPLICATOR;For upper layer network, its LEAF.

We are already working in a revision that will take care of that.

Thanks

weiguo