Hi Saumya Pls see inline.
From: "Dikshit, Saumya" <[email protected]> Date: Tuesday, September 7, 2021 at 3:22 PM To: "Parag Jain (paragj)" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05 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. * 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 Paragj> CP would mean BGP/EVPN/RIB which ever CP component has the info included in the sub-TLVs. 1. 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. * In case the RIB specific parameters need validation, then on receive side processing of ping, should run it through the RIB and FIB both ? Paragj> yes. * 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”. 1. If a need be, to perform “reachability-check to a tenant vrf (EVI) on remote NVE”, for which no route has been published yet ? Paragj> only vrf-existence is not checked by lsp ping. Thanks Parag as I mentioned in #2 of below email * 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:[email protected]] Sent: Tuesday, September 7, 2021 11:56 PM To: Dikshit, Saumya <[email protected]>; [email protected]; [email protected] Cc: [email protected] 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" <[email protected]<mailto:[email protected]>> Date: Thursday, September 2, 2021 at 1:42 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Query/comments on draft-ietf-bess-evpn-lsp-ping-05 Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
