Hi Saumya
Pls see inline.
From: "Dikshit, Saumya" <saumya.diks...@hpe.com>
Date: Tuesday, September 7, 2021 at 3:22 PM
To: "Parag Jain (paragj)" <par...@cisco.com>,
"draft-ietf-bess-evpn-lsp-p...@ietf.org"
<draft-ietf-bess-evpn-lsp-p...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Cc: "bess-cha...@ietf.org" <bess-cha...@ietf.org>
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:par...@cisco.com]
Sent: Tuesday, September 7, 2021 11:56 PM
To: Dikshit, Saumya <saumya.diks...@hpe.com>;
draft-ietf-bess-evpn-lsp-p...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
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" <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>>
Date: Thursday, September 2, 2021 at 1:42 PM
To:
"draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>"
<draft-ietf-bess-evpn-lsp-p...@ietf.org<mailto:draft-ietf-bess-evpn-lsp-p...@ietf.org>>,
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>"
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>
Subject: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: <par...@cisco.com<mailto:par...@cisco.com>>,
<sbout...@ciena.com<mailto:sbout...@ciena.com>>,
<gregimir...@gmail.com<mailto:gregimir...@gmail.com>>,
<saja...@cisco.com<mailto:saja...@cisco.com>>,
<ssa...@cisco.com<mailto:ssa...@cisco.com>>
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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
