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) > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
