Subject: State machine diagram & alarm generation

From: [email-masked]
Date: Sat, 12 Feb 2005 08:38:37 -0000

Dave, Jeff,

Sorry for the delay in responding to your comments. 

First of all, thank you for taking the time to clarify the state machine. Do you think it would be worthwhile adding a state machine diagram to the base document to provide clarification? I think this would help anyone reading the draft for the first time understand the state transitions without having to methodically work through the If/Then statements.

Regarding my comments about looping through the Failing, Down, Init states whilst a unidirectional failure exists, my concern is from an alarm perspective. If an implementation is configured to raise an alarm upon entering the Failing state, then it may continuously send out alarms as it loops through the various states. If we had a tunnel LSP failure that was carrying thousands of PWs, each running VCCV BFD, then this would be a lot of unnecessary alarms to deal with. Obviously this could be avoided by requiring that the implementation only raises an alarm when transitioning from the up state to the Failing state (not Init to Failing state). Do you know how alarms are raised in current BFD implementations?

Also, in the MPLS case an alarm should only be raised if an FDI/AIS hasn't been received from an underlying server layer, Therefore, on entering the Failing defect state (if this is indeed when an alarm is raised) then a node should wait a couple of seconds to see if it gets an FDI before raising an alarm.

The issue of raising alarms is not covered in the current draft, other than saying "The exact action taken when the session state changes is outside the scope of this specification, though it is expected that this state change (particularly to and from Up state) is reported to other components of the system." Perhaps this is seen as an implementation issue? However, in a multivendor environment, alarms must be generated in a consistent manner across different boxes. If there is no intention to address the issue of when alarms should be raised within the current BFD drafts, are there plans to cover this issue elsewhere in a separate draft, e.g. something like a BFD best practices draft?

Thanks,
Richard

> -----Original Message-----
> From: Dave Katz [mailto:[email-masked]]
> Sent: 02 February 2005 22:40
> To: Jeffrey Haas
> Cc: [email-masked]; [email-masked]; Spencer,R,Richard,XDE R
> Subject: Re: Transition from failing state
> 
> 
> 
> On Feb 2, 2005, at 12:52 PM, Jeffrey Haas wrote:
> 
> > On Wed, Feb 02, 2005 at 12:29:23PM -0000, 
> [email-masked] wrote:
> >> Therefore, it seems to me that whilst A->B connectivity is 
> lost, Node 
> >> B will remain permanently in the Failing state, whilst Node A will 
> >> loop continuously though the Failing, Down, Init states. Is this 
> >> correct or am I missing something?
> >
> > Correct.  By analogy, this isn't much worse (given the 
> fallback to a 1
> > second timer for sending packets) than something like BGP 
> transitioning
> > through it's statemachine.
> >
> > It is up to an implementation whether it wants to leave a 
> BFD instance
> > running on a session that is otherwise down for a long 
> period of time.
> > For example, if BFD was supporting OSPF, then one could presume an
> > implementation would delete the BFD instance for a given 
> pair of peers
> > until the OSPF hello protocol noticed that the session was up again.
> 
> Yep, in the case of one-way connectivity, this is what will happen.  
> Given that the only "interesting" transition is Up->Failing (or 
> perhaps, in limited cases, Init->Up) the machinations of the state 
> machine hurt nobody.  One could indeed claim that they are 
> useful;  in 
> particular, timing out of Init state carries useful semantics.
> 
> >
> >> Also, the only exit criteria described for the Failing state is as 
> >> follows:
> >>
> >> Else if bfd.SessionState is Failing
> >>    If I Hear You is zero, set bfd.SessionState to Down
> >>
> >> What happens if just after entering the Failing state (due to 
> >> detection timeout as in the previous example), 
> connectivity A->B is 
> >> restored and Node B receives a BFD packet from node A with 
> a I Hear 
> >> You of nonzero? This would occur if node A (whilst still in the Up 
> >> state) sends a BFD packet to node B before it receives the BFD 
> >> failure notification from Node B (with H bit set to 0 and 
> Diag set to 
> >> 1).
> >
> > This isn't any different than B saying that it wishes to tear the 
> > connection
> > down.  The state machine could go through the usual motions of 
> > restoring
> > the connection, but B would do so starting from the failing 
> state and 
> > would
> > have to wait for A to acknowledge it.
> 
> Indeed.  The intent of the state machine is to make sure both sides 
> *always* know that the session has failed.  If it takes a couple of 
> extra packets to get the session going again in some 
> relatively unusual 
> instances, that's no big deal (and not worth the complexity to try to 
> optimize it out.)
> 
> --Dave
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Feb 2005 12:20:49 -0500

