Re: [bess] Enhancing lsp ping (in extension to draft-ietf-bess-evpn-lsp-ping)

[Gyan Mishra <[e-mail]>]

Excellent!

Thank you

Gyan

On Fri, May 20, 2022 at 1:27 PM Dikshit, Saumya <[e-mail]>
wrote:

> Thanks Gyan. I will add you in the next version in a weeks time, as on
> road till then.
>
> Yes, 2 out of 3 requirements are equally applicable to mpls underlay. I
> think i have mentioned it in few places in the doc, else we can add a
> section to call it out.
>
> Regards,
> Saumya.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Friday, 20 May 2022, 19:58
> *To:* Dikshit, Saumya <[e-mail]>
> *Cc:* BESS <[e-mail]>; Greg Mirsky <[e-mail]>; Parag
> Jain (paragj) <paragj=[e-mail]>;
> [e-mail] <
> [e-mail]>
> *Subject:* Re: Enhancing lsp ping (in extension to
> draft-ietf-bess-evpn-lsp-ping)
>
> Hi Saumya
>
> I reviewed the draft and the bullet points requirements in your earlier
> email and the draft looks good and I would be happy to collaborate on this
> effort.
>
> I agree this LSP ping extension will help with troubleshooting CP-DP
> issues that are extremely  difficult to resolve in NVO environments.
>
> Is the primary focus for DC NVO encapsulation environments and secondarily
> for MPLS underlay environments?
>
> Kind Regards
>
> Gyan
>
> On Thu, May 19, 2022 at 4:53 AM Dikshit, Saumya <[e-mail]>
> wrote:
>
>> Hello All,
>>
>>
>>
>> We have published a new draft
>> https://datatracker.ietf.org/doc/draft-saum-evpn-lsp-ping-extension/
>>
>> The intention is to deal with the requirements mentioned in the email
>> chain below.
>>
>> This is the outcome of comments which I had made while reviewing “
>> draft-ietf-bess-evpn-lsp-ping”
>>
>> and consensus was that it can be dealt in a separate document.
>>
>>
>>
>> Please provide your comments and help evolving it further.
>>
>>
>>
>> Regards,
>>
>> Saumya.
>>
>>
>>
>> *From:* BESS [mailto:[e-mail]] *On Behalf Of *Dikshit,
>> Saumya
>> *Sent:* Monday, October 25, 2021 8:23 PM
>> *To:* Greg Mirsky <[e-mail]>
>> *Cc:* Parag Jain (paragj) <paragj=[e-mail]>;
>> [e-mail]; Gyan Mishra <
>> [e-mail]>; BESS <[e-mail]>
>> *Subject:* [bess] Enhancing lsp ping (in extension to
>> draft-ietf-bess-evpn-lsp-ping)
>>
>>
>>
>> [Changing the subject line]
>>
>> Summarizing the requirements:
>>
>> 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.  The permutation & combinations can be listed down in detail, in
>> course of discussion.
>>
>> 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.
>>
>> 3.   To choose between a mode, where the CP-DP consistency check can be
>> relaxed only to perform a DP lookup. The modes can be
>>
>>       - CP-DP Consistency Check mode
>>
>>       - DP only check
>>
>> Please feel free to add. If this can be generalized for any solution
>> (EVPN, L3VPN, L2VPN->VPLS/VPWS) provisioned over MPLS fabric.
>>
>> Thanks
>>
>> Saumya.
>>
>>
>>
>>
>>
>> *From:* Dikshit, Saumya
>> *Sent:* Monday, October 18, 2021 9:28 AM
>> *To:* Greg Mirsky <[e-mail]>
>> *Cc:* Gyan Mishra <[e-mail]>; Parag Jain (paragj) <
>> paragj=[e-mail]>; BESS <[e-mail]>;
>> [e-mail]
>> *Subject:* RE: [bess] Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>>
>>
>>
>> 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:[e-mail] <[e-mail]>]
>>
>> *Sent:* Friday, October 15, 2021 8:34 AM
>> *To:* Dikshit, Saumya <[e-mail]>
>> *Cc:* Gyan Mishra <[e-mail]>; Parag Jain (paragj) <
>> paragj=[e-mail]>; BESS <[e-mail]>;
>> [e-mail]
>> *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 <[e-mail]>
>> 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:[e-mail]]
>> *Sent:* Wednesday, October 13, 2021 8:41 PM
>> *To:* Parag Jain (paragj) <paragj=[e-mail]>
>> *Cc:* BESS <[e-mail]>; Dikshit, Saumya <[e-mail]>;
>> Greg Mirsky <[e-mail]>;
>> [e-mail]
>> *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=
>> [e-mail]> wrote:
>>
>> 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" <[e-mail]>
>> *Date: *Wednesday, October 13, 2021 at 12:10 AM
>> *To: *Greg Mirsky <[e-mail]>, BESS <[e-mail]>
>> *Cc: *"[e-mail]" <
>> [e-mail]>, "Parag Jain (paragj)" <
>> [e-mail]>
>> *Subject: *RE: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>>
>>
>>
>> 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:[e-mail]]
>> *Sent:* Tuesday, October 12, 2021 9:39 PM
>> *To:* Dikshit, Saumya <[e-mail]>; BESS <[e-mail]>
>> *Cc:* [e-mail]; Parag Jain (paragj) <
>> [e-mail]>
>> *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 <[e-mail]>
>> 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:[e-mail]] *On Behalf Of *Dikshit,
>> Saumya
>> *Sent:* Monday, September 13, 2021 7:31 PM
>> *To:* Greg Mirsky <[e-mail]>
>> *Cc:* [e-mail]; [e-mail];
>> Parag Jain (paragj) <[e-mail]>; [e-mail]
>> *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:[e-mail] <[e-mail]>]
>>
>> *Sent:* Monday, September 13, 2021 12:23 AM
>> *To:* Dikshit, Saumya <[e-mail]>
>> *Cc:* Parag Jain (paragj) <[e-mail]>;
>> [e-mail]; [e-mail];
>> [e-mail]
>> *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 <[e-mail]>
>> 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:[e-mail]]
>> *Sent:* Saturday, September 11, 2021 8:19 PM
>> *To:* Dikshit, Saumya <[e-mail]>;
>> [e-mail]; [e-mail]
>> *Cc:* [e-mail]
>> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>>
>>
>>
>> Hi Saumya
>>
>>
>>
>> Pls see inline.
>>
>>
>>
>> *From: *"Dikshit, Saumya" <[e-mail]>
>> *Date: *Thursday, September 9, 2021 at 3:54 AM
>> *To: *"Parag Jain (paragj)" <[e-mail]>, "
>> [e-mail]" <
>> [e-mail]>, "[e-mail]" <[e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>
>> *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:[e-mail] <[e-mail]>]
>> *Sent:* Wednesday, September 8, 2021 11:43 PM
>> *To:* Dikshit, Saumya <[e-mail]>;
>> [e-mail]; [e-mail]
>> *Cc:* [e-mail]
>> *Subject:* Re: Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>>
>>
>>
>> Hi Saumya
>>
>>
>>
>> Pls see inline.
>>
>>
>>
>> *From: *"Dikshit, Saumya" <[e-mail]>
>> *Date: *Tuesday, September 7, 2021 at 3:22 PM
>> *To: *"Parag Jain (paragj)" <[e-mail]>, "
>> [e-mail]" <
>> [e-mail]>, "[e-mail]" <[e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>
>> *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:[e-mail] <[e-mail]>]
>> *Sent:* Tuesday, September 7, 2021 11:56 PM
>> *To:* Dikshit, Saumya <[e-mail]>;
>> [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]>
>> *Date: *Thursday, September 2, 2021 at 1:42 PM
>> *To: *"[e-mail]" <
>> [e-mail]>, "[e-mail]" <[e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>
>> *Subject: *Query/comments on draft-ietf-bess-evpn-lsp-ping-05
>> *Resent-From: *<[e-mail]>
>> *Resent-To: *<[e-mail]>, <[e-mail]>, <
>> [e-mail]>, <[e-mail]>, <[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.
>>
>>
>>
>> _______________________________________________
>> BESS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bess
>>
>> --
>>
>> [image: Image removed by sender.] <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347 *
>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*