Subject: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 08 Jan 2019 09:51:58 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-evpn-df-election-framework-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It's not really clear to me that the question of Updating 7432 has been
settled by the responses to the directorate reviews; I've noted a few
places in the text that are problematic in this regard, in the COMMENT
section.

I'm a little worried that we're setting future extensions up for a
combinatoric explosion of required analysis, by requiring new capabilities
and DF algorithms to determine their applicability/compatibility with all
previously defined mechanisms of the other type.  But maybe there's some
easy math to show that it won't be too bad.  Let's have a discussion about
this topic, even if we don't end up needing to make any changes to the
document as a result.  (I do note that this explosion would not really
happen if we combined the two into a single enumerated codepoint space that
combines DF algorithm with the enablement state of all then-defined feature
flags.)

Wection 3.3

   Section 7.6 of [RFC7432] describes how the value of the ES-Import
   Route Target for ESI types 1, 2, and 3 can be auto-derived by using
   the high-order six bytes of the nine byte ESI value. The same auto-
   derivation procedure can be extended to ESI types 0, 4, and 5 as long
   as it is ensured that the auto-derived values for ES-Import RT among
   different ES types don't overlap.

How do I ensure that the auto-derived values don't overlap?

Section 4.2

                     The ESI value MAY be set to all 0's in the Weight
   function below if the operator so chooses.

I'm not 100% sure I'm interpreting this correctly, but this sounds like a
piece of device-specific configuration (i.e., configured by the operator)
that must be the same across all devices for correct operation, but is not
covered by the advertisement of the DF Election Exctended Community.  This
would decrease the robustness of the system to basically the "experimental"
level of DF election algorithm 31, which also relies on universal agreement
of manual configuration.  Is this actually something we want to include?

Section 5

   The AC-DF capability MAY be used with any "DF Alg" algorithm. It MUST

As written, this suggests that it is true for any current or future
algorithm, which is in conflict with the text in Section 3.2 that notes
that "for any new DF Alg defined in future, its applicability/compatibility
to the existing capabilities must be assessed on a case by case basis."  It
seems more prudent to make the assessment after the relevant technologies
are both extant, so I would suggest this be non-normative text, perhaps
"the AC-DF capability is expected to be of general applicability with any
future 'DF Alg' algorithm".

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2.1

I a little bit wonder if the risk of poor distribution of DFs with the
default algorithm is being oversold -- any "hash identifiers into buckets"
scheme will be susceptible to pessimal input, but if the inputs are not
attacker-controlled and the pessimal inputs are unlikely to occur randomly,
we may not need to care.

   2- Even in the case when the Ethernet Tag distribution is uniform the
      instance of a PE being up or down results in re-computation ((v
      mod N-1) or (v mod N+1) as is the case); the resulting modulus
      value need not be uniformly distributed because it can be subject
      to the primality of N-1 or N+1 as may be the case.

This is making some assumptions about the (potential) distribution of the
tag values that could be made more clear, as otherwise the primality is
not particularly relevant (particularly for an actual uniform distribution
that covers all possible values).  Similarly below, by the CLRS reference
(CLRS probably has the ability to assume that we're running on binary
computers and may even be doing things like operating on pointers, which
tend to have fixed structure in the low-order bits due to alignment
considerations, etc.  For these (human-allocated?) integer identifiers it's
less clear what assumptions should come into play.)

Section 1.3

   Section 2.2 describes some of the issues that exist in the Default DF

There is no section 2.2; presumably this is supposed to be 1.2.

   o HRW and AC-DF mechanisms are independent of each other. Therefore,
     a PE MAY support either HRW or AC-DF independently or MAY support
     both of them together. A PE MAY also support AC-DF capability along
     with the Default DF election algorithm per [RFC7432].

This seems a little confusing since just a couple paragraphs ago you are
distinguishing between "election algorithms" and "capabilities", but here
the two new things (one of each type) are lumped together as "mechanisms".
If election algorithms and capabilities are inherently independent things,
then maybe there is not a need to reiterate the independence of HRW and
AC-DF here.

