[bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df

[<[e-mail]>]

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/draf
t-ietf-bess-evpn-pref-df-05.txt>
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft
-ietf-bess-evpn-pref-df-05.txt

 

 

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.

 

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.

 

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 ?

 

 

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

 

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 ?
 
 
"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.
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.
 
Shouldn't the "no preemption" thing be valuable being agnostic to DF Alg ?
 
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.
 
 
References:
I think vES should be set as normative as people really need to understand
what vES is to understand the document.
 

 

Brgds,

 

Stephane