Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-unsolicited-09

On 1/18/22, 8:33 AM, "rtg-dir on behalf of Jeffrey Haas" wrote: Henning, Thank you for your comments on this draft. On Fri, Jan 14, 2022 at 04:29:48AM -0800, Henning Rogge via Datatracker wrote: > I have two nits with the document... > > 1st, I would like a

Re: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

I support publication of the latest version of the draft (I had supported the previous version as well). Thanks, Acee On 1/11/22, 4:37 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: Just a reminder that WGLC for this ends on Friday. Your review is greatly appreciated. -- Jeff

Re: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

This version looks ready to me. I support publication. Thanks, Acee On 1/5/22, 2:18 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: Working Group, This begins a second round of Working Group Last Call on the RFC 9127-bis work. As a reminder, this is primarily to address

Re: [yang-doctors] RFC 9127-bis question - impact of reference clauses in an import statement

I support proceeding as Jeff suggests. I'm confident other BFD WG members would agree and the lack of other opinions is due to everyone feeling this was a done deal. Thanks, Acee On 12/22/21, 1:42 PM, "yang-doctors on behalf of Jeffrey Haas" wrote: [Note - re-send to fix bfd list

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Note that I also reviewed the YANG model for the extensions and don't have any issues. I was a little surprised to see two features but I can't see a better way to support global configuration AND/OR interface configuration. On 8/4/20, 10:09 AM, "Acee Lindem (acee)" wrote:

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

I've read the document (more than once) and support publication. It is a very simple BFD extension that simplifies deployment for the use cases enumerated in the "Introduction". I have one editorial comments: Can you use phasing other than "initiates BFD control packets"? Perhaps,

Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication

Hi Mahesh, From: Rtg-bfd on behalf of Mahesh Jethanandani Date: Thursday, July 2, 2020 at 12:14 AM To: "Reshad Rahman (rrahman)" Cc: "rtg-bfd@ietf. org" , "draft-ietf-bfd-optimizing-authenticat...@ietf.org" Subject: Re: Shepherd writeup for draft-ietf-bfd-optimizing-authentication Hi

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

ent for each client of the BFD session. If that is a plausible use case, I think that placing dampening to a client may be a better choice. Regards, Greg On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee) mailto:a...@cisco.com>> wrote: Hi Albert, Ketan, The authors will document dampening in

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Albert, Ketan, The authors will document dampening in the operational considerations. I’m also of the mind that the dampening should be done in BFD rather than the BFD clients (e.g., BGP). Thanks, Acee From: Lsr on behalf of Albert F Date: Thursday, July 25, 2019 at 5:14 PM To: "Ketan

Re: IETF 104 - BFD agenda posted

Hi Jeff, We'd also like 10-15 to present https://datatracker.ietf.org/doc/draft-merciaz-idr-bgp-bfd-strict-mode/ The presenter is Mercia Zheng. Thanks, Acee On 3/12/19, 8:56 AM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: Working Group, We have a two hour session scheduled the

Re: BFD WG adoption for draft-haas-bfd-large-packets

choosing this message out of a mixed thread to give a reply. > So, not all of this is targeted as a response to you, Acee. > > On Tue, Oct 23, 2018 at 04:30:52PM +0000, Acee Lindem (acee) wrote: >> Hi Albert, Les, >> >> I tend to agree with Les that BFD doesn’t seem like t

Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Albert, From: "Albert Fu (BLOOMBERG/ 120 PARK)" Reply-To: Albert Fu Date: Tuesday, October 23, 2018 at 12:45 PM To: "rtg-bfd@ietf.org" , "Les Ginsberg (ginsberg)" , Acee Lindem Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets Hi Acee, You are right in that this issue does

Re: BFD WG adoption for draft-haas-bfd-large-packets

From: "Albert Fu (BLOOMBERG/ 120 PARK)" Reply-To: Albert Fu Date: Tuesday, October 23, 2018 at 1:23 PM To: "Les Ginsberg (ginsberg)" , Acee Lindem , "rtg-bfd@ietf.org" Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets (* Resending smaller message *) Hi Acee, Please see

Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Albert, Resending due to a related problem – message was too big for IETF filter and I pruned part of the thread at the end. From: "Albert Fu (BLOOMBERG/ 120 PARK)" Reply-To: Albert Fu Date: Tuesday, October 23, 2018 at 12:45 PM To: "rtg-bfd@ietf.org" , "Les Ginsberg (ginsberg)" , Acee

Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Albert, Les, I tend to agree with Les that BFD doesn’t seem like the right protocol for this. Note that if you use OSPF as your IGP and flap the interface when the MTU changes, you’ll detect MTU mismatches immediately due to OSPF’s DB exchange MTU negotiation. Granted, control plane

Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote: > On Wed, Jul 04, 2018 at 03:20:42AM +, Reshad Rahman (rrahman) wrote: > > I am not 100% sure I understand the point being made. Is it a question

Re: Comments on Optimizing BFD Authentication