Section 3

   This section describes the BGP extensions required to support the new
   DF Election procedures. In addition, since the EVPN specification
   [RFC7432] does leave several questions open as to the precise final
   state machine behavior of the DF election, section 3.1 describes
   precisely the intended behavior.

This text sounds like we should be Update:ing 7432.

Section 3.2

     - Otherwise if even a single advertisement for the type-4 route is
       not received with the locally configured DF Alg and capability,

nit: shouldn't this be "received without"?

Section 3.2.1

   [RFC7432] implementations (i.e., those that predate this
   specification) will not advertise the DF Election Extended Community.

This wording also suggests that we should be Update:ing 7432.

Section 4
I note that the state of the art in non-cryptographic fast hashing has
improved a lot since 1998 and we have things like the Jenkins hash that are
supposed to be superior to CRC-32 and such.

                                   [HRW1999] provides pseudo-random
   functions based on the Unix utilities rand and srand and easily
   constructed XOR functions that perform considerably well. This
   imparts very good properties in the load balancing context. Also each
   server independently and unambiguously arrives at the primary server
   selection. [...]

It's not really clear to me that this text adds much value -- we go on
later to say that we explicitly use a Wrand() function from HRW1999.

Section 4.2

   1.  DF(v) = Si: Weight(v, Es, Si) >= Weight(v, Es, Sj), for all j. In
       case of a tie, choose the PE whose IP address is numerically the
       least. Note 0 <= i,j < Number of PEs in the redundancy group.

I strongly suggest expanding out the notation with more words, e.g. "DF(v)
is defined to be the address Si such that [...]".  We probably shouldn't
assume much abstract math background from RFC readership.  (Similarly for
BDF(v).  The BDF(v) expression doesn't even say what the i, j, and k are
evaluated over.)

   HRW solves the disadvantages pointed out in Section 2.2.1 and
   ensures:

Again, this is now Section 1.2.1

   o More importantly it avoids the needless disruption case of Section
     2.2.1 (3), that is inherent in the existing Default DF Election.

and here.
(Also, this bullet point is just describing the same situation as the
previous one, if I understand correctly.)

Section 5

   modify the DF Election procedures by removing from consideration any
   candidate PE in the ES that cannot forward traffic on the AC that
   belongs to the BD. [...]

What guarantees that the ACS information is available on all PEs involved
in the election?

   In particular, when used with the Default DF Alg, the AC-DF
   capability modifies the Step 3 in the DF Election procedure described
   in [RFC7432] Section 8.5, as follows:

Only a single paragraph follows, but the referenced document has three
paragraphs in the indicated step.  Are the last two paragraphs no longer
intended to apply?  In particular, if we apply this paragraph as a direct
replacement for the RFC 7432 step 3, then there is no longer a normative
description of the modulus-based algorithm, which seems incorrect.  Also,
there's a lot of style/editorial changes, that make the difference in
behavior harder to read from the diff.  (Side note: I don't think this
particular text implies that this document needs an Updates: relation to
RFC 7432, since it is a behavior change conditional on the use of a
negotiated feature.)

   a) When PE1 and PE2 discover ES12, they advertise an ES route for
      ES12 with the associated ES-import extended community and the DF
      Election Extended Community indicating AC-DF=1; they start a timer
      at the same time. [...]

(nit?) This text implies some synchronization between PE1 and PE2 for
starting the timer, whereas I think the intent is just to note that they
each start a timer as they advertise the route, independently of each other.

   In addition to the events defined in the FSM in Section 3.1, the
   following events SHALL modify the candidate PE list and trigger the
   DF re-election in a PE for a given <ES,VLAN> or <ES,VLAN Bundle>. In
   the FSM of Figure 3, the events below MUST trigger a transition from
   DF_DONE to DF_CALC:

Then why are they not listed as part of the referenced FSM (or at least
mentioned with a forward-reference)?

Section 7

Are there any considerations to discuss about increased resource
consumption (e.g., for storing and transmiting Ethernet A-Ds per-<ES,VLAN>
vs. per-<ES,VLAN Bundle>) and the risk of DoS due to reaching resource
caps?

                Note that the network will not benefit of the new
   procedures if the configuration of one of the PEs in the ES is
   changed to the Default [RFC7432] DF Election.

