Excellent! Thank you
Gyan On Fri, May 20, 2022 at 1:27 PM Dikshit, Saumya <[email protected]> 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 <[email protected]> > *Sent:* Friday, 20 May 2022, 19:58 > *To:* Dikshit, Saumya <[email protected]> > *Cc:* BESS <[email protected]>; Greg Mirsky <[email protected]>; Parag > Jain (paragj) <[email protected]>; > [email protected] < > [email protected]> > *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 <[email protected]> > 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:[email protected]] *On Behalf Of *Dikshit, >> Saumya >> *Sent:* Monday, October 25, 2021 8:23 PM >> *To:* Greg Mirsky <[email protected]> >> *Cc:* Parag Jain (paragj) <[email protected]>; >> [email protected]; Gyan Mishra < >> [email protected]>; BESS <[email protected]> >> *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 <[email protected]> >> *Cc:* Gyan Mishra <[email protected]>; Parag Jain (paragj) < >> [email protected]>; BESS <[email protected]>; >> [email protected] >> *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:[email protected] <[email protected]>] >> >> *Sent:* Friday, October 15, 2021 8:34 AM >> *To:* Dikshit, Saumya <[email protected]> >> *Cc:* Gyan Mishra <[email protected]>; Parag Jain (paragj) < >> [email protected]>; BESS <[email protected]>; >> [email protected] >> *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 protected]> >> 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 protected]] >> *Sent:* Wednesday, October 13, 2021 8:41 PM >> *To:* Parag Jain (paragj) <[email protected]> >> *Cc:* BESS <[email protected]>; Dikshit, Saumya <[email protected]>; >> Greg Mirsky <[email protected]>; >> [email protected] >> *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 protected]> 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" <[email protected]> >> *Date: *Wednesday, October 13, 2021 at 12:10 AM >> *To: *Greg Mirsky <[email protected]>, BESS <[email protected]> >> *Cc: *"[email protected]" < >> [email protected]>, "Parag Jain (paragj)" < >> [email protected]> >> *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:[email protected]] >> *Sent:* Tuesday, October 12, 2021 9:39 PM >> *To:* Dikshit, Saumya <[email protected]>; BESS <[email protected]> >> *Cc:* [email protected]; Parag Jain (paragj) < >> [email protected]> >> *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 protected]> >> 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 protected]] *On Behalf Of *Dikshit, >> Saumya >> *Sent:* Monday, September 13, 2021 7:31 PM >> *To:* Greg Mirsky <[email protected]> >> *Cc:* [email protected]; [email protected]; >> Parag Jain (paragj) <[email protected]>; [email protected] >> *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 protected] <[email protected]>] >> >> *Sent:* Monday, September 13, 2021 12:23 AM >> *To:* Dikshit, Saumya <[email protected]> >> *Cc:* Parag Jain (paragj) <[email protected]>; >> [email protected]; [email protected]; >> [email protected] >> *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 protected]> >> 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 protected]] >> *Sent:* Saturday, September 11, 2021 8:19 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 >> >> >> >> Pls see inline. >> >> >> >> *From: *"Dikshit, Saumya" <[email protected]> >> *Date: *Thursday, September 9, 2021 at 3:54 AM >> *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, >> >> >> >> Please see inline. Let me know your thoughts. >> >> >> >> Thanks >> >> Saumya. >> >> >> >> *From:* Parag Jain (paragj) [mailto:[email protected] <[email protected]>] >> *Sent:* Wednesday, September 8, 2021 11:43 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 >> >> >> >> 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. >> >> >> 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 protected] <[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]> >> *Date: *Thursday, September 2, 2021 at 1:42 PM >> *To: *"[email protected]" < >> [email protected]>, "[email protected]" <[email protected]> >> *Cc: *"[email protected]" <[email protected]> >> *Subject: *Query/comments on draft-ietf-bess-evpn-lsp-ping-05 >> *Resent-From: *<[email protected]> >> *Resent-To: *<[email protected]>, <[email protected]>, < >> [email protected]>, <[email protected]>, <[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 >> >> -- >> >> [image: Image removed by sender.] <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email [email protected] <[email protected]>* >> >> *M 301 502-1347* >> >> >> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347 * > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
