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

From: Greg Mirsky <[email-masked]>
Date: Tue, 12 Oct 2021 09:08:56 -0700

Hi Saumya,
thank you for sharing your ideas about extending EVNP LSP Ping
functionality. These are interesting and useful proposals that, in my
opinion, further extend the basic functionality of EVNP LSP Ping as defined
in the draft. I'll be happy to discuss and work with you and others on a
new document to introduce new extensions. In the meantime, progressing the
current version of the EVPN LSP Ping document with the "classic" 8209-style
scope is extremely important for network operators that need standard-based
OAM tools in their toolboxes.
What is your opinion?

Regards,
Greg

On Tue, Sep 14, 2021 at 7:24 AM Dikshit, Saumya <[email-masked]>
wrote:

> Multicasting it to authors of the draft, if the below use cases and
> (potential) solution can be made as part of this draft.
>
>
> Thanks
>
> Saumya.
>
>
>
>
>
> *From:* BESS [mailto:[email-masked]] *On Behalf Of *Dikshit, Saumya
> *Sent:* Monday, September 13, 2021 7:31 PM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Parag
> Jain (paragj) <[email-masked]>; [email-masked]
> *Subject:* Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Thank you Greg.
>
>
>
> +1 on this drafts compliance to RFC8209.
>
>
>
> There are couple of requirements spelled out in the email below,
> summarizing it here as well:
>
> 1.       Allow wild-card/don’t-care values for attributes carried in the
> sub-TLVs as it will surely help when all details are not available. To draw
> parallels I see it equivalent to querying for an (potential) NLRI in a
> BGP-EVPN RIB via a management interface, where in all parameters hard to
> gather.
>
> 2.     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 publishes 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. Hence an lsp-ping to validate the configuration
> of VRF_X on remote PE should help here.
>
> If this can be achieved by incremental changes to this draft, shall be
> helpful. #2 requirement is equally applicable to VRF-LITE as well and can
> be called out an extension to rfc8209.
>
> Regards,
>
> Saumya.
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Monday, September 13, 2021 12:23 AM
> *To:* Dikshit, Saumya <[email-masked]>
> *Cc:* Parag Jain (paragj) <[email-masked]>;
> [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Saumya,
>
> thank you for your comments and questions.
>
> As I understand the draft, it does not update RFC 8029 and, as a result,
> everything that has been defined in RFC 8029 is fully applicable and can be
> used in EVPN and MVPN environments. If there's any part of the text that is
> not clear, please let me know and we can work together on improving it.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Sep 12, 2021 at 10:02 AM Dikshit, Saumya <[email-masked]>
> wrote:
>
> Hi Parag,
>
>
>
> Thank you for the response. Please see inline with tag [SD2] and provide
> your further inputs.
>
>
>
> Thanks
>
> Saumya.
>
>
>
> *From:* Parag Jain (paragj) [mailto:[email-masked]]
> *Sent:* Saturday, September 11, 2021 8:19 PM
> *To:* Dikshit, Saumya <[email-masked]>;
> [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Saumya
>
>
>
> Pls see inline.
>
>
>
> *From: *"Dikshit, Saumya" <[email-masked]>
> *Date: *Thursday, September 9, 2021 at 3:54 AM
> *To: *"Parag Jain (paragj)" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Parag,
>
>
>
> Please see inline. Let me know your thoughts.
>
>
>
> Thanks
>
> Saumya.
>
>
>
> *From:* Parag Jain (paragj) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, September 8, 2021 11:43 PM
> *To:* Dikshit, Saumya <[email-masked]>;
> [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>
>
>
> Hi Saumya
>
>
>
> Pls see inline.
>
>
>
> *From: *"Dikshit, Saumya" <[email-masked]>
> *Date: *Tuesday, September 7, 2021 at 3:22 PM
> *To: *"Parag Jain (paragj)" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *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.
>
>
>    1. 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.
>
> [SD] I am little unclear, as to how running the Sub-TLV parameters through
> the RIB, will ensure that this RIB entry (NLRI) was CHOSEN as the FIB
> entry.
>
> Essentially, the RIB entry mapping to the Sub-TLV, has to contend with
> other RIB entries and also with same route published by other protocols (or
> instances of protocol), eventually get picked as FIB entry.  Lsp ping to
> the sub-tlv may pan out differently in RIB and in FIB. But as I understand,
> that is not the purpose of this reachability check defined in this draft.
>
>
>
> Paragj2> I also mentioned bgp and evpn CP components above.
>
>
>
> We should call out this out specifically in the document or stick to
> validating the datapath.
>
> Paragj2> DP-CP consistency check is an important part of lsp ping
> functionality. As RFC8029 states, the LSP echo message contains sufficient
> information to  verify correctness of DP operations and verify DP against
> CP to localize the fault.
>
> [SD2] I am not contending DP-CP validation when needed, but when partial
> information is known (w.r.t), it will be good to go with remaining
> parameters as wild/card. Even RFC8029 provides some leeway in various
> sections. For example, in
> https://datatracker.ietf.org/doc/html/rfc8029#section-4, it tends to keep
> the underlay information open-ended if not known:
>
> “If the underlying (LDP) tunnel were not known, or
>
>    was considered irrelevant, the FEC Stack could be a single element
>
>    with just the VPN IPv4 sub-TLV.”
>
>
>
>
>
> Both RIB and FIB validation (leading to successful echo response), may not
> indicate that right RIB and FIB are consistent with respect to sub-tlv
> being carried.
>
> I suggest that we keep lsp ping to just the data plane validation.
> Consistency-check will require lot of compute (might need a complete path
> calculation of BGP-EVPN), to indicate the consistency. Good to know if
> there are reference implementations optimizing this already.
>
> This is one more reason to use wild card.
>
>
>
>    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.
>
>
>    1. 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.
>
>    1. 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.
>
> [SD] That’s a good solution to have. I have mentioned the use-case in
> below email.
>
> I propose that we leverage the existing “EVPN IP Prefix Sub-TLV”, with
> appropriate values (may be wild-card/don’t care) to realize this.
>
>
>
> Paragj2> EVPN IP Prefix sub-tlv is for verifying ip prefix in a vrf. I am
> not sure it should/can be applied to the use case you  mention.
>
> [SD2] My take was to re-use tlvs/info carried in lsp-ping as already
> defined in this draft. If not agreeable to authors and group members, it
> will be good to define a new tlv (or otherwise) via an ancillary draft if
> needed. I can do that if, authors of this draft feel that it’s a misfit in
> this document. Since the label encoding can implicitly map to the VRF/EVI
> on the target, a sub-tlv indicating an EVI-check (either L2 or L3) can help
> the cause..
>
>
>
> Thanks
>
> Parag
>
>
>
>
>
> as I mentioned in #2 of below email
>
>    1. 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-masked] <[email-masked]>]
> *Sent:* Tuesday, September 7, 2021 11:56 PM
> *To:* Dikshit, Saumya <[email-masked]>;
> [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *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-masked]>
> *Date: *Thursday, September 2, 2021 at 1:42 PM
> *To: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Query/comments on draft-ietf-bess-evpn-lsp-ping-05
> *Resent-From: *<[email-masked]>
> *Resent-To: *<[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, <[email-masked]>
> *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.
>
>
>
>

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Wed, 13 Oct 2021 04:10:15 +0000

Hi Greg,

Thank you for acknowledging.
I agree that a new extension draft should be written to include below proposals.

+1 on progressing with current state of this draft draft-ietf-bess-evpn-lsp-ping

Thanks
Saumya.

From: Greg Mirsky [mailto:[email-masked]]
Sent: Tuesday, October 12, 2021 9:39 PM
To: Dikshit, Saumya <[email-masked]>; BESS <[email-masked]>
Cc: [email-masked]; Parag Jain (paragj) <[email-masked]>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya,
thank you for sharing your ideas about extending EVNP LSP Ping functionality. These are interesting and useful proposals that, in my opinion, further extend the basic functionality of EVNP LSP Ping as defined in the draft. I'll be happy to discuss and work with you and others on a new document to introduce new extensions. In the meantime, progressing the current version of the EVPN LSP Ping document with the "classic" 8209-style scope is extremely important for network operators that need standard-based OAM tools in their toolboxes.
What is your opinion?

Regards,
Greg

On Tue, Sep 14, 2021 at 7:24 AM Dikshit, Saumya <[email-masked]<mailto:[email-masked]>> wrote:
Multicasting it to authors of the draft, if the below use cases and (potential) solution can be made as part of this draft.

Thanks
Saumya.

From: BESS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dikshit, Saumya
Sent: Monday, September 13, 2021 7:31 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Parag Jain (paragj) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Thank you Greg.

There are couple of requirements spelled out in the email below, summarizing it here as well:

1.       Allow wild-card/don’t-care values for attributes carried in the sub-TLVs as it will surely help when all details are not available. To draw parallels I see it equivalent to querying for an (potential) NLRI in a BGP-EVPN RIB via a management interface, where in all parameters hard to gather.

2.     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 publishes 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. Hence an lsp-ping to validate the configuration of VRF_X on remote PE should help here.
If this can be achieved by incremental changes to this draft, shall be helpful. #2 requirement is equally applicable to VRF-LITE as well and can be called out an extension to rfc8209.
Regards,
Saumya.

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, September 13, 2021 12:23 AM
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>
Cc: Parag Jain (paragj) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya,
thank you for your comments and questions.
As I understand the draft, it does not update RFC 8029 and, as a result, everything that has been defined in RFC 8029 is fully applicable and can be used in EVPN and MVPN environments. If there's any part of the text that is not clear, please let me know and we can work together on improving it.

Regards,
Greg

On Sun, Sep 12, 2021 at 10:02 AM Dikshit, Saumya <[email-masked]<mailto:[email-masked]>> wrote:
Hi Parag,

Thank you for the response. Please see inline with tag [SD2] and provide your further inputs.

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, September 11, 2021 8:19 PM
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya

Pls see inline.

From: "Dikshit, Saumya" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 9, 2021 at 3:54 AM
To: "Parag Jain (paragj)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Parag,

Thanks
Saumya.

From: Parag Jain (paragj) [mailto:[email-masked]]
Sent: Wednesday, September 8, 2021 11:43 PM
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya

Pls see inline.

From: "Dikshit, Saumya" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 7, 2021 at 3:22 PM
To: "Parag Jain (paragj)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Parag,

  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.
[SD] I am little unclear, as to how running the Sub-TLV parameters through the RIB, will ensure that this RIB entry (NLRI) was CHOSEN as the FIB entry.
Essentially, the RIB entry mapping to the Sub-TLV, has to contend with other RIB entries and also with same route published by other protocols (or instances of protocol), eventually get picked as FIB entry.  Lsp ping to the sub-tlv may pan out differently in RIB and in FIB. But as I understand, that is not the purpose of this reachability check defined in this draft.

We should call out this out specifically in the document or stick to validating the datapath.
Paragj2> DP-CP consistency check is an important part of lsp ping functionality. As RFC8029 states, the LSP echo message contains sufficient information to  verify correctness of DP operations and verify DP against CP to localize the fault.
[SD2] I am not contending DP-CP validation when needed, but when partial information is known (w.r.t), it will be good to go with remaining parameters as wild/card. Even RFC8029 provides some leeway in various sections. For example, in https://datatracker.ietf.org/doc/html/rfc8029#section-4<https://datatracker.ietf.org/doc/html/rfc8029#section-4>, it tends to keep the underlay information open-ended if not known:

Both RIB and FIB validation (leading to successful echo response), may not indicate that right RIB and FIB are consistent with respect to sub-tlv being carried.
I suggest that we keep lsp ping to just the data plane validation. Consistency-check will require lot of compute (might need a complete path calculation of BGP-EVPN), to indicate the consistency. Good to know if there are reference implementations optimizing this already.
This is one more reason to use wild card.

  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.
[SD] That’s a good solution to have. I have mentioned the use-case in below email.
I propose that we leverage the existing “EVPN IP Prefix Sub-TLV”, with appropriate values (may be wild-card/don’t care) to realize this.

Paragj2> EVPN IP Prefix sub-tlv is for verifying ip prefix in a vrf. I am not sure it should/can be applied to the use case you  mention.
[SD2] My take was to re-use tlvs/info carried in lsp-ping as already defined in this draft. If not agreeable to authors and group members, it will be good to define a new tlv (or otherwise) via an ancillary draft if needed. I can do that if, authors of this draft feel that it’s a misfit in this document. Since the label encoding can implicitly map to the VRF/EVI on the target, a sub-tlv indicating an EVI-check (either L2 or L3) can help the cause..

Thanks
Parag

     *   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-masked]]