Isn't this the case if there is not unanimity among all PEs in the ES about
what election algorithm is preferred, which is a broader possible case than
one being changed to use the default algorithms?

Section 8

   o Allocate Sub-Type value 0x06 in the "EVPN Extended Community Sub-
     Types" registry defined in [RFC7153] as follows:

Sometimes we see language about "confirm the existing early allocation",
but I assume that the RFC Editor and IANA have a standard way of sorting
this stuff out.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 17 Jan 2019 22:10:16 +0000

Benjamin,

Thank you very much for your review.
Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon.
Thanks.
Jorge

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Tuesday, January 8, 2019 at 6:52 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, January 8, 2019 at 6:51 PM

    

   [JORGE] We finally agreed on making it updating 7432 and explain why in the intro/abstract. Thanks.

        [concerns about combinatoric explosion were overblown; removed]
           
        Section 3.3

   
[JORGE] The autoderivation in RFC7432 for ESI types 1, 2 and 3 can be used "only if it produces ESIs that satisfy the uniqueness requirement specified above." RFC7432 does not specify how the overlap is avoided, it is out of scope, but one may think the operator must manually check that the values auto-deriving the 9-octet ESI value don't match. We added the following text, let us know if it is okay:
"As in [RFC7432], the mechanism to guarantee that the auto-derived ESI or ES-import RT values for different ESIs do not match is out of scope of this document."
       
        Section 4.2

   
[Satya] This is to accommodate the case in https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00.
Specifically, if the same set of PES are multi-homed to the same set of ESes, setting the ES to 0, would result in the "same unique" PE be the DF for a given EVI for all those ESes.
Use can be made of this property in the optimization in https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00.
Yes, it would need manual configuration to enable this.
       
        Section 5

   
[JORGE] Good point. We added "The AC-DF capability is expected to be of general applicability with any future DF Algorithm."

       
        Section 1.2.1

       
   
[Satya] As I replied to Adam:
 
The Ethernet tag that identifies the BD can be as large as 2^24; however, it is not guaranteed that the tenant BD on the ES will conform to a uniform distribution. In fact, it up to the customer what BDs they will configure on the ES. Quoting Knuth [Art of Computer Programming Pg. 516]
  " In general, we want to avoid values of M that divide r^k+a or r^k−a, where k
      and a are small numbers and r is the radix of the alphabetic character set
      (usually r=64, 256 or 100), since a remainder modulo such a value of M tends
      to be largely a simple superposition of key digits. Such considerations
      suggest that we choose M to be a prime number such that r^k!=a(modulo)M or
      r^k!=−a(modulo)M for small k & a."
In our case, N is the number of PEs in RFC 7432 which corresponds to M above.
Since N, N-1 or N+1 need not satisfy the primality properties of the M above; as per RFC 7432 modulo based DF assignment, whenever a PE goes down or a new PE boots up (hosting the same Ethernet Segment), the modulo scheme need not necessarily map BDs to PEs uniformly.
       
        Section 1.3

[JORGE] changed, thx.

[JORGE] they are indeed independent, but since in the future may be some capabilities that only make sense for certain DF Algs, we believe it is better to explicitly state here that the DF Alg and capability defined are compatible. Let us know if it is not okay.
       
        Section 3

        This text sounds like we should be Update:ing 7432.
[JORGE] yes, we finally converged into this too. Rev 08 will update 7432. Thanks.
       
        Section 3.2

[JORGE] fixed, thanks.
       
        Section 3.2.1

 [JORGE] done. Thx.
       
        Section 4

[Satya] Agreed. We can take it out for brevity. We can edit this a bit as I don’t see it harming anything.
       
        Section 4.2

        I strongly suggest expanding out the notation with more words, e.g. "DF(v)
        is defined to be the address Si such that [...]".  We probably shouldn't
        assume much abstract math background from RFC readership.  (Similarly for
        BDF(v).  The BDF(v) expression doesn't even say what the i, j, and k are
        evaluated over.)
