[bess] Questions about draft-ietf-bess-evpn-bfd

[Alexander Vainshtein <[e-mail]>]

Hi,
I am reading the latest available version of the draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bfd-06>,  and I have several questions to the authors.


  1.  RFC 5882 suggest that BFD sessions in general are coupled with their clients which:
     *   Initiate establishment of these sessions
     *   React to state transitions of these sessions in some way
The well-known clients can be routing protocols, redundancy mechanisms etc.
Can the authors please clarify which entities are expected to act as the clients of the EVPN BFD sessions, and which actions can these clients take upon, say, exist of an established session from its UP state?

  1.  Section 4 "Fault Detection for Unicast Traffic" suggests advertisement of "My" discriminator values in the BGP Discriminator attribute in MAC/IP Advertisement (EVPN Type 2, a.k.a. RT-2) routes.
     *   Can the authors please clarify whether a different My discriminator value is expected to be assigned for each MAC address that have been locally learned by the given PE?
     *   Suppose that:

                                                              i.      PE-1 and PE-2 participate in the same EVI and the same BD in this EVI

                                                             ii.      PE-1 has locally learned MAC-1, assigned My Discriminaror D1 to it and advertised D1 in the corresponding RT-2

                                                           iii.      PE-2 has locally learned MAC-2, assigned My Discriminaror D2 to it and advertised D2 in the corresponding RT-2
Does the draft imply that a BFD session between PE-1 and PE-2 using D1 and D2 as the cross-matching pairs of <My Discriminator, You Discriminator) should be established? If not, how is the decision to establish - or not to establish - such a BFD session is taken?

     *   In the assumptions of (b) above, what should happen if PE-1 withdraws RT-2 it has advertised for MAC-1 (e.g., because this MAC address has been aged out, or because it has moved to another PE)?
     *   Suppose that:

                                                              i.      PE-1, PE-2 and PE-3 participate in the same EVI and the same BD in this EVI

                                                             ii.      PE-1 and PE-2 are attached to the same multi-homed Ethernet segment in All-Active load-balancing mode

                                                           iii.      A certain MAC address, MAC-1 has been locally learned by PE-1, but not by PE-2

                                                           iv.      PE-3 sends traffic with Destination MAC address MAC-1 to both PE-1 based on RT-2 advertised for this MAC address and to PE-2 based on the per-EVI Ethernet A-D (EVPN Type 1, a.k.a. RT-1) route
Does the draft imply that PE-3 can verify its connectivity for MAC-1 to PE-1 but not to PE-2?
Does the draft imply that PE-2, upon receiving RT-2 for MAC-1 from PE-1 allocates a "local" discriminator" for this MAC address? If yes, how is this discriminator advertised?

  1.  Can the authors please clarify whether each PE where a certain EVI/BD is instantiated, is expected to establish BFD session with all the PEs from which it has received an IMET Route? If not, how is the decision to establish - or not to establish - such a BFD session is taken?
  2.  Can the authors please clarify why the UDP port that is allocated for 1-hop IP BFD (RFC 5881) is reused for EVPN BFD?

Your timely feedback will be highly appreciated.

Regards, and lots of thanks,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.