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

[Gyan Mishra <[e-mail]>]

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 <[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]>rg>; Dikshit, Saumya <[e-mail]>om>;
> Greg Mirsky <[e-mail]>om>;
> [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]>om>, BESS <[e-mail]>
> *Cc: *"[e-mail]" <
> [e-mail]>gt;, "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]>om>; 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]>om>; [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]>om>;
> [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]>om>;
> [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]>om>, "
> [e-mail]" <
> [e-mail]>gt;, "[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]>om>;
> [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]>om>, "
> [e-mail]" <
> [e-mail]>gt;, "[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]>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]>
> *Date: *Thursday, September 2, 2021 at 1:42 PM
> *To: *"[e-mail]" <
> [e-mail]>gt;, "[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]>om>, <[e-mail]>om>, <
> [e-mail]>gt;, <[e-mail]>om>, <[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
>
> --
>
> <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*