Denote the PEs addresses as S0, S1, .. SN-1.
[Satya] DF(v): is defined to be the address Si (index i) for which weight(v, Es, Si) is the highest, 0 <= i < N-1
Similarly, BDF(v) is defined as that PE with address Sk for which the computed weight is the next highest after the weight of the DF.
j is the running index from 0 to N-1, i, k are selected values.

[JORGE] fixed, thanks.

        and here.
 [JORGE] fixed, thanks.
       
        Section 5

        What guarantees that the ACS information is available on all PEs involved
        in the election?
[JORGE] the ACS information is available on all PEs since it is distributed by the A-D routes as explained later. The withdrawal of an A-D per-EVI route indicates the AC state goes down. But since this is the behavior in RFC7432, we don't think there is a need to explain that.

[JORGE] we changed the text to the following. Hopefully it makes it clear:
    ----------------------
   
       3. When the timer expires, each PE builds an ordered "candidate" list
          of the IP addresses of all the PE nodes attached to the Ethernet
          Segment (including itself), in increasing numeric value. The
          candidate list is based on the Originator Router's IP addresses of
          the ES routes, but excludes any PE from whom no Ethernet A-D per
          ES route has been received, or from whom the route has been
          withdrawn. Afterwards, the DF Election algorithm is applied on a
          per <ES, Ethernet Tag>, however, the IP address for a PE will not
          be considered candidate for a given <ES, Ethernet Tag> until the
          corresponding Ethernet A-D per EVI route has been received from
          that PE. In other words, the ACS on the ES for a given PE must be
          UP so that the PE is considered as candidate for a given BD. If
          the Default DF Alg is used, every PE in the resulting candidate
          list is then given an ordinal indicating its position in the
          ordered list, starting with 0 as the ordinal for the PE with the
          numerically lowest IP address. The ordinals are used to determine
          which PE node will be the DF for a given Ethernet Tag on the
          Ethernet Segment, using the following rule:
   
          Assuming a redundancy group of N PE nodes, for VLAN-based service,
          the PE with ordinal i is the DF for an <ES, Ethernet Tag V> when
          (V mod N)= i. In the case of VLAN-(aware) bundle service, then the
          numerically lowest VLAN value in that bundle on that ES MUST be
          used in the modulo function as Ethernet Tag.
   
          It should be noted that using the "Originating Router's IP
          address" field in the Ethernet Segment route to get the PE IP
          address needed for the ordered list allows for a CE to be
          multihomed across different ASes if such a need ever arises.
   
    <snip>
    ----------------------

        (nit?) This text implies some synchronization between PE1 and PE2 for
        starting the timer, whereas I think the intent is just to note that they
        each start a timer as they advertise the route, independently of each other.
[JORGE] good catch. Changed to:
    "a) When PE1 and PE2 discover ES12, they advertise an ES route for ES12 with the associated ES-import extended community and the DF Election Extended Community indicating AC-DF=1; they start a DF Wait timer (independently). Likewise, PE2 and PE3 advertise an ES route for ES23 with AC-DF=1 and start a DF Wait timer."

        Then why are they not listed as part of the referenced FSM (or at least
        mentioned with a forward-reference)?
[JORGE] we added the following at the end of section 3.1:
    "The above events and transitions are defined for the Default DF Election Algorithm. As described in Section 5, the use of the AC-DF capability introduces additional events and transitions."
       
        Section 7
       
        Are there any considerations to discuss about increased resource
        consumption (e.g., for storing and transmiting Ethernet A-Ds per-<ES,VLAN>
        vs. per-<ES,VLAN Bundle>) and the risk of DoS due to reaching resource
        caps?
[JORGE] we don't think there are additional security considerations since there are no additional Ethernet A-D routes suggested by the procedures in this document. The procedures suggest to change the DF Election and make it per VLAN as opposed to per VLAN bundle, but the amount of routes needed does not change.

       
        Isn't this the case if there is not unanimity among all PEs in the ES about
        what election algorithm is preferred, which is a broader possible case than
        one being changed to use the default algorithms?
