Re: [bess] About draft-brissette-bess-evpn-mh-pa-02

Hi,

I agree w/ both Jorge and Krzysztof.  All we need is a new DF Election capability, port active load balancing, and a description of how each of the defined DF elections is modified.  For HRW, RFC 8584 already describes computing a 32 bit CRC over the concatenation of Ethernet Tag and ESI so we would simply remove the Ethernet Tag from the CRC computation.

Yours Irrespectively,

John

Juniper Internal
From: BESS <bess-bounces@ietf.org> On Behalf Of Krzysztof Szarkowicz
Sent: Saturday, April 20, 2019 4:35 AM
To: draft-brissette-bess-evpn-mh-pa.authors@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] About draft-brissette-bess-evpn-mh-pa-02

Hi,

Would like to add as well one comment, regarding section 4, which says:

For Modulo calculation, byte 10 of the ESI is used.

This is too restrictive, since in essence it means, to achieve the desired diversity, operator would need to use ESI byte 10 for ESI differentiation. Given the fact, ES-Import RT community inherits from ESI only byte 1-7, many deployments differentiate ESI within these bytes only. So, byte 10 stays the same in many deployments (typically '00').

Therefore, modulo calculation should take into account entire ESI (bytes 2-10, omitting byte 1, which defines ESI type). Or, some sort of hash/CRC function should be calculated over ESI bytes 2-10, quasi compressing 9 bytes to 1 byte (= result of hash/CRC), and this 1 byte should be taken as input for modulo calculations.

Thanks,
Krzysztof

On 2018-Nov-05, at 10:44, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> wrote:

Hi all,

I think I already made similar comments when the first revision of the draft in the subject was presented, but since I see no changes in the last revision, please let me throw the comments to the list for discussion:

1) section 3
"Peering PEs MAY exchange only Ethernet-Segment route (Route Type-4)"
Note that the AD per-ES route is REQUIRED in RFC7432. Please don't make this solution non-backwards compatible. Besides, mass withdrawal is important in this solution.

2) section 4
The document only talks about the default Alg and HRW Alg, but other Algs such as Preference make a lot of sense here too.
Also, shouldn't you request a new capability in the DF Election EC capability registry? If so, IMO this could be done:
- the ES routes are advertised with existing DF Algs, e.g., default, HRW, Pref
- when the new capability "port-based" is signaled, the Alg should be modified to consider the port only and not the Ethernet Tags.
- the "port-based" capability should be compatible with the 'DP' capability (for non-revertive) and you should make sure that the AC-DF bit is zero so that an AC going down does not influence the DF Election.

3) I assume the ES associated to the port is defined as single-active mode. Also, as in RFC7432, the ESI-label based split-horizon procedures should be used to avoid transient echo'ed packets.

4) section 5 - Port-active over Integrated Routing-Bridging Interface
In this section you assume that the entire port belongs to a single BD, and there are no other ACs in the BD. Without this assumption you cannot drive the IRB state out of the ES state. Please let me know if I am missing something, otherwise please, make this explicit.

Thank you.
Jorge

_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess