Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

["Dikshit, Saumya" <[e-mail]>]

Hi Parag,

Thanks for the response. I have few bullets on the same.
Please help clarify and if there is a need to call them out explicitly.


1.       “Consistency checkers” feature-set does validates the CP-DP parity and can be leveraged via management interface to the box.

a.       Do you imply the consistency check between protocol RIB and the dataplane FIB, Or the consistency between Software FIB (slow path) and the LC-FIB

2.       Parameters such as RD, shall not make it to the DP and their presence is restricted to the NLRI (entries/tables) in the protocol RIB.

a.       In case the RIB specific parameters need validation, then on receive side processing of ping, should run it through the RIB and FIB both ?

b.      In case it’s just the dataplane validation (which I can gather from this draft), then RIB validation is not required and RD’s  can carry “don’t care”.

3.       If a need be, to perform “reachability-check to a tenant vrf (EVI) on remote NVE”, for which no route has been published yet ? as I mentioned in #2 of below email

a.       Is it possible to achieve that with lsp-ping check with existing sub-TLVs without “wild-card/don’t-care”

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:[e-mail]]
Sent: Tuesday, September 7, 2021 11:56 PM
To: Dikshit, Saumya <[e-mail]>om>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya

The remote PE router processing the lsp ping packet, does consistency checks between data plane and control plane. RD, ESI fields along with other fields defined in the sub-tlvs are used for that purpose. Wildcard/don’t care values for these fields will defeat the purpose of DP-CP consistency checks.

Thanks
Parag

From: "Dikshit, Saumya" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 2, 2021 at 1:42 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Thursday, September 2, 2021 at 1:42 PM

[sending the queries in a different email with changed subject line]

Hello Authors of draft-ietf-bess-evpn-lsp-ping draft,

I have following queries regarding this draft:

>>>> Do we intend-to-use/call-out-usage-of “wild-card/don’t-care” values for attributes carried in the sub-TLVs ?
For example, If the admin intends  to check the reachability to host (MAC_X/IP_X) published (in route-type-2)  by remote PE.
The remote PE learnt it locally over ESI_X against Vlan X (mapped to BD_XYZ).

Is it possible, that the “EVPN MAC sub-tlv”  can carry the “Route Distinguisher” and “Ethernet Segment Identifier” as don’t care.

>>>> Another caseto handle would be test the reachability to tenant-VRF VRF_X (with EVPN mapped EVI) configured on the remote PE, PE1.
VRF_X has no active IP/IPv6 interface configured and its sole usage is to obtain the leaked (via IVRL) routes from other VRFs (non-EVPN) and PE1 published this to other peers via EVPN control plane. Till the first prefix (learnt ) route is published (Route Type 5) by PE1 for the EVI (mapped to VRF_X), the tunnels will not be provisioned on other PEs.
In order to test the reachability to VRF_X (on PE1) from another PEs, let’s say, PE2 or a centralized-controller (which can emulate/supports MPLS),

It may need to carry all/subset-of attributes with “don’t-care/wild-card” in “EVPN IP Prefix Sub-TLV”.


Please let know your thoughts on above.

Thanks
Saumya.