Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Satya,

Wrt BW utilization in the core, in EVPN we have always tried to be cognizant of it and thus handling it in the best way possible. That’s why we got:

  1.  ARP suppression – to suppress flooding ARP message over core
  2.  Capability to turn off flooding in the core altogether
  3.  IGMP suppression – to suppress flooding of IGMP messages via IGMP proxy
  4.  Avoid unnecessary transmission of multicast streams – send mcast flow to the PEs that only have receivers

The best solution for your use case is (option-A):

  1.  Enable DF election on per mcast flow – gives the best load-balancing for DF election among multicast flows and avoids FAT VLAN issue
  2.  Enable IGMP proxy and SMET route – avoid unnecessary transmission of mcast flows over core

The 2nd best solution for your use case is (option-B):

  1.  Enable DF election per VLAN and turn off ESI getting factored-in the HRW hash
  2.  Enable IGMP proxy and SMET route – avoid unnecessary transmission of mcast flows over core

The 3rd solution for your ucase case is (option-C):

  1.  Enable DF election per VLAN and turn off ESI getting factored-in the HRW hash
  2.  Stop sending IMET route for non-DF BD

I guess you can guess which one I am in favor of ☺

Cheers,
Ali


From: "Satya Mohanty (satyamoh)" <[e-mail]>
Date: Wednesday, March 21, 2018 at 11:35 PM
To: Cisco Employee <[e-mail]>, Sandy Breeze <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Ali,

Your suggestion of the default/non-default mode will really help here.
Let me explain with reference to #2 that you posted in the email-chain (and I quote below) because I think that captures the reasoning well.

"Even for multi-homing with >2 PEs in the redundancy group, the chances of a PE not becoming a DF across all ES's in a BD is extremely low. We need to keep in mind that number of ES's are much larger than number of PEs !! And HRW algorithm in our df-framework draft takes into account the ES-id in its hash algorithm which means for the same BD, different PEs can become DF for different ES's !!”

The above is very true for the general case. No doubt about it.
However there may be a case to not spread the DF in special toplogies and for specific reasons.

Consider the topology below.

ES1 - - - - - - - - - PE1
                |
ES2 - - - - - - - - - PE2
                |
ES3  - - - - - - - - - PE3

Here all the PEs host all the ESes.
That is, ES1, ES2 and ES3 are connected to all of the PEs, PE1, PE2 and PE3, and all of them have the exact same set of vlans configured; by setting the ESid to zero in the HRW hash function, the carving of the vlan is the same for each of the ES; it would be independent of the ESID, similar to the base modulo (ESID oblivious) algorithm.

  1.  When we combine the above with the proposed IMET suppression approach, then we will save bandwidth utilization in the core, because the same PE would be the DF for an EVI (vlan) regardless of the ESI’s (no spraying of DF for the same vlan). Only this PE would then attract the BUM.
  2.  As you know, HRW does a ranking of the PE per-vlan. When the DF goes down, the new DF for a vlan, is still a unique one, regardless of the ES. This may help in the user having “some control” of the DF. This is in fact a matter of independent interest of the current discussion. It will perform similarly as the base-modulo DF election as far as carving is concerned and still have the benefits of the HRW when a PE goes down or comes into the reckoning, in the sense, that it  will minimize on the number of (vlan, DF) re-mappings.

At least, that was my thinking when we had internal discussions with Sandy regarding IMET suppression.
So, as you can see, the main goal in (1) is to restrict the BUM flodding rather than the uniform distribution of the PE access side utilization as the point #2 that you mentioned in your email.

I will let Sandy comment  if he can have two ES in his BD on the EVPN GW. Now he has one.
Then this will be more useful  for his case.
Once he is here, we can discuss with him.

Thanks,
—Satya


From: "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 22, 2018 at 5:05 AM
To: satyamoh <[e-mail]<mailto:[e-mail]>>, Sandy Breeze <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Satya,

As I mentioned earlier in another thread among the co-authors, we need to have a default mode of operation and for the default mode, the ESI MUST be factored-in the hash function (e.g.;, (vlan, ESI, PE’s IP address). Also, as discussed earlier we can capture in the draft the “option” for not factoring-in the ESI  (ESI=0 in the hash algorithm) – i.e., PEs in a redundancy group MAY all be configured to set ESI=0 in the hash algorithm.

BTW, do you have certain scenarios/use-cases in mind for setting ESI=0?

Cheers,
Ali

From: "Satya Mohanty (satyamoh)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 21, 2018 at 3:16 PM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, Sandy Breeze <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

We will take the feedback and revise the next version with the EVPN GW case as the primary use case.
Also, we will make it informational.

I need to make a mention again of what I spoke at the mic because I think it may not have been clear to everyone.
In the DF election framework draft, the weight is now a function of  the tuple(vlan, Esid, PE’s IP).
If we set the Esid to 0, then as long as each ES has the exact same set if vlans, the carving of vlans by the algorithm is the same.

Thanks,
—Satya

From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 21, 2018 at 6:27 PM
To: Sandy Breeze <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Sandy,

The key point in here is that the proposal is intended for EVPN GWs (and not PEs). By talking about PEs and NVEs at BESS yesterday, lot of people got confused. Although for EVPN GWs, this proposal makes better sense, for EVPN PEs, it doesn’t much because:

  1.  Vast majority (if not all) of TORs/PEs multi-homing are dual-homing which gives us zero benefit
  2.  Even for multi-homing with >2 PEs in the redundancy group, the chances of a PE not becoming a DF across all ES's in a BD is extremely low. We need to keep in mind that number of ES's are much larger than number of PEs !! And HRW algorithm in our df-framework draft takes into account the ES-id in its hash algorithm which means for the same BD, different PEs can become DF for different ES's !!
3) As soon as there is a stub node (e.g., a single-home CE) connected to any PE, then all bets are off and that PE needs to send IMET route and receive mcast traffic
4) As soon as there is a link/ES failure, then we will end-up with (3) above for dual-homing scenario and the PE with active link needs to send IMET route and receive mcast traffic
5) For mcast flow (*,G) or (S,G), the solution described in igmp-proxy draft  is the most optimal

So, I would suggest to do the following:

  1.  In the problem statement of the draft, capture the below use case clearly.
  2.  Change the name of the draft to “bum optimization for EVPN gateways”
  3.  Capture briefly why the proposal is not intended for EVPN PEs/NVEs because of the above reasons.

Cheers,
Ali

From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Sandy Breeze <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 21, 2018 at 8:58 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

After some discussion, we acknowledge the problem description needs further clarification for this not to become too specific a use case.  Consider the following example of our existing live deployments;

[cid:image001.png@01D3C12D.50A50F00]


The main points to articulate here are;

  *   PE[1..4] are at the boundary of an EVPN/MPLS domain (core side) and an EVPN/VXLAN domain (datacentre fabric side)
  *   They are responsible for L2VNI VTEP from ToR and MPLS L2VPN in core.
  *   From their point of view, 1 BD = 1 L2VNI (=1 ES).
  *   For any given DF type (modulo/HRW/etc) they distribute DF’s per-ES between them.
  *   Therefore, all nDF PE’s attract BUM for ES’s they’re not allowed to forward on and hence the waste of bandwidth in the EVPN core and cycles.

In our case, the solution we propose works very well.  We also showed this does no harm for the more typical EVPN-multihoming at the PE use case yesterday, which held up to technical scrutiny.

Sandy