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

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

Hi Weiguo,

From: Haoweiguo <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 29, 2014 at 12:18 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,

Pls see my reply inline with [weiguo].

Thanks

weiguo

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

Hi Weiguo,

Thank you for your comments.
Your proposal for the per-evi mode (advertising evi-to-AR in BGP)
[weiguo]: Yes, my proposal is for per-evi mode. EVI-to-AR is advertised 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.).

[weiguo]: I think the multicast state(the flood-list corresponding to each EVI) number on each REPLICATOR node in my proposal is less than your solution. In my proposal, if REPLICATOR1 and REPLICATOR2 are responsible for BUM traffic forwarding of EVI 1-100 and EVI 101-200 respectively, REPLICATOR1 doesn't need maintain flood-lists for EVI 101-200 and  REPLICATOR2 doesn't need maintain flood-lists for EVI 1-100. In your solution, all REPLICATORs need maintain flood-lists for all EVIs in EVPN network, this will cause scalability issue on each REPLICATORs.

[JORGE] Our solution supports both modes, per-evi and per-flow load-balancing. I am not saying we should not support the per-evi flow balancing. Rather the opposite, it will make sense in many cases. Also if you have two ar-replicators for all the EVIs:
- if both have local ACs, both require the regular flooding list for each evi with ACs, as per EVPN.
- if they don’t have local ACs, you can decide what EVIs they are ar-replicator for. For the rest they won’t maintain flooding lists.
- you normally have more than one ar-replicator per evi, for redundancy reasons. In this case, for a given evi you want the backup ar-replicator to have its flooding list ready in case of failure of the primary one.
And in any case, we will optimize this further in future revisions as I said.


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.

[weiguo]: I think leaf choosing is suitable for small scale EVPN networks, it will not cause scalability issue when each REPLICATORs maintain flood-lists for all EVIs in EVPN network. Your solution also can achieve EVI based load balancing among multiple REPLICATORs.

[JORGE] The leaf choosing its ar-replicator locally is much more scalable than having to wait for the selection coming from somewhere else and deal with failures and inconsistencies. Again, the draft supports both load balancing modes. We’ll try to make it clearer.



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