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

Reply via email to