Hi Stephane, Thanks for the review and my apologies for the delay. We just posted a new revision.
As usual, very good points. Please see in-line. Thx Jorge From: "slitkows.i...@gmail.com" <slitkows.i...@gmail.com> Date: Wednesday, February 26, 2020 at 3:20 PM To: "draft-ietf-bess-evpn-pref...@ietf.org" <draft-ietf-bess-evpn-pref...@ietf.org>, 'BESS' <bess@ietf.org> Cc: "bess-cha...@ietf.org" <bess-cha...@ietf.org> Subject: Shepherd's Review of draft-ietf-bess-evpn-pref-df Resent-From: <alias-boun...@ietf.org> Resent-To: <jorge.raba...@nokia.com>, <senthil.sathap...@nokia.com>, <p...@juniper.net>, <w...@juniper.net>, <jdr...@juniper.net>, <saja...@cisco.com>, <satya...@cisco.com> Resent-Date: Wednesday, February 26, 2020 at 3:20 PM Hi Authors, Here is my review of the document: Please look at the nits and fix them. https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-pref-df-05.txt [Jorge] done. Section 3: - Is the DF preference field only there when DF Alg=2 ? I mean if DF Alg !=2, can the reserved field be encoded differently ? This should be clear IMO. [Jorge] ok, added: “If the DF Alg is different than Alg 2, these two octets can be encoded differently.” Section 4.1: “ Note that, by default, the Highest-Preference is chosen for each ES or vES, however the ES configuration can be changed to the Lowest-Preference algorithm as long as this option is consistent in all the PEs in the ES. I don’t think it is a good idea to open this modification. People can play with preference values to achieve the required behavior while always keeping high pref. We have no way to ensure consistency, except if we advertise the behavior as part of the exct. Consistency of DF election is key and needs to be ensured as much as we can. [Jorge] the idea is have the highest preference as default (maybe use normative language?), which means that it will work fine. Opening to lowest is to give more flexibility, knowing that if the user has to change the config from the default, they will do it in all the PEs of the ES. In case of equal Preference in two or more PEs in the ES, the tie-breakers will be the DP bit and the lowest IP PE, in that order. For instance: The sentence is not clear enough and must use normative language. Example: In case of equal Preference between two or more PEs in the ES, an implementation MUST first prefer PEs advertising the DP bit set and then prefer the PE with the lowest IP address. Which IP address are we talking about exactly here ? [Jorge] I change this text to: “In case of equal Preference in two or more PEs in the ES, the DP bit and the lowest IP of the candidate PEs are used as tie-breakers. After selecting the PEs with the highest Preference value, an implementation MUST first select the PE advertising the DP bit set, and then select the PE with the lowest IP address (if the DP bit selection does not yield a unique candidate). The PE's IP address is the address used in the candidate list and it is derived from the Originating Router's IP address of the ES route. Some examples of the use of the DP bit and IP address tie-breakers follow…” Section 4.3: Typo on: A new "Don't Preempt Me" capability is defined on a per-PE per-ES Basis Should be : “A new "Don't Preempt Me" capability is defined on a per-PE basis [Jorge] actually the DP capability is defined per ES on each PE. So I changed it to the following to make it clear: “A new "Don't Preempt Me" capability is defined on a per-PE/per-ES basis,” s/however this document do not enforces the/however this document does not enforce the/ Question: Why don’t you enforce consistency ? What is the side effect of not ensuring consistency ? [Jorge] The “SHOULD” term is because normally you would expect all the PEs in the ES to be consistent in the use of DP. But the procedures are really independently run by each PE and there is no negative side effect if only part of the PEs are configured as non-revertive. Former DF PEs configured without this capability will preempt the DF when they recover after a failure, but that is of course expected. In any case, I added: “In case of inconsistency in the support of the DP capability in the PEs of the same ES, non-revertive behavior is not guaranteed.” “When PE3's vES2 comes back up, PE3 will start a boot-timer (if booting up) or hold-timer (if the port or EVC recovers). That timer will allow some time for PE3 to receive the ES routes from PE1 and PE2. » Are you changing the way the DF election works ? Usually, PE advertises its route and then wait to receive other routes. [Jorge] those timers are on top of the FSM defined in RFC8584, e.g. we need to give some extra time before the ES goes up and we advertise the ES route, if the ES is configured with the DP capability. This is because the advertised preference and DP values may not be the same as the configured ones, and the ‘in-use’ values will depend on the other ES routes in the ES. If we advertise the ES route immediately after the ES is up, we may not have received the other ES routes and we don’t know what “in-use” values to advertise in order to avoid preemption in the ES. I added some text on point 5 (section 4.3). What happens if all PEs on the ES are failing at the same time or the ES booting up on all the PEs at the same time ? you have no way to hear what is the pref from the remote. [Jorge] The non-revertive capability makes sense when there is at least one PE alive in the ES and we don’t want to preempt it so that there is no traffic impact. If all the PEs fail, there is traffic impact anyway, so there is really no non-revertive behavior, but an initialization in all the PEs. Shouldn’t the “no preemption” thing be valuable being agnostic to DF Alg ? [Jorge] the non-preemption may not be possible with some Algs, so it has to be studied with each individual Alg. For instance, I can’t see how it can work with the default Alg in the way it is defined. On 6) Consider that we had: PE3 advertising <300,1> PE2 advertising <200,1> PE1 advertising <100,1> PE3 fails and come back, advertising [200,0], leading to PE2 being DF. PE2 fails, but in a similar time PE1 changes its pref to 250. This leads to PE1 being DF while in this case PE3 should be DF because it should have recovered its preference but it can’t. [Jorge] there may be race conditions, but whenever PE3 receives PE2 withdraw, it advertises (300,1). Even if both things happen at the same time, both will be computed by PE3. The main point is that upon a change in the ES, all the PEs calculate the highest and lowest PEs that are active in the ES. And if a PE becomes either one and its ‘in-use’ pref != ‘admin’ pref, then it will send an update with its admin values. References: I think vES should be set as normative as people really need to understand what vES is to understand the document. [Jorge] ok, I made a few changes in the references. Let me know if it is ok. Brgds, Stephane
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
