Saumya, Please see in-line. Thanks. Jorge
From: BESS <bess-boun...@ietf.org> on behalf of Dikshit, Saumya <saumya.diks...@hpe.com> Date: Thursday, July 14, 2022 at 10:43 AM To: draft-ietf-bess-evpn-pref-df....@ietf.org <draft-ietf-bess-evpn-pref-df....@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org> Subject: Re: [bess] Few queries on draft-ietf-bess-evpn-pref-df Hello Authors, Chairs, Can you clarify below comments ? Regards, Saumya. From: Dikshit, Saumya Sent: Tuesday, July 12, 2022 4:28 PM To: draft-ietf-bess-evpn-pref-df....@ietf.org Cc: bess@ietf.org Subject: Few queries on draft-ietf-bess-evpn-pref-df Hello Authors of draft-ietf-bess-evpn-pref-df, I have few queries. Kindly help me on those. >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-09#section-3 Bit 0 (corresponds to Bit 24 of the DF Election Extended Community and it is defined by this document): D bit or 'Don't Preempt' bit (DP hereafter), determines if the PE advertising the ES route requests the remote PEs in the ES not to preempt it as DF. [Saumya] the granularity of these bits, should impact DF-election granularity on a per <ES, BD> or <ES, EVI> ? Please correct my understanding or this is applicable to all BDs/EVIs on the ES ? [jorge] all the fields in the DF election extended community affect the ES for which the ES route is advertised. >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-09#section-3 The allowed values are within the range 0-65535, and the default value MUST be 32767. [Saumya] Any thought on this value being inherited from the “Originator Router’s IP”, thus relieving from one more default value. More so, if there is no choice of particular preference, it may workout well without any explicit configuration to non-default values. [jorge] if you don’t configure an explicit preference value in any PE of the ES, the default will be the same on all of them. Then the DF election will use the tie breakers defined in the document, which might be the DP and IP address (advertised in the originating-ip). So you get the same overall result. >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-09#section-4.1 the DP bit and the lowest IP of the candidate PEs are used as tie- breakers. [Saumya] Can we deal with a case, where the tie-breaker also needs some customization (for example, highest IP address instead of lowest IP), by signaling the intent. [jorge] then you may well change the preference.. not sure what the issue is. >>>> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-09#section-4.3 this local policy MUST be consistent in all the PEs of the ES. [Saumya] The so called local policies (as also mentioned in https://datatracker.ietf.org/doc/html/rfc8584), are not local as they are being called out to be consistent on all PEs of the ES. To be consistent, why not signal them via a TLV “as an exception” and let it be absorbed/processes by the PEs configured for to absorb this exception and not call them as local-policies. [jorge] this is typically vendor specific and local, resulting in the update of the preference value. Similar to policies being used for other protocols, e.g. vrrp. >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-09#section-4.4 This timer is applied between the INIT and the DF_WAIT states <Saumya> How about a scenario where in two or more PEs are rebooted (lets say a complete POD or fabric). In such a case, any ES routes coming in after beyond DF_WAIT, will be handled distinctly, as all of them should be applying the same logic and few of them might be configured with same Preference as the ones which were not having any segment outage. [jorge] you can make the timers long enough if you wanted. Also the non-revertive behavior is really for non-planned uncontrolled operations as described in the document. >>>> “The user may force a PE to preempt the existing DF for a given Ethernet Tag without re-configuring all the PEs in the ES.” [Saumya]In the above statement, why is the DF tied to “Ethernet Tag”, instead of a mapped Bridge/Broadcast domain (or corresponding VID). Tag is just a wrapper for normalization. [jorge] we follow RFC8584 terminology >>>> as long as the representation of the broadcast domains is configured consistently across the multi-homed PEs attached to that ES. [Saumya]I understand the statement is under Ethernet-tag, but the consistency should be across the Segments for all PEs hosting the mapped EVI. [jorge] again, we follow the RFC8584 terminology, in particular for Ethernet Tag. Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
