Subject: BFD Hold Down Timers

From: "Bart Wensley" <[email-masked]>
Date: Thu, 21 Jan 2010 12:51:02 -0500

Hi,

We have been asked to support a hold down timer in our BFD
implementation. The purpose of the timer would be to delay state
change notifications (for a BFD session going from down to up)
for the duration of the timer (which could be on the order of
minutes). This would delay the re-establishment of a routing
adjacency (e.g. BGP, OSPF) until the hold down timer has
expired. From a search on the web, I see that Juniper has
implemented this in JUNOS 8.5 and I believe this is one reason 
we are being asked to support it.

This would be pretty straight forward, except we have also been
told that the hold down timer should have the following side
effects on BFD: 

1. If the hold time timer is configured and a BFD session goes
   into the admin down state, any clients (e.g. BGP, OSPF) should
   treat this as the down state and break their adjacencies. This
   is in direct conflict with draft-ietf-bfd-generic-05, section
   4.1:
     If the session state on either the local or remote system 
     (if known) is AdminDown, BFD has been administratively 
     disabled, and the establishment of a control protocol 
     adjacency MUST be allowed.

2. If the hold down timer is configured, prevent the
   establishment of the routing adjacency until the BFD session
   comes up. The implication is that if the hold down timer is 
   not configured, the routing adjacency should be allowed before
   the BFD session comes up. From looking through discussions 
   this mailing list, it seems there is some confusion as to 
   which is the correct behaviour, although I don't think using 
   hold down timer configuration is the right way to resolve it.

This is third hand information, so I apologize if it is
incorrect. I have searched the BFD drafts and this mailing list
and I have not found any discussion of a hold down timer having
these side effects.

Can someone from Juniper confirm whether JUNOS behaves this way
when hold down timers are used? If so: 
- Is this behaviour documented anywhere?
- Will this be added to one of the BFD drafts?

I'm also curious about whether any other vendors have implemented
hold down timers with (or without) these side effects. If vendors
are modifying their BFD implementations like this, I can see it
making inter-vendor interop difficult if the behaviour is not
standardized.

Thanks,

Bart Wensley
Versatile Services Engine Software Design
Nortel
[email-masked]

---

From: Dave Katz <[email-masked]>
Date: Thu, 21 Jan 2010 11:25:26 -0700

>     adjacency MUST be allowed.

The history of AdminDown state and its implications was somewhat fluid  
through the refinement of BFD, but the semantics we finally settled on  
were "We're not running BFD rignt now;  please act as if nothing is  
wrong."

The behavior you're looking for can be accommodated by holding down in  
Down state rather than AdminDown--see the base spec, section 6.8.18.   
If you're in Down rather than AdminDown state, you can stay there as  
long as you like, and the session will stay down but the session will  
still be trading packets, and so the state will hang around (and the  
protocols will stay down.)

>   hold down timer configuration is the right way to resolve it.

The concept of a hold down timer is outside of the spec, so without a  
clear definition of what that means (in particular, what state you're  
holding down in) you can't talk about what the expected behavior would  
be.  However, if you're holding down in Down state, the behavior seems  
clear (at least to me):

    Therefore, the establishment of control protocol adjacencies SHOULD
    be blocked if both systems are willing to establish a BFD session  
but
    a BFD session cannot be established.

Exchanging BFD packets constitutes "both systems are willing to  
establish a BFD session", and one side not budging from Down state  
constitutes "cannot be established".

> - Will this be added to one of the BFD drafts?

It would be inappropriate to talk about our particular implementation  
on this list (particularly if it has been overtaken by the specs ;-) )  
but there should be no interoperability issues.

> making inter-vendor interop difficult if the behaviour is not

I don't believe that there are any interoperability issues if the  
specs are followed.

--Dave

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 21 Jan 2010 10:37:30 -0800

Hi Bart,

   See NB> below...

On 1/21/10 9:51 AM, "Bart Wensley" <[email-masked]> wrote:

Hi,

1. If the hold time timer is configured and a BFD session goes
   into the admin down state, any clients (e.g. BGP, OSPF) should
   treat this as the down state and break their adjacencies.

NB> I am not sure what is the relation between the hold-down timer and "bfd going down".
As per your description above, the hold-down is related to bfd coming up and informing clients.

  This

2. If the hold down timer is configured, prevent the
   establishment of the routing adjacency until the BFD session
   comes up. The implication is that if the hold down timer is
   not configured, the routing adjacency should be allowed before
   the BFD session comes up.
   From looking through discussions
   this mailing list, it seems there is some confusion as to
   which is the correct behaviour, although I don't think using
   hold down timer configuration is the right way to resolve it.

NB> There was some config for isis (see draft-ietf-isis-bfd-tlv). Besides that...I don't remember any
definite conclusion on what is the right way.

 *   Is this behaviour documented anywhere?

     NB> I will refrain from commenting on vendor specific behavior on a public forum.
There is some documentation available publicly on JNPR website.

NB> Not that I am aware of.

Thanks
Nitin

---

From: "Bart Wensley" <[email-masked]>
Date: Thu, 21 Jan 2010 14:31:10 -0500

Nitin,

> coming up and informing clients.

There is no relation between the hold-down timer and this
non-compliant behaviour for the AdminDown state. I just wanted to
confirm that this wasn't proper behaviour. We will stick with
the AdminDown behaviour Dave Katz described:
  "We're not running BFD right now;  please act as if nothing is
  wrong."

Bart

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 1:38 PM
To: Wensley, Bart (CAR:SI23); [email-masked]
Subject: Re: BFD Hold Down Timers

Hi Bart,

   See NB> below...

Hi,

NB> I am not sure what is the relation between the hold-down timer and
"bfd going down".
As per your description above, the hold-down is related to bfd coming up
and informing clients.

  This

NB> There was some config for isis (see draft-ietf-isis-bfd-tlv).
Besides that...I don't remember any
definite conclusion on what is the right way.

     NB> I will refrain from commenting on vendor specific behavior on a
public forum.
There is some documentation available publicly on JNPR website.

Thanks
Nitin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 21 Jan 2010 15:51:22 -0800

The notion of requiring BFD session to be UP before establishing the BFD
client adjacency depends upon knowledge that both sides have been
configured to support BFD. Absent signalling extensions in the BFD
client (such as those defined in draft-ietf-isis-bfd-tlv) this knowledge
is not available. Without this knowledge inconsistent behavior can be
seen. For example, consider the following sequences:

Sequence #1:
IGP is configured on A
IGP is configured on B
A-B IGP adjacency comes up
BFD is configured on A

Sequence #2:
BFD is configured on A
IGP is configured on A
IGP is configured on B
A-B IGP adjacency does NOT come up

The state of forwarding is identical in both cases, but the state of the
IGP adjacency is not.

For this reason I do not find the suggested feature appealing.

I would also point out that the motivation for draft-ietf-isis-bfd-tlv
was issues that arise out of the lack of fate sharing between the BFD
packets and IS-IS PDUs. These issues do not arise in (for example) the
case of BFD and OSPFv2. Absent those issues, the IS-IS signalling
extensions would not have been proposed.

YMMV

   Les

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bart Wensley
> Sent: Thursday, January 21, 2010 11:31 AM
> To: Nitin Bahadur
> Cc: [email-masked]; Dave Katz
> Subject: RE: BFD Hold Down Timers
> 
> Nitin,
>

---

From: Dave Katz <[email-masked]>
Date: Thu, 21 Jan 2010 17:54:05 -0700

Well, the spec is careful to say that you need some way of knowing  
that BFD is in play on both ends or not.

Realistically, the *vast* majority of BFD sessions will be managed at  
both ends by the same party, and so the a priori knowledge of whether  
or not BFD is desired is not at issue.

For that matter, even when there are different parties, one does not  
bring up IGPs willy-nilly with any promiscuous router that flounces  
along.  ;-)

As for the example, as always, misconfigurations are problematic, and  
this is certainly not the worst thing that happens whens somebody  
screws up a config.  More plausibly, things will work the same way in  
both examples if BFD is actually being configured on both ends, and  
the end state is identical even if you choose the maximally pessimal  
ordering (say, sequence #2, but configure BFD on B at the very end...)

--Dave

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 22 Jan 2010 08:46:11 -0800

Dave -

> From: Dave Katz [mailto:[email-masked]]
> Sent: Thursday, January 21, 2010 4:54 PM
> To: Les Ginsberg (ginsberg)
> Cc: Bart Wensley; Nitin Bahadur; [email-masked]

I have no problem w the spec in this regard.

> ordering (say, sequence #2, but configure BFD on B at the very end...)

The more substantive point in my post was that the motivation for
wanting to prevent the IGP adjacency from coming up BEFORE BFD session
is established is the lack of fate sharing of the IGP PDUs/packets and
the BFD packets. In the case of IS-IS this lack of fate sharing has been
demonstrated to cause problems in the real world - hence
draft-ietf-isis-bfd-tlv. There are other cases to which the same issues
are applicable (e.g. OSPFv3 support for IPv4) - but I am not aware of
issues in cases where the same network layer protocol is used for IGP
and BFD (e.g. OSPFv2).

Given the widespread deployment of BFD support which does NOT require
the BFD session to be up prior to IGP adjacency establishment, the
introduction of implementations which require this in the absence of IGP
signalling of BFD support does cause interoperability problems.

   Les

> >> As per your description above, the hold-down is related to bfd
> coming
> >> up
> >> and informing clients.
> >>
> >>  This
> >>     NB> I will refrain from commenting on vendor specific behavior
> on
> >> a
> >> public forum.