[JORGE] ok, changed to:
    "Note that the network will not benefit of the new procedures if the DF Election Alg is not consistently configured on all the PEs in the ES (if there is no unanimity among all the PEs, the DF Election Alg falls back to the Default [RFC7432] DF Election)."
       
        Section 8

        Sometimes we see language about "confirm the existing early allocation",
        but I assume that the RFC Editor and IANA have a standard way of sorting
        this stuff out.
[JORGE] ok, we'll wait for RFC Editor / IANA edits.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 18 Jan 2019 15:12:54 +0000

FYI

We just posted revision 08 which addresses all the comments given during the review (thank you all for that). From the authors perspective, the document is ready to go. 

Thanks.
Jorge

-----Original Message-----
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thursday, January 17, 2019 at 11:10 PM
To: Benjamin Kaduk <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)

    Benjamin,

    -----Original Message-----
    From: Benjamin Kaduk <[email-masked]>
    Date: Tuesday, January 8, 2019 at 6:52 PM
    To: The IESG <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)
    Resent-From: <[email-masked]>
    Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
    Resent-Date: Tuesday, January 8, 2019 at 6:51 PM

        

               
            Section 3.3

       
           
            Section 4.2

       
           
            Section 5

       

           
            Section 1.2.1

           

           
            Section 1.3

           

            Section 3

           
            Section 3.2

           
            Section 3.2.1

           
            Section 4

    
           
            Section 4.2

           

           
            and here.
           
            Section 5

           

       

        <snip>
        ----------------------

           
           
            Section 7

            

            Section 8

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jan 2019 10:01:30 -0600

> Satya and I have looked at your points one by one, please see in-line. Let us know if you are ok now. We'll publish revision 08 soon.

I see that the -08 has landed since I started composing this message --
thanks!  Some more comments inline.

>     https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/

That suffices to resolve the Discuss point.
Having said that, though, Martin did some research and had some good points
on the telechat, that type 0 has 9 octets of fully arbitrary value, whereas
types 4 and 5 use as a base the router ID and also have a local
discriminator.  (IIRC, types 1, 2, and 3 were generally going to be unique
as inherent properties of how they are determined, e.g., via the global
uniqueness of MAC addresses.)  I would suggest (but not insist upon)
mentioning something about the operator being able to use the discriminator
and type-0 arbitrary values to ensure the needed non-overlap.

> Yes, it would need manual configuration to enable this.

I think I did not properly convey the point I was concerned about, here.
What I'm concerned about is that if there are separate knobs for using HRW
as the DF alg, and for setting the ESI input to zero, then we have a new
failure mode in the case when all routers agree to use HRW but disagree
about whether to set ESI to zero.  In particular, it seems like that could
cause two routers to both think they are the active DF, which is IIUC
really bad, especially so since it defeats the mechanism introduced by this
document to ensure that all PEs agree what algorithm is being used (with
fallback to the default algorithm).  It would seem much safer to just have
two DF algorithms -- one for HRW-including-ESI and another for
HRW-with-ESI-set-to-zero (or HRW-without-ESI, really), and allow
deployments to have the full protection of the election algorithm being
defined here.

As an additional asid, I'm not 100% sure I see the applicability of the
zero-ESI case ot the draft-mohanty-bess-evpn-bum-opt case -- from reading
the document itself I was wondering if the zero-ESI input was needed so
that (using that document's Figure 1) PE5 would be able to tell which of
PE1/2/3 wer the DF for the ES attaching CE1.  But my reading of your text
above is that the goal would be to try to get all BUM traffic to that one
"same unique" PE that is DF for *all* ESes, letting the other PEs avoid
getting any BUM traffic.  In any case, this is just a side note, since I
don't think it matters for the discussion in my previous paragraph here.

> [JORGE] Good point. We added "The AC-DF capability is expected to be of general applicability with any future DF Algorithm."

Adam had a better description of how to improve this text, and I do agree
that the new text is much more clear -- thank you both to Adam and the
authors for working on this!

> [JORGE] they are indeed independent, but since in the future may be some capabilities that only make sense for certain DF Algs, we believe it is better to explicitly state here that the DF Alg and…

It is fine to leave as-is.

> [Satya] DF(v): is defined to be the address Si (index i) for which weight(v, Es, Si) is the highest, 0 <= i < N-1

The new text is a big help, here.  I still expect readers to be confused by
the usage (in the retained enumerated list) of "DF(v) = Si:" that uses ":"
as a shorthand for "such that" -- in my mathematics course, we used the
vertical bar as such a shorthand, but it still remains something of a
specialist notation that I don't expect to be familiar to the general
reader base.

> [JORGE] the ACS information is available on all PEs since it is distributed by the A-D routes as explained later. The withdrawal of an A-D per-EVI route indicates the AC state goes down. But since…

Ah, that makes sense.  Thank you for explaining it to me, with my inexpert
7432 knowledge.

> [JORGE] we changed the text to the following. Hopefully it makes it clear:

That is a big help, thanks.  I might consider starting a new paragraph for
"If the Default DF Alg is used[...]", but that's a very minor point.

>     <snip>

Sounds good.

> [JORGE] we don't think there are additional security considerations since there are no additional Ethernet A-D routes suggested by the procedures in this document. The procedures suggest to change…

Okay, thanks for thinking about it.

-Benjamin

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Sat, 19 Jan 2019 00:38:02 +0000

Hi Benjamin,

Thanks for your comments. My replies inline [Satya]

On 1/18/19, 8:01 AM, "Benjamin Kaduk" <[email-masked]> wrote:

    defined here.

[Satya] Agreed that you have a point. We can indeed have two algorithms, one for HRW-including-ESI and another for HRW-without-ESI.

I can incorporate that in https://tools.ietf.org/html/draft-mohanty-bess-evpn-bum-opt-00 when we refresh it before this IETF (we are delayed on that).

Will that suffice to address your concern?

[Satya] Your understanding is on the correct lines. That is the intention of the zero-ESI.

In that case, the DF will be same for all the ES.

But in that draft, since we also advertise the IMET from the BDF and other PEs that may be singly-homed,  PE5 will not necessarily know who is the DF.

[Satya] Thank you for emphasizing on this and bringing it to our attention.

    reader base.

[Satya] ok 😊 I can change with “|”.

    7432 knowledge.

    Sounds good.

    -Benjamin

Thanks,

--Satya

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jan 2019 19:13:45 -0600

> Will that suffice to address your concern?

So the idea would be to remove the discussion from this document about
setting ESI to zero, and have draft-mohanty-bess-evpn-bum-opt allocate a
new DF Algorithm codepoint?  That would be what I see as the optimal
solution.

> [Satya] ok 😊 I can change with “|”.

Okay, thanks.

-Benjamin

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 24 Jan 2019 10:46:41 +0000

Hi Benjamin,

Satya and I made the changes agreed on this thread and we published version 09.
Version 09 is good to go from our perspective.

Benjamin, Martin, please let us know if the draft can progress now.

Thank you.
Jorge

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Saturday, January 19, 2019 at 2:13 AM
To: "Satya Mohanty (satyamoh)" <[email-masked]>
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)

    
    
    Okay, thanks.
    
    -Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Jan 2019 10:34:51 -0600

Hi Jorge,

Version 09 addresses my discuss points, so I have cleared in the
datatracker.

I do think that it would be better to use "MUST" in "when using the HRW
Algorithm for EVPN DF Election, the ESI value in the Weight function SHOULD
be set to that of the corresponding ES", and that there could be more
discussion about how to provide the non-overlapping property of derived
ES-Import RT values, but those are not grounds to block the document from
advancing.

Thank you for the updates!

-Benjamin

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 25 Jan 2019 09:48:33 +0000

Hi Benjamin,

Thank you very much.
Sure, we'll discuss that, however for the time being we prefer to progress the document as is. We can still make some little changes when at the RFC editor.

Thanks again for your thorough review and very useful comments.
Jorge

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Thursday, January 24, 2019 at 9:06 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Cc: "Satya Mohanty (satyamoh)" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Litkowski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-df-election-framework-07: (with DISCUSS and COMMENT)

    Hi Jorge,

    
    
    -Benjamin