Mahesh – I believe these should be done as augmentations since draft-ietf-bfd-yang-13 has already been submitted to the IESG for publication. Thanks, Acee From: Rtg-bfd on behalf of Mahesh Jethanandani Date: Monday, April 2, 2018 at 12:06 AM

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

be schema mounted for use in an LNE 3) It may be schema mounted for use in a VRF I thought this was the case for all routing protocols. Regards, Reshad. On 2018-02-17, 1:31 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote: I thoug

Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09

On 2018-02-17, 3:56 AM, "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de> wrote: On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote: > * Design of the Data Model > > - Do

Re: The BFD WG has placed draft-spallagatti-bfd-vxlan in state "Call For Adoption By WG Issued"

Hi Jeff, I finally read this draft and support WG adoption (even though I’m NOT a fan of VXLAN, I realize it is a popular deployment scenario). Thanks, Acee On 1/3/18, 10:45 AM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: Working

Re: draft-nitish-vrrp-bfd

Hi Nitish, Irrespective of any IPR discussions, BFD is inherently a P2P protocol and, consequently, I would vote for P2P peer table. Thanks, Acee From: rtgwg > on behalf of "Nitish Gupta (nitisgup)"

Re: I-D Action: draft-ietf-bfd-yang-06.txt

Sigh, I mean “why don’t you add ‘enabled’…" On 7/31/17, 2:56 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote: >Hi Mahesh, > >On 7/31/17, 12:42 AM, "Mahesh Jethanandani" <mjethanand...@gmail.com> >wrote: > >>Yingzhen, >> >>Ove

Re: I-D Action: draft-ietf-bfd-yang-06.txt

le to >provide an example. > >Regards, >Reshad. > > > >On 2017-07-27, 10:34 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote: > >>Hi Reshad, >> >>Ok - I see now. I was looking at the wrong -base-cfg-parms groupings. >>Fewer similar g

Re: I-D Action: draft-ietf-bfd-yang-06.txt

ers. > >Let me get rid of the client module and have everything in the types >module. > >I am not sure why you’re not seeing something different. > >Regards, >Reshad. > > > >On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote: > >

Re: I-D Action: draft-ietf-bfd-yang-06.txt

isn’t pushed to GitHub yet. This version https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd-t ypes.yang only has the enabled leaf. Thanks, Acee > >Regards, >Reshad. > > > >On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" <a...@cisco.com

Re: I-D Action: draft-ietf-bfd-yang-06.txt

y also want the multiplier/timer. The bfd-client-ext-cfg-parms grouping should use bfd-types:bfd-grouping-common-cfg-parms rather than bfd-types:bfd-client-base-cfg-parms - no? This would be more obvious w/o the client module. Thanks, Acee > >Regards, >Reshad. > > > >On 20

Re: I-D Action: draft-ietf-bfd-yang-06.txt

Hi Reshad, Why do we need a new YANG model for clients? Why can’t they just use ietf-bfd-types.yang? I’d like to avoid the unnecessary levels of indirection. In fact, it looks wrong to me since the grouping bfd-client-ext-cfg-parms uses the grouping bfd-grouping-base-cfg-parms which only contains

Re: IETF OSPF YANG and BFD Configuration

On 6/20/17, 1:50 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com> wrote: > >> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee) <a...@cisco.com> wrote: >> >> Hi Jeff, >> >> On 6/20/17, 10:58 AM, "Jeffrey Haas" <jh...@pfrc.

Re: IETF OSPF YANG and BFD Configuration

Hi Jeff, On 6/20/17, 10:58 AM, "Jeffrey Haas" wrote: >Les, > >On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg) wrote: >> > Different protocols have different survivability requirements. An >>IGP may >> > very well want sub-second timers, potentially for repair

Re: IETF OSPF YANG and BFD Configuration

Jeff, On 6/20/17, 10:20 AM, "Jeffrey Haas" <jh...@pfrc.org> wrote: >Acee, > >On Mon, Jun 19, 2017 at 10:10:43PM +, Acee Lindem (acee) wrote: >> I don’t really feel there is a strong requirement to support different >> timers values per protocol even

Re: IETF OSPF YANG and BFD Configuration

Hi Jeff, Mahesh, See a couple inlines. On 6/20/17, 10:16 AM, "Jeffrey Haas" wrote: >Mahesh, > >On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote: >> > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas wrote: >> > Where we run into some issues are

Re: IETF OSPF YANG and BFD Configuration

ation parms. We concluded that the BFD >>authentication parms were better off in BFD. And once we did that, the >>timer/multiplier followed >> >> I may not recall all the details/discussons, but I do recall that we >>went back and forth on this and it took some time to make

Re: WG adoption poll on draft-nitish-vrrp-bfd-04

While I originally didn’t think this was necessary, I can see the use case and support RTG WG adoption. Thanks, Acee From: rtgwg > on behalf of Chris Bowers > Date: Thursday, September 29, 2016

Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt

Chris, Mahesh, I agree with this characterization of the draft and believe that, if adopted, it belongs in the RTG WG. Thanks, Acee From: rtgwg > on behalf of Chris Bowers > Date: Monday,