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

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

Weiguo,

Thank you for your comments.
I understand what you are saying, however I am still not convinced that we need this at this point.
This is not “my solution” :-) but a work-in-progress document led by a few of us. We want this to be useful, and as simple as possible so we’ll discuss more among the authors and see.

Thanks.
Jorge

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

Yes, your solution supports both modes, per-evi and per-flow loadbalancing, i have no doubt about this point. My proposal is to enhance your per-evi solution.

In your solution, if there are 4 REPLICATORs in EVPN network, each REPLICATOR needs maintains flooding-lists for all EVIs, the number of multicast forwarding table is very large. In my solution, each REPLICATOR only needs maintain flooding-lists for partial EVIs. For example, if there are 10K EVI in EVPN network, in your solution each REPLICATOR needs maintain 10K flooding-lists. In my solution, each REPLICATOR only needs maintain 2.5K flooding-lists.

Why my solution can achieve such result? Because in my solution, all REPLICATORs need collaborate to assign EVI, the BUM traffic in one EVI only needs one REPLICATORs to process. <REPLICATOR, EVI> association should be advertised to whole EVPN network to let all leaf nodes know it.

If one REPLICATOR fails, the EVIs which were originally processed on the REPLICATOR should be adjusted to the remained REPLICATORs.

The above is the basic idea for the enhancement and is common mechanism, if you agree with this, i can write a section for you.

Thanks

weiguo

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

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