Sent: Tuesday, September 7, 2021 11:56 PM
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>>
Date: Thursday, September 2, 2021 at 1:42 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, September 2, 2021 at 1:42 PM

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).

>>>> 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”.

Thanks
Saumya.

---

From: "Parag Jain (paragj)" <[email-masked]>
Date: Wed, 13 Oct 2021 12:20:07 +0000

Hi Saumya

Thank you agreeing to progressing draft-ietf-bess-evpn-lsp-ping in the current state.

Thank you Saumya and Greg for closing on this.

I’ll be happy to participate in the new proposal discussions.

regards
Parag

From: "Dikshit, Saumya" <[email-masked]>
Date: Wednesday, October 13, 2021 at 12:10 AM
To: Greg Mirsky <[email-masked]>, BESS <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Parag Jain (paragj)" <[email-masked]>
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Greg,

Thanks
Saumya.

Hi Saumya,

Regards,
Greg

Thanks
Saumya.

Thank you Greg.

Hi Saumya,

Regards,
Greg

Thanks
Saumya.

Hi Saumya

Pls see inline.

Hi Parag,

Thanks
Saumya.

Hi Saumya

Pls see inline.

Hi Parag,

We should call out this out specifically in the document or stick to validating the datapath.
Paragj2> DP-CP consistency check is an important part of lsp ping functionality. As RFC8029 states, the LSP echo message contains sufficient information to  verify correctness of DP operations and verify DP against CP to localize the fault.
[SD2] I am not contending DP-CP validation when needed, but when partial information is known (w.r.t), it will be good to go with remaining parameters as wild/card. Even RFC8029 provides some leeway in various sections. For example, in https://datatracker.ietf.org/doc/html/rfc8029#section-4, it tends to keep the underlay information open-ended if not known:

