Hi Sasha, My apologies for the slow reply. Thanks for your questions.
See below at <de>. On Sun, Mar 31, 2024 at 11:30 AM Alexander Vainshtein < alexander.vainsht...@rbbn.com> wrote: > 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: > 1. Initiate establishment of these sessions > 2. 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, exit of an established session from its UP state? > <de> I would say that EVPN restoration mechanisms (redundancy and recovery/convergence) are the most logical clients for BFD sessions. > > 2. 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. > 1. 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? > 2. 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? > > 3. 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)? > 4. 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? > <de> This document specifies BFD operating at the level of intra-PE tunnels, that is, part of the Network layer. So, I think the answer to 2a above is No. <de> On 2b, it would generally be a matter of local policy/configuration whether an attempt was made to start a BFD session. Such a session might be started when a label switched path is created. Or when the first data actually flows. Or whatever. And, on 2c, it is similarly a matter of local policy/configuration. The draft currently specifies a fake MAC address that can be used to advertise a discriminator if there is no learned MAC address available for this purpose but perhaps it should permit a discriminator to be advertised with an A-D Route. <de> On 2d, currently the draft indicates that PE-2 would advertise its discriminator by using an RT-2 for a fixed "fake" MAC address, TBD3, to be assigned. But, on reflection, PE-2 advertising this discriminator with an RT-1 may be a better technique. > > 3. 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? > > <de> I think the answer to this would commonly be Yes but, again, it is a matter of local policy/configuration. See 2b/2c above. The ingress PE, as I understand it, replicates packets based on IMET advertisements received. So, if this is to be monitored, an ingress PS if configured to use p2mp BFD is the head of a p2mp BFD session where each egress PE is a leaf. > > 3. Can the authors please clarify why the UDP port that is allocated > for 1-hop IP BFD (RFC 5881) is reused for EVPN BFD? > > <de> The BFD packets are encapsulated and sent through a tunnel so it seems to me that it should appear to BFD to be 1-hop. <de> Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > Your timely feedback will be highly appreciated. > > > > Regards, and lots of thanks, > > Sasha >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
