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

[Donald Eastlake <[e-mail]>]

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 <
[e-mail]> 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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


> Your timely feedback will be highly appreciated.
>
>
>
> Regards, and lots of thanks,
>
> Sasha
>