Thanks
Parag

Thanks
Saumya.

Hi Saumya

Thanks
Parag

Thanks
Saumya.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 13 Oct 2021 11:10:39 -0400

Hi Saumya & Greg

I would be happy to work on collaboration of this new draft as I can
provide an operational POV on criticality on CP - DP consistency check
validation for network operators in an NVO environment.

There are  production scenarios with timing of state machine events with
CP-DP that may have false positive or negative with LSP ping in NVO
environment where an issue may still exists with consistency and out of
sync situations due to the timing of events.

Kind Regards

Gyan

On Wed, Oct 13, 2021 at 8:20 AM Parag Jain (paragj) <paragj=
[email-masked]> wrote:

> *Date: *Wednesday, October 13, 2021 at 12:10 AM
> *To: *Greg Mirsky <[email-masked]>, BESS <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "Parag Jain (paragj)" <
> [email-masked]>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Tuesday, October 12, 2021 9:39 PM
> *To:* Dikshit, Saumya <[email-masked]>; BESS <[email-masked]>
> *Cc:* [email-masked]; Parag Jain (paragj) <
> [email-masked]>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Thu, 14 Oct 2021 10:30:41 +0000

Thanks Gyan,Parag.
Please suggest, how do we trigger the discussion.
I can a Spin-out a rev-0 for a new draft. Let me know your thoughts.

