Preference-based DF selection

[MotiMorg]

The 'preference' parameter, currently located in df-election container, is "the PE preference to become the DF in the ES". If that so, then the parameter must be specified per PE (actually, per PE per service) rather than as a single value on the whole ES level. So, I recommend on moving the parameter next to ethernet-segment-identifier (in the group list). The parameter should still be conditionally relevant, i.e, only when the group is an ES instance and only when the df-election-method of that ES is 'preference' (preference-based).

[boucadair]

Hi Moti,

Good catch. Please check the proposed PR to fix this. Thank you.

[MotiMorg]

Hi Med, There are two issues with the proposal:

1. The DF preference should be per PE, per service, and per ES too. Note that even if the service is evpn-based, it is still possible that the service in this PE doesn't employ any ES instance as a network-access. So, no need for DF-preference at all. On the opposite scenario, it is possible that multiple network-accesses in the service and PE are ES instances. Each ES in each service in that PE should have its own preference value.
2. The DF-preference is required only when the DF-election method is preference-based. It was part of the previous leaf definition.

So, that's why I proposed to have the parameter as part of the group

Now, I do not know how to correctly express that in the YANG. But, there are two restrictions to consider. First, the preference parameter is relevant only if the ethernet-segment-identifier is meaningful (i.e., only if the group is really an ES instance) and only if the df-election-method of the referred ethernet-segment-identifier is 'preference'.

[boucadair]

Hi Med, There are two issues with the proposal:

1. The DF preference should be per PE, per service, **and per ES too**. Note that even if the service is evpn-based, it is still possible that the service in this PE doesn't employ any ES instance as a network-access. So, no need for DF-preference at all. On the opposite scenario, it is possible that multiple network-accesses in the service and PE are ES instances. Each ES in each service in that PE should have its own preference value.

2. The DF-preference is required only when the DF-election method is preference-based. It was part of the previous leaf definition.

So, that's why I proposed to have the parameter as part of the group

Now, I do not know how to correctly express that in the YANG. But, there are two restrictions to consider. First, the preference parameter is relevant only if the ethernet-segment-identifier is meaningful (i.e., only if the group is really an ES instance) and only if the df-election-method of the referred ethernet-segment-identifier is 'preference'.

I considered that approach first, but given that we the preference is also announced in bgp and that we need to constraint it to EVPN type, I went for this proposal.

Also, I removed the "when" because we don't have access to DF-election. I considered adding a new leaf under the PE, but there is still a risk to have conflicting values in the ES and the VPN.

In the current proposal, we don't create redundant config. the df-prio will just be ignored if another election type was set at the ES level.

Let's think if there is a better way to express this. The proposal is for discussion. Thanks.

[MotiMorg]

If we don't have access to the DF-election-method of the ES instances then OK. I agree that we can specify a value for it and the device will ignore it when irrelevant. However, the value cannot be configured on VPN level because the parameter is instantiated per each ES object (i.e., per each customer site/edge-device) that is served by the the VPN. Maybe the VPN does have its own priority/preference as well, for some other preference-based mechanism. But, it is not to be confused with the ES-level parameter that serves the DF election mechanism, among member PEs of a particular ES.

[boucadair]

If we don't have access to the DF-election-method of the ES instances then OK.

Great, thanks.

I agree that we can specify a value for it and the device will ignore it when irrelevant. However, the value cannot be configured on VPN level because the parameter is instantiated per each ES object (i.e., per each customer site/edge-device) that is served by the the VPN. Maybe the VPN does have its own priority/preference as well, for some other preference-based mechanism. But, it is not to be confused with the ES-level parameter that serves the DF election mechanism, among member PEs of a particular ES.

The proposed PR suggests to put it under vpn-network-access. I'm not sure there is a confusion there. Do you see any? Thanks.

[MotiMorg]

I re-visited your proposed PR and understood my mistake. Yes, the proposal will solve the issue. Thanks.

[boucadair]

I re-visited your proposed PR and understood my mistake. Yes, the proposal will solve the issue. Thanks.

Thank you for double checking, Moti. Will merge the PR.