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>; 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 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>; 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 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; BESS <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 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 >> INVALID URI REMOVED >> announce__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQGvmYo0-NYkeju_lyYKP0b >> 8 F3stf1U1sL_-lytdHnzVWHg$ Internet-Draft directories: >> 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 Senior MPLS Expert loa.pi...@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
