Subject: RE: draft-palanivelan-bfd-v2-gr-08

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Tue, 2 Nov 2010 10:34:12 +0530

To get started on this draft,
This draft documents two issues with BFD and suggests a single solution
to address both.

1) The first one is about the BFD failures during GRs in Planned
Restarts, when co-existing with other Process intensive applications.
This draft explains on such an issue, when scaled broadband
configurations co-exist in the system that has routing protocols enabled
with GR and BFD.
Here, though the remote system (restarter) signals about the planned
restart and the local system does get to know about the restart, during
the restart,
the local system still looks for BFD packets at the pre-negotiated timer
values. Now, we have the tied routing protocol adjusting its timers to
wait for an extended time (as negotiated for GR),but BFD still waiting
for the originally negotiated timer values.

Though this works fine in simple, less intensive environment, in a
process intensive scenario, wherein I had given an example of BB configs
in the draft, BFD may miss the packets, declare the remote neighbor down
to the tied application (routing protocol) and hence bringing down the
adjacency. This is also true for a system that has deep-packet
inspection application like NBAR enabled in the system. I Have seen this
in deployments with the products of the top-2 datacom companies and
hence feel there is every reason to document and address this.

For BFD to survive in such a scenario, The implementers look to use
Flags/Timers or "Flags and Timers" to manage BFD timer values. Here
again, though the timers are managed, there is no way of indicating at
the local system that, the remote system is (gracefully) restarting. The
local system anyway knows that the remote peer is restarting, why not
have it in the diag field? And let that be set by the remote peer and
why not have a bfd state indicating this state?.

These two can be done within the existing framework of bfd (with
additions to bfd diag and state). I thought negotiating the GR timers,
between the peer makes it a much more standardized way of doing it and
hence suggested the same in this draft.

Not many would disagree to what I have said here, but whether this can
be within the framework or not can be debated and also on whether this
can be suggested as a BCP or otherwise.

2) The second one is about unplanned restarts and I see this working
group is pretty much convinced that this problem won't be solved with
what is suggested in this draft.
Though I do think this extension would help solve the problem, I do not
have it implemented anywhere to prove that it actually does.

Appreciate your comments on my thoughts.

Regards,
A. Palanivelan

-----Original Message-----
From: Dave Katz [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 10:34 PM
To: Palanivelan A (apvelan)
Cc: rtg-bfd WG
Subject: Re: draft-palanivelan-bfd-v2-gr-08

On Oct 29, 2010, at 12:33 AM, Palanivelan A (apvelan) wrote:

> My experience with the process is not much to talk about but let me
> confirm it is not easy even to get it to Historic :).
> I loved to be part of working group in working through this document
and
> unfortunately it did not happen. 
> 
> Any good suggestions in how to go about, I would love to take it Dave.

If the group thinks it to be worthwhile (I personally think it would
be), it would be quite valuable to discuss the GR issues on this list,
particularly any that you've run across that we did not foresee, with
the goal of producing a BCP that more thoroughly documents how the
various pieces of BFD and the control protocols might be pulled together
to achieve GR.  If you feel that our technical evaluation of your
proposal is in error, or that the existing mechanisms are insufficient
and yours adds value, that would be extremely helpful as well.

Thanks,

--Dave

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 1 Nov 2010 23:33:45 -0700

Can u solve the first problem by bringing the BFD session administratively
down on the router that is restarting? On an admin down, the remote peer
should not affect the BFD clients...and the sessions also won't time out.

Thanks
Nitin

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 2 Nov 2010 12:19:46 -0400

+1

Regards,
Jeff  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
Sent: Monday, November 01, 2010 23:34
To: Palanivelan A (apvelan); Dave Katz
Cc: rtg-bfd WG
Subject: Re: draft-palanivelan-bfd-v2-gr-08
Importance: High

Thanks
Nitin

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Wed, 3 Nov 2010 12:34:28 +0530

Nitin and Jeff,

What we are looking at with the solution that you suggested is, turning
off your feature so that it doesn't affect the tied application.
For me, this is more a workaround/ temporary fix to the issue and why do
you want to back-off than actually attacking the issue and solving it.

Again, this doesn't scale too. When the restarter has say about more bfd
sessions/neighbors, we will be adding more cycles to the restarter this
way.
If you look at any of the Graceful restart mechanisms, always the
helpers do more work than the restarter (for the simple reason, in a
scaled scenario, the helper gotto take care of one of its session and if
this is on the restarter, it got to take care for as many connected
neighbors).

Ideally since we have the diag fields available in bfd, we infact should
look to leverage it in managing better and hence have a complete
control.

Thanks and Regards,
A.Palanivelan

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Tuesday, November 02, 2010 9:50 PM
To: Nitin Bahadur; Palanivelan A (apvelan); Dave Katz
Cc: rtg-bfd WG
Subject: RE: draft-palanivelan-bfd-v2-gr-08

+1

Regards,
Jeff  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nitin Bahadur
Sent: Monday, November 01, 2010 23:34
To: Palanivelan A (apvelan); Dave Katz
Cc: rtg-bfd WG
Subject: Re: draft-palanivelan-bfd-v2-gr-08
Importance: High

Can u solve the first problem by bringing the BFD session
administratively
down on the router that is restarting? On an admin down, the remote peer
should not affect the BFD clients...and the sessions also won't time
out.

Thanks
Nitin