Richard,

On Sat, Feb 12, 2005 at 08:38:37AM -0000, [email-masked] wrote:
> First of all, thank you for taking the time to clarify the state
> machine. Do you think it would be worthwhile adding a state machine
> diagram to the base document to provide clarification?

I'll let the authors answer, but it sounds useful to me. :-)

> Regarding my comments about looping through the Failing, Down,
> Init states whilst a unidirectional failure exists, my concern is
> from an alarm perspective.

The proposed MIB had covered this particular issue.  The MIB authors
are waiting on the base specification authors before they republish.

(This is a reminder to everyone that the time left to submit drafts
prior to the next IETF is rapdily dwindling.)

>From the MIB:

bfdSessUp NOTIFICATION-TYPE
   OBJECTS     { bfdSessDiag, -- low range value
                 bfdSessDiag  -- high range value
   }
   STATUS      current
   DESCRIPTION
       "This notification is generated when the
        bfdSessState object for one or more contiguous
        entries in bfdSessTable are about to enter the up(2)
        state from some other state. The included values of
        bfdSessDiag MUST both be set equal to this
        new state (i.e: up(1)).  The two instances of 
        bfdSessDiag in this notification indicate the range 
        of indexes that are affected.  Note that all the indexes 
        of the two ends of the range can be derived from the
        instance identifiers of these two objects.  For
        cases where a contiguous range of sessions
        have transitioned into the up(1) state at roughly
        the same time, the device SHOULD issue a single
        notification for each range of contiguous indexes in
        an effort to minimize the emission of a large number
        of notifications.  If a notification has to be
        issued for just a single bfdSessEntry, then
        the instance identifier (and values) of the two
        bfdSessDiag objects MUST be the identical."
   ::= { bfdNotifications 1 }

bfdSessDown NOTIFICATION-TYPE
   OBJECTS     { bfdSessDiag, -- low range value
                 bfdSessDiag  -- high range value
   }
   STATUS      current
   DESCRIPTION
       "This notification is generated when the
        bfdSessState object for one or more contiguous
        entries in bfdSessTable are about to enter the down(4)
        or adminDown(5) states from some other state. The included 
        values of bfdSessDiag MUST both be set equal to this
        new state (i.e: down(4) or adminDown(5)).  The two instances 
        of bfdSessDiag in this notification indicate the range 
        of indexes that are affected.  Note that all the indexes 
        of the two ends of the range can be derived from the
        instance identifiers of these two objects.  For
        cases where a contiguous range of sessions
        have transitioned into the down(4) or adminDown(5) states 
        at roughly the same time, the device SHOULD issue a single
        notification for each range of contiguous indexes in
        an effort to minimize the emission of a large number
        of notifications.  If a notification has to be
        issued for just a single bfdSessEntry, then
        the instance identifier (and values) of the two
        bfdSessDiag objects MUST be the identical."
   ::= { bfdNotifications 2 }

> If an implementation is configured to
> raise an alarm upon entering the Failing state, then it may
> continuously send out alarms as it loops through the various states.

The events in BFD that are of primary use are the transitions in
and out of the up state.  While an implementation might have some
valid use for transitions amongst other states, I suspect that
most wont.  To provide a similar example, the SNMP notification
events for BGP's state machine theoretically cover any state transition
from a higher numbered state to a lower numbered state.  In practice,
this just generates unnecessary events.  Several implementations will
only send these events when a transition occurs out of Established.

> However, in a multivendor environment,
> alarms must be generated in a consistent manner across different
> boxes. If there is no intention to address the issue of when alarms
> should be raised within the current BFD drafts, are there plans to
> cover this issue elsewhere in a separate draft, e.g. something like
> a BFD best practices draft?

Do you think that addressing this outside the MIB is appropriate?  If
so, perhaps you could propose some text.

-- 
Jeff Haas 
NextHop Technologies

---

From: Dave Katz <[email-masked]>
Date: Tue, 15 Feb 2005 15:36:21 -0800

> I'll let the authors answer, but it sounds useful to me. :-)

I can try to add some ASCII art, but it would probably be more 
straightforward to just add a brief paragraph describing the state 
machine, which is really quite simple.  I'll give that a shot first.  
(Working on the next rev...)

--Dave