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_QiwECVEbzttiQKMYfUBRmIZQuQGvmY
>> o0-NYkeju_lyYKP0b8F3stf1U1sL_-lytd2tpLPBA$
>>
>> There is also an htmlized version available at:
>> INVALID URI REMOVED
>> t-saum-evpn-lsp-ping-extension-01__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZ
>> QuQGvmYo0-NYkeju_lyYKP0b8F3stf1U1sL_-lytdDWrMYII$
>>
>> A diff from the previous version is available at:
>> INVALID URI REMOVED
>> um-evpn-lsp-ping-extension-01__;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQG
>> 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_lyYKP0b8
>> F3stf1U1sL_-lytdHnzVWHg$ Internet-Draft directories:
>> http://www.ietf.org/shadow.html 
>> Ee_QiwECVEbzttiQKMYfUBRmIZQuQGvmYo0-NYkeju_lyYKP0b8F3stf1U1sL_-lytdpBw
>> _Lig$ or
>> INVALID URI REMOVED
>> _;!!NpxR!lEe_QiwECVEbzttiQKMYfUBRmIZQuQGvmYo0-NYkeju_lyYKP0b8F3stf1U1s
>> 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

Reply via email to