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

From: Santosh P K <[email-masked]>
Date: Wed, 27 Oct 2010 20:40:42 +0530

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

---

From: Dave Katz <[email-masked]>
Date: Wed, 27 Oct 2010 11:18:49 -0600

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
>    system).”
> 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?

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Thu, 28 Oct 2010 18:31:30 +0530

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:[email-masked]] 
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

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

Hello Palanivelan,
     I have couple of doubts on this draft. Under section 6.2. Remote
Neighbor Restart and Recovery, it's mentioned that.

  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

---

From: Dave Katz <[email-masked]>
Date: Thu, 28 Oct 2010 11:11:15 -0600

On Oct 28, 2010, at 7:01 AM, Palanivelan A (apvelan) wrote:

>  
> 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.

If there is a need to describe how to do GR more explicitly, a BCP would be the ideal vehicle, as an implementation that follows it would continue to be interoperable with other implementations that don't do the function.  If an implementor is looking for a solution, one that does not require modification of the protocol is actually a feasible option, whereas modifying the protocol is not (at least not if interoperability is a requirement, at least for a significant time.)

But it appears that the proposed change simply doesn't work for the primary interesting case (unscheduled restart with short detection times) because, as far as I can tell, *nothing* can solve that problem, and it also doesn't fix the issue with poor scheduling, which in any case is an implementation problem that cannot be fixed by the protocol.

>  
> 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 as far as I can tell, it doesn't actually do what it purports to do, and thus modifies the protocol to no useful end.

>  
> 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 don't think that there is any mechanism for an ID to achieve Historic status (which is a misnomer in this case), though I'm not an IETF process expert;  IDs are purged after six months.  If I understand correctly, Historic status is used to classify older RFCs whose technology has been abandoned or otherwise overtaken by events.  I don't believe there is any mechanism by which this draft can be archived within the IETF.

As far as I can tell, the draft was last discussed in public in July of 2009 (which I suppose is why I was confused about how it came to have six more revisions since then) and the only comments boiled down to "this isn't necessary".  When it popped up again on the list yesterday, I took a harder look and came to the conclusion that it is not only unnecessary, but won't solve any problems that aren't already solvable by the RFCs.

I appreciate the fact that you're interested enough in the problem to take the time to write and edit a draft, and I certainly don't want to dissuade you.  But I would urge you to put that energy into a draft that clarifies the functional and implementation issues with GR in a way that operates within the existing standards track documents;  such a draft could end up as an RFC and suitably recorded.

--Dave

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 28 Oct 2010 15:10:05 -0400

On Thu, Oct 28, 2010 at 1:11 PM, Dave Katz <[email-masked]> wrote:
>...
> I don't think that there is any mechanism for an ID to achieve Historic
> status (which is a misnomer in this case), though I'm not an IETF process
> expert;  IDs are purged after six months.  If I understand correctly,
> Historic status is used to classify older RFCs whose technology has been
> abandoned or otherwise overtaken by events.  I don't believe there is any
> mechanism by which this draft can be archived within the IETF.

A number of RFCs have been issued originally as Historic. The most
recent three were RFC 6037, RFC 5806, and RFC 5773 for which the
official announcements are here:

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8514&tid=1288292436
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=7673&tid=1288292698
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=7505&tid=1288292756

Donald

---

From: Dave Katz <[email-masked]>
Date: Thu, 28 Oct 2010 13:44:48 -0600

I stand corrected.

I assume that there is at least some hurdle to cross to publish a Historic RFC;  otherwise I could publish my grocery lists or something.  ;-)

--Dave

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 28 Oct 2010 16:00:58 -0400

Who knows, I've never done it. For all I know it may be more difficult
than publishing a standards track document :-)

Thanks,
Donald

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Fri, 29 Oct 2010 12:03:57 +0530

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.

Regards,
A.Palanivelan

-----Original Message-----
From: Dave Katz [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 1:15 AM
To: Donald Eastlake
Cc: rtg-bfd WG; Palanivelan A (apvelan)
Subject: Re: draft-palanivelan-bfd-v2-gr-08

I stand corrected.

I assume that there is at least some hurdle to cross to publish a
Historic RFC;  otherwise I could publish my grocery lists or something.
;-)

--Dave

> official announcements are here:
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=8514&tid=1288
292436
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=7673&tid=1288
292698
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=7505&tid=1288
292756

---

From: Dave Katz <[email-masked]>
Date: Fri, 29 Oct 2010 11:03:56 -0600

> 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: "Palanivelan A (apvelan)" <[email-masked]>
Date: Sat, 30 Oct 2010 12:31:43 +0530

Hi Dave,

Thanks for that encouraging mail. Let me do it as per your suggestion
and analyzing and discussing the gaps in depth definitely helps.

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

> 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