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

["Palanivelan A (apvelan)" <[e-mail]>]

 

We see BFD to be serving what it is meant to and the wide
implementations of this technology points to its acceptance. 

If we have to pick at the areas that are little grey, BFD for routing
protocols with GR comes as one of them.

 

Though the success of BFd with GR depend on the system design and that
there can be different ways of addressing the issue in line with the
design, 

This draft intended to provide a common solution that can be adopted.
This was originally intended for "standards track".

 

But this working group, within its rights felt that BFD would not look
for such an extension and that this need not be considered for a
standards track and 

I am certainly not debating on that. The independent reviewers however
proposed that this draft can be recorded for future and hence were
willing to

consider this draft for  a "Historic" status.The revisions to this draft
were all based on these review comments.

 

I hope this clarifies the intend of the draft and also the status of
this draft as on date. 

 

I guess, for someone who is facing this issue and looking  at a
solution, this draft gives an option (not the only one though)  to
address and that is my bottom point.

 

Thanks and Regards,

A.Palanivelan

 

From: Dave Katz [mailto:[e-mail]] 
Sent: Wednesday, October 27, 2010 10:49 PM
To: Palanivelan A (apvelan)
Cc: rtg-bfd WG; Santosh P K
Subject: Re: draft-palanivelan-bfd-v2-gr-08

 

I somehow seem to have missed the ongoing revision of this draft.

 

To underscore what Santosh says, I believe that GR interactions can be
dealt with in an informational BCP, without any modification of the base
spec.  RFC 5882 has a bunch of verbiage to try to address exactly this
scenario.

 

 

But to the details:

 

I don't see how there is *any* mechanism that can deal with unplanned
restart if the BFD session can't stay up long enough for the restarting
system to start sending BFD packets again.  The non-restarting system
fundamentally cannot differentiate between this and a crashed neighbor;
it must assume that the path has failed and do whatever it needs to
(take down a routing protocol adjacency, for example.)  Unless I'm
missing something, this is an unavoidable side effect of fast failure
detection, and the only way to deal with it is to make the behavior of
the dependent control protocol implementations less onerous when the
topology changes (which is frankly what folks should have done instead
of inventing GR, which in my opinion is an awful kludge).

 

If the BFD session can stay up long enough for the restarting system to
send BFD packets again, and the control protocol has GR capabilities,
the second paragraph of section 3.3 of RFC 5882 describes in general
terms what to do.  In particular, the mythical adaptation layer
described in the RFC can detect the fact that the session is actively
being reestablished (by virtue of the receipt of BFD packets from the
restarting system) and apply hysteresis to the BFD session flap.  This
will give the restarted control protocol sufficient time to signal the
GR and avoid perturbation in that layer.

 

The Diag field is intended to be *informational* only, that is, a
write-only field as far as the BFD state machine is concerned.  There is
currently *no* place in the spec where a receiving system uses this
field as part of the BFD state machine.  Using it to signal within the
protocol is outside of the architectural thinking (which, admittedly, is
not explicitly documented).  But beyond that, the Diag field is
"fragile" within the protocol;  it is easily overwritten under various
conditions based on the existing spec, and attempting to preserve its
value for signaling would require constraining the operation of the
sender.  This is hinted at in section 6.8.17 in RFC 5880 when describing
concatenated paths, for example.

 

I see no value in signaling the GR timers in the protocol;  if a
restarting system can trigger this mechanism by sending Diag 9, it could
also do so by simply cranking up the transmit and receive intervals to
whatever values it desires.  For planned restart, this is all that is
necessary (and this can be done cleanly at that time.)  For unplanned
restart, at some level it doesn't matter;  by the time you can signal
anything from the restarted system, you can run BFD at full speed, or
whatever rate you would like to signal at that time.

 

All the stuff about broadband and large fan-out seems to be beside the
point, an excuse for poor system design, and doesn't seem to add
anything to the argument.  A system that is fielding DHCP requests but
is ignoring fundamental connectivity is broken in any case (and as
Santosh points out, no mechanism in the protocol is going to help you if
the packets can't be sent and received anyhow.)  Doing successful
unplanned GR has certain requirements, among them ensuring that the
protocols involved can actually talk, and the particular example is not
a particularly good one, IMHO.

 

What am I missing?

 

--Dave

 

 

On Oct 27, 2010, at 9:10 AM, Santosh P K wrote:





Hello Palanivelan,
     I have couple of doubts on this draft. Under section 6.2. Remote
Neighbor Restart and Recovery, it's mentioned that.
 
   "When the set of systems had their BFD sessions established, with GR
   support as described in this document, when the remote neighbor
   restarts it will set the BFD diagnostics field to a value of 9
   (Neighbor Restarting) in the control packet to its neighbor (local
   system)."
 
  This draft is trying to address the unplanned restart of protocols
using BFD, as the planned outage is handled today anyway. 
 
1.    How BFD would determine that protocol using BFD has gone for
graceful restart (in case of unplanned outage), to send BFD packet with
BFD diagnostics field set to 9?  
2.    If BFD can determine that protocol using BFD has restarted with GR
enabled and that's not planned outage then can't we increase BFD session
timers instead of having MyRestartInterval and yourRestartInterval
fields?
3.    In case we miss out initial couple of BFD packets with diagnostics
field set to 9 due to BFD not having enough CPU slice on restarting
router, then at local router (helper) are we not bringing down the
session? 

 

....................................

Thanks and regards
Santosh P K