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 <saumya.diks...@hpe.com> 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:hayabusa...@gmail.com] > *Sent:* Wednesday, October 13, 2021 8:41 PM > *To:* Parag Jain (paragj) <paragj=40cisco....@dmarc.ietf.org> > *Cc:* BESS <bess@ietf.org>; Dikshit, Saumya <saumya.diks...@hpe.com>; > Greg Mirsky <gregimir...@gmail.com>; > draft-ietf-bess-evpn-lsp-p...@ietf.org > *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= > 40cisco....@dmarc.ietf.org> 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" <saumya.diks...@hpe.com> > *Date: *Wednesday, October 13, 2021 at 12:10 AM > *To: *Greg Mirsky <gregimir...@gmail.com>, BESS <bess@ietf.org> > *Cc: *"draft-ietf-bess-evpn-lsp-p...@ietf.org" < > draft-ietf-bess-evpn-lsp-p...@ietf.org>, "Parag Jain (paragj)" < > par...@cisco.com> > *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:gregimir...@gmail.com] > *Sent:* Tuesday, October 12, 2021 9:39 PM > *To:* Dikshit, Saumya <saumya.diks...@hpe.com>; BESS <bess@ietf.org> > *Cc:* draft-ietf-bess-evpn-lsp-p...@ietf.org; Parag Jain (paragj) < > par...@cisco.com> > *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 <saumya.diks...@hpe.com> > 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:bess-boun...@ietf.org] *On Behalf Of *Dikshit, Saumya > *Sent:* Monday, September 13, 2021 7:31 PM > *To:* Greg Mirsky <gregimir...@gmail.com> > *Cc:* draft-ietf-bess-evpn-lsp-p...@ietf.org; bess-cha...@ietf.org; Parag > Jain (paragj) <par...@cisco.com>; bess@ietf.org > *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:gregimir...@gmail.com <gregimir...@gmail.com>] > > *Sent:* Monday, September 13, 2021 12:23 AM > *To:* Dikshit, Saumya <saumya.diks...@hpe.com> > *Cc:* Parag Jain (paragj) <par...@cisco.com>; > draft-ietf-bess-evpn-lsp-p...@ietf.org; bess@ietf.org; > bess-cha...@ietf.org > *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 <saumya.diks...@hpe.com> > 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:par...@cisco.com] > *Sent:* Saturday, September 11, 2021 8:19 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 > > > > Pls see inline. > > > > *From: *"Dikshit, Saumya" <saumya.diks...@hpe.com> > *Date: *Thursday, September 9, 2021 at 3:54 AM > *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, > > > > Please see inline. Let me know your thoughts. > > > > Thanks > > Saumya. > > > > *From:* Parag Jain (paragj) [mailto:par...@cisco.com <par...@cisco.com>] > *Sent:* Wednesday, September 8, 2021 11:43 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 > > > > 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. > > > 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:par...@cisco.com <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> > *Date: *Thursday, September 2, 2021 at 1:42 PM > *To: *"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: *Query/comments on draft-ietf-bess-evpn-lsp-ping-05 > *Resent-From: *<alias-boun...@ietf.org> > *Resent-To: *<par...@cisco.com>, <sbout...@ciena.com>, < > gregimir...@gmail.com>, <saja...@cisco.com>, <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 > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
