Re: [bess] A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08

["Parag Jain (paragj)" <[e-mail]>]

Hi Sacha

We have addressed all your comments in the new version of the darft (draft-ietf-bess-evpn-lsp-ping-09).

Thanks
Parag

From: Ali Sajassi (sajassi) <[e-mail]>
Date: Wednesday, November 30, 2022 at 1:12 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail] <[e-mail]>, Alexander Ferdman <[e-mail]>, Dmitry Valdman <[e-mail]>, Ron Sdayoor <[e-mail]>, Nitsan Dolev <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: A question pertaining to validation of LSP Ping Echo requests in draft-ietf-bess-evpn-lsp-ping-08
Hi Sasha,

Please refer to my comments below:



AS>> EVPN-VPWS has multiple modes, and it may be better to cover it in a separate draft. I will talk to Parag about a write-up of a short draft about EVPN-VPWS and put a clarification statement that this draft is limited to EVPN and EVPN-IRB.
[[Sasha]] Can you please clarify what limiting the current draft to just EVPN and EVPN with IRB means.
Suppose that an egress PE that has advertised a per EVI EVPN Type 1 route with a certain NLRI (RD, ESI, Ethernet Tag ID, Label) for an interface of an EVPN-VPWS instance it contains receives an LP Ping Echo request with the EVPN Ethernet A-D Sub-TLV in the Target FEC TLV that matches RD, ESI and Ethernet Tag ID of this route and with the top label that matches the label in the advertised route. Which return code should t use in its reply?

AS> We need to look at all the modes in EVPN-VPWS, if we can cover it easily in the existing draft, we’ll cover it. If not, we’ll do it in another draft. Since for LSP ping, we are talking about MPLS service path only and not end-to-end forwarding path, my guess would be we should be able to cover it in the existing draft.


AS>> When an EVPN is configured for symmetric IRB mode, then ARP/ND is terminated locally and thus there is no need to verify it remotely (actually you cannot verify it remotely!). However, for asymmetric IRB, ARP/ND is processed remotely and thus should be verify it remotely. That’s why I have the text the way I have written it.

[[Sasha]] Suppose that two PEs are attached to an All-Active MH ES, and both are configured with a MAC-VRF attached to this MH ES and configured with a Symmetric EVPN IRB with anycast IP and MAC address. Suppose further that one (and it typically would be just one) of these PEs receives an P message with a certain IP→MAC pair in its sender part and advertises this pair in an EVPN Type 2 route with Labl1 and Label2. What prevents the other PE from sending an LSP Ping Echo request with the EVPN MACIP Sub-TLV in the Target FEC stack TLV and with the label it has received in the Label1 field of the advertised route to the PE that has advertised this route, and what, if anything, prevents it from responding with return code 3 to such a request?

AS> That’s perfectly fine and the egress PE responds with return code 3. This follows the clarification text that I had earlier: “When the remote PE receives MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN label points to a MAC-VRF, then it validates the MAC state and forwarding. If the remote PE is not configured in symmetric IRB mode, then it validates ARP/ND state as well.”

Cheers,
Ali