Hi Parag, Thanks for the review. Please find inline.
Regards, Saumya From: Parag Jain (paragj) [mailto:par...@cisco.com] Sent: Saturday, September 17, 2022 8:51 PM To: Dikshit, Saumya <saumya.diks...@hpe.com>; bess-cha...@ietf.org Cc: Loa Andersson <l...@pi.nu>; draft-saum-evpn-lsp-ping-extens...@ietf.org; BESS <bess@ietf.org> Subject: Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt Dear Authors, I have following comments on the draft. 1) Problem description - premise of problem statement does not right to me. Section 4.1 and 4.2 mention complexity of remembering NLRI and FEC string by operator. Operator is not supposed to enter any of these. The ping implementation should be filling in NLRI and FEC etc from protocols (e.g. evpn bgp). This is how lsp ping have been implemented industry wide for l3vpn, l2vpn etc. >>> Since it's delegated to underlying implementation, then it should also have >>> an option to transparently pass all the information to the ping PDU and the >>> needful to be done at the target tunnel end-point. Standards should be >>> open ended to take care of all use-cases. 2) Comment regarding CP checks, its up to the implementation to do CP checks or not. Router processing the ping packet can choose not do any CP checks. >>> If the request from send side is to get all the RIB information at the >>> target BPG-EVPN peer, then data-plane checks won't suffice. It's a good >>> triaging alternative to get data from remote-peer that may not provide a >>> direct management access to another operator domain. Thanks Parag From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Date: Thursday, July 14, 2022 at 4:46 AM To: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Cc: Loa Andersson <l...@pi.nu<mailto:l...@pi.nu>>, draft-saum-evpn-lsp-ping-extens...@ietf.org<mailto:draft-saum-evpn-lsp-ping-extens...@ietf.org> <draft-saum-evpn-lsp-ping-extens...@ietf.org<mailto:draft-saum-evpn-lsp-ping-extens...@ietf.org>>, BESS <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt Hello Chairs, This draft was written as part of review comments discussed on the https://datatracker.ietf.org/doc/html/draft-jain-bess-evpn-lsp-ping<https://datatracker.ietf.org/doc/html/draft-jain-bess-evpn-lsp-ping> as the authors of "https://datatracker.ietf.org/doc/html/draft-jain-bess-evpn-lsp-ping<https://datatracker.ietf.org/doc/html/draft-jain-bess-evpn-lsp-ping>" wanted to keep the comments as new requirements. Kindly review and suggest on taking this draft to conclusion. Regards, Saumya. -----Original Message----- From: Dikshit, Saumya Sent: Friday, June 3, 2022 7:37 PM To: 'bess-cha...@ietf.org' <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>> Cc: 'Loa Andersson' <l...@pi.nu<mailto:l...@pi.nu>>; 'draft-saum-evpn-lsp-ping-extens...@ietf.org' <draft-saum-evpn-lsp-ping-extens...@ietf.org<mailto:draft-saum-evpn-lsp-ping-extens...@ietf.org>>; 'BESS' <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt Hello Chairs, It will be great if you can review this draft and include it as part of bess WG. This draft surely helps solving issues which should help taking ensuring ease of serviceability from end-user point of view. Regards, Saumy.a -----Original Message----- From: Dikshit, Saumya Sent: Friday, June 3, 2022 7:32 PM To: 'Loa Andersson' <l...@pi.nu<mailto:l...@pi.nu>>; draft-saum-evpn-lsp-ping-extens...@ietf.org<mailto:draft-saum-evpn-lsp-ping-extens...@ietf.org>; BESS <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt Hi Loa, Thanks for the comments. I will surely update the section in the next-version. Regards, Saumya. -----Original Message----- From: Loa Andersson [mailto:l...@pi.nu] Sent: Friday, June 3, 2022 1:15 PM To: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>>; draft-saum-evpn-lsp-ping-extens...@ietf.org<mailto:draft-saum-evpn-lsp-ping-extens...@ietf.org>; BESS <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt Saumua, Inline please (and yes I understand that this is nit-picking, but sometimes one could do that :) ). On 2022-05-31 07:15, Dikshit, Saumya wrote: > Hi Loa, > >>>> Can you please explain what it means. > <saumya> It implies any re-use of the values from allocated via > [I-D.draft-ietf-bess-evpn-lsp-ping] when the same-parameter is referred to in > [I-D.draft-saum-evpn-lsp-ping-extension]. First, if this text goes into the RFC, it is totally redundant. Second, I can understand that this is useful information to have while this is an individual or a working group document. Though I think that "inherit" is misleading (for me it implies some type of ownership). With some experience to guide documents through more or less trick IANA allocations I would change the the IANA Considerations to: 8. IANA Considerations This document makes no request for IANA allocations. This document is dependent on the IANA considerations discussed in [I-D.draft-ietf-bess-evpn-lsp-ping]. This section should be removed before publication as an RFC. > >>>> . I would be appreciated if you notified the wg when you allocate >>>> parameters from this registry, or notify our LSP Ping registry experts, >>>> Carlos and Mach. > <saumya> +1. It's the first cut of the document. Yes, understood. I was really thinking about draft-ietf-bess-evpn-lsp-ping when I said that :). But down the line it is applicable to this draft also. /Loa Expecting few more changes based on further discussions and before firming-up on newly introduced parameters. > > Regards, > Saumya. > > -----Original Message----- > From: Loa Andersson [mailto:l...@pi.nu] > Sent: Monday, May 30, 2022 5:36 PM > To: > draft-saum-evpn-lsp-ping-extens...@ietf.org<mailto:draft-saum-evpn-lsp-ping-extens...@ietf.org>; > BESS <bess@ietf.org<mailto:bess@ietf.org>> > Subject: Re: I-D Action: draft-saum-evpn-lsp-ping-extension-01.txt > > Authors, > > the IANA section of this draft says: > > This document inherits all the IANA considerations discussed in > [I-D.draft-ietf-bess-evpn-lsp-ping]. > > Can you please explain what it means. > > WG Chairs > > The MPLS working group have put in quite a bit of effort to keep the LSP Ping > parameter registry consistent. I would be appreciated if you notified the wg > when you allocate parameters from this registry, or notify our LSP Ping > registry experts, Carlos and Mach. > > As for the allocations made in draft-ietf-bess-evpn-lsp-ping, I see no > problems. > > /Loa > > > On 2022-05-30 13:36, > internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : EVPN Mpls Ping Extension >> Authors : Saumya Dikshit >> Gyan Mishra >> Srinath Rao >> Santosh Easale >> Ashwini Dahiya >> Filename : draft-saum-evpn-lsp-ping-extension-01.txt >> Pages : 13 >> Date : 2022-05-30 >> >> Abstract: >> In an EVPN or any other VPN deployment, there is an urgent need to >> tailor the reachability checks of the client nodes via off-box tools >> which can be triggered from a remote Overlay end-point or a >> centralized controller. There is also a ease of operability needed >> when the knowledge known is partial or incomplete. This document >> aims to address the limitation in current standards for doing so and >> provides solution which can be made standards in future. As an >> additional requirement, in network border routers, there are liaison/ >> dummy VRFs created to leak routes from one network/fabric to another. >> There are scenarios wherein an explicit reachability check for these >> type of VRFs is not possible with existing mpls-ping mechanisms. >> This draft intends to address this as well. Few of missing pieces >> are equally applicable to the native lsp ping as well. >> >> >> The IETF datatracker status page for this draft is: >> INVALID URI REMOVED >> m-evpn-lsp-ping-extension/__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQGvm >> Y o0-NYkeju_lyYKP0b8F3stf1U1sL_-lytd2tpLPBA$ >> >> There is also an htmlized version available at: >> INVALID URI REMOVED >> t-saum-evpn-lsp-ping-extension-01__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmI >> Z QuQGvmYo0-NYkeju_lyYKP0b8F3stf1U1sL_-lytdDWrMYII$ >> >> A diff from the previous version is available at: >> INVALID URI REMOVED >> um-evpn-lsp-ping-extension-01__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQ >> G vmYo0-NYkeju_lyYKP0b8F3stf1U1sL_-lytdHP6k-GY$ >> >> >> Internet-Drafts are also available by rsync at >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> I-D-Announce mailing list >> i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> >> INVALID URI REMOVED >> announce__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQGvmYo0-NYkeju_lyYKP0b >> 8 F3stf1U1sL_-lytdHnzVWHg$ Internet-Draft directories: >> http://www.ietf.org/shadow.html<http://www.ietf.org/shadow.html> >> lpS2G4WnBgKZHlXUSnavWWXdQW4BbHzZGqvIO5FzLwkw0sN7VQDOfVW2XI4NIGdjn5yZb >> uwEt9k$ >> Ee_QiwECVEbzttiQKMYfUBRmIZQuQGvmYo0-NYkeju_lyYKP0b8F3stf1U1sL_-lytdpB >> w >> _Lig$ or >> INVALID URI REMOVED >> _;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQGvmYo0-NYkeju_lyYKP0b8F3stf1U1 >> s >> L_-lytdf3uGqj4$ > -- Loa Andersson email: l...@pi.nu<mailto:l...@pi.nu> Senior MPLS Expert loa.pi...@gmail.com<mailto:loa.pi...@gmail.com> Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