Regards,
Saumya.

From: Gyan Mishra [mailto:[email-masked]]
Sent: Wednesday, October 13, 2021 8:41 PM
To: Parag Jain (paragj) <paragj=[email-masked]>
Cc: BESS <[email-masked]>; Dikshit, Saumya <[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]
Subject: Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya & Greg

I would be happy to work on collaboration of this new draft as I can provide an operational POV on criticality on CP - DP consistency check validation for network operators in an NVO environment.

There are  production scenarios with timing of state machine events with CP-DP that may have false positive or negative with LSP ping in NVO environment where an issue may still exists with consistency and out of sync situations due to the timing of events.

Kind Regards

Gyan
TA
On Wed, Oct 13, 2021 at 8:20 AM Parag Jain (paragj) <paragj=[email-masked]<mailto:[email-masked]>> wrote:
Hi Saumya

regards
Parag

From: "Dikshit, Saumya" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 13, 2021 at 12:10 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, BESS <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Parag Jain (paragj)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Greg,

Thanks
Saumya.

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 12, 2021 9:39 PM
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; BESS <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Parag Jain (paragj) <[email-masked]<mailto:[email-masked]>>
Subject: Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya,

Regards,
Greg

Thanks
Saumya.

Thank you Greg.

Hi Saumya,

