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 ? >>>> 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. >>>> 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. >>>> >>>> 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. >>>> 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. >>>> "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. >>>> 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. Regards, Saumya.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess