Subject: draft-ietf-bfd-generic-05, adjacency establishment (section 4.1, 10.1.1)

From: "Johannes Resch" <[email-masked]>
Date: Fri, 11 Dec 2009 15:14:23 +0100 (CET)

Hi all,

I'm currently seeing a problem that might be an interop issue between two
vendors concerning the adjacency formation using BFD with OSPF as client.

Trying to determine which side behaves "correct", I've got the impression
that the wording in draft-ietf-bfd-generic-05, section 4.1 and/or 10.1.1
is not quite specific to define the following points:

1. when an implementation should actively start sending BFD protocol
packets during the multiple steps of IGP adjacency formation
2. when an implementation should accept BFD protocol traffic from an IGP
neighbor during the multiple steps of IGP adjacency formation

The specific problem I'm seeing is that vendor1 already triggers BFD in
2-way phase, while vendor2 will neither send nor accept BFD traffic in
that phase.
The result is that the OSPF state on vendor1 device will not proceed to
exstart/exchange state and remains in "BFDdown" state forever, while
vendor2 toggles between exstart and down (after reaching retransmission
timeouts for DD packets)

Did I miss some other documents where these points are spelled out in a
more detailed fashion? Is this something that has been discussed before?

Best regards,
-jr

PS: I would also be particularly interested if Cisco folks could comment
on what behavior is correct from their POV..

---

From: Dave Katz <[email-masked]>
Date: Fri, 11 Dec 2009 09:21:39 -0800

It sounds as though the confusion is partly due to my less-than- 
adequate wordsmithing, and partly due to OSPF's unfortunate  
overloading of the term "adjacency", and partly due to vendor2 not  
thinking through the problem to be solved too thoroughly.

The intent is to trigger the BFD session as soon as the neighbor is  
discovered, which in the case of OSPF would be as soon as the first  
Hello is received from the neighbor.  The verbiage in 4.1 is  
attempting to describe (in the case of OSPF) blocking even advancing  
to 2way state until the BFD session comes up--the lack of BFD should  
leave the OSPF neighbor stuck in Init state, subject to the caveats  
therein.

The acceptance of BFD packets ought not to be ambiguous;  if one side  
hasn't turned on BFD yet, it's not going to receive the packets, and  
if it is attempting to bring up a session, it will.

I'll see if I can make an editorial change at this late date.

Sorry for the confusion,

--Dave

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 11 Dec 2009 23:57:27 -0800

The key issue in determining whether the IGP adjacency should be brought
up before or after the BFD session is whether the IGP knows the state of
BFD support both locally and on the neighbor. If BFD is either not
supported or not enabled on the neighbor then waiting on BFD will
prevent the IGP adjacency from coming up in situations where the
adjacency SHOULD come up. This point is discussed in
draft-ietf-bfd-generic-05 Section 4.1 - and seems clear to me - though
Dave seems to think the wording could be improved.

Section 4.1 also mentions that the control protocol could carry
signaling as to the willingness to establish a BFD session - thereby
enabling the IGP to correctly choose whether to block the establishment
of its adjacency until the BFD session is up or not. The only defined
signalling I am aware of is in

draft-ietf-isis-bfd-tlv-01

Absent such a signalling mechanism, it has been standard procedure for
the IGP adjacency to come up first and the BFD session to be used solely
as a fast-down detection mechanism. This works well enough in cases
where the control protocol packets share fate with the BFD packets -
which is the case with OSPFv2 and OSPFv3 when used for IPv6. However it
is not the case for IS-IS - hence the motivation for the above draft. It
is also not the case when OSPFv3 is used to support IPv4.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dave Katz
> Sent: Friday, December 11, 2009 9:22 AM
> To: Johannes Resch
> Cc: [email-masked]
> Subject: Re: draft-ietf-bfd-generic-05, adjacency establishment
> (section 4.1,10.1.1)
>