Regards,
Greg

Thanks
Saumya.

Hi Saumya

Pls see inline.

Hi Parag,

Thanks
Saumya.

Hi Saumya

Pls see inline.

Hi Parag,

Thanks
Parag

Thanks
Saumya.

Hi Saumya

Thanks
Parag

Thanks
Saumya.

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 Oct 2021 22:28:12 -0400

Hi Saumya

Once you have the Rev-0, send a summary of the context of the gap the draft
will solve and solicit feedback from the WG.

Kind Regards

Gyan

On Thu, Oct 14, 2021 at 6:31 AM Dikshit, Saumya <[email-masked]>
wrote:

> *From:* Gyan Mishra [mailto:[email-masked]]
> *Sent:* Wednesday, October 13, 2021 8:41 PM
> *To:* Parag Jain (paragj) <paragj=[email-masked]>
> *Cc:* BESS <[email-masked]>; Dikshit, Saumya <[email-masked]>;
> Greg Mirsky <[email-masked]>;
> [email-masked]
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 14 Oct 2021 20:04:01 -0700

Hi Saumya,
you've brought up several good cases that we can solve using the EVPN LSP
Ping. Let's start with them as the problem statements. Then we discuss how
to solve them.

Regards,
Greg

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Mon, 18 Oct 2021 03:57:37 +0000

Hi Greg, Parag, Gyan, et al.

Let me start a fresh email with an apt subject line, collating all bullets from earlier exchanges.

Thanks
Saumya.

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, October 15, 2021 8:34 AM
To: Dikshit, Saumya <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Parag Jain (paragj) <paragj=[email-masked]>; BESS <[email-masked]>; [email-masked]
Subject: Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya,
you've brought up several good cases that we can solve using the EVPN LSP Ping. Let's start with them as the problem statements. Then we discuss how to solve them.

Regards,
Greg

On Thu, Oct 14, 2021 at 3:31 AM Dikshit, Saumya <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Gyan,Parag.
Please suggest, how do we trigger the discussion.
I can a Spin-out a rev-0 for a new draft. Let me know your thoughts.

Regards,
Saumya.

From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, October 13, 2021 8:41 PM
To: Parag Jain (paragj) <paragj=[email-masked]<mailto:[email-masked]>>
Cc: BESS <[email-masked]<mailto:[email-masked]>>; Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05

Hi Saumya & Greg

Kind Regards

Gyan
TA

regards
Parag

Hi Greg,

Thanks
Saumya.

Hi Saumya,

Regards,
Greg

Thanks
Saumya.

Thank you Greg.

Hi Saumya,

Regards,
Greg

Thanks
Saumya.

Hi Saumya

Pls see inline.

Hi Parag,

Thanks
Saumya.

Hi Saumya

Pls see inline.

Hi Parag,

Thanks
Parag

Thanks
Saumya.

Hi Saumya

Thanks
Parag

Thanks
Saumya.

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347