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

From: Bob Albrightson <[email-masked]>
Date: Fri, 11 Dec 2009 6:45:22 PST

Unless I'm missing something, it seems to me if a BFD client has not
asked BFD to bring up a session, then any three way handshake in an
attempt to bring up a BFD session should fail.

OSPF should not be relying on BFD to come up before bring up its
sessions.  BFD clients need to bring up their sessions first before
asking BFD to monitor the peer.

 -bob

> 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: Ville Hallivuori <[email-masked]>
Date: Fri, 11 Dec 2009 17:36:46 +0200

Hello all,

I don't see how OSPF could be brought up before BFD session is up. If
user has configured BFD monitoring as a prerequisite, then OSPF clearly
must keep any neighbors that do not have BFD sessions up in a state that
does not permit traffic forwarding. Proper state seems to be Init.

If implementation were to take a more relaxed approach and negotiate OSPF
before BFD session is up, it would risk longer detection times (up to
OSPF dead timer, usually 40 seconds):
  - Until BFD session is brought up
  - Forever, if neighbor does not support BFD

I do agree with Bob that BFD negotiation must not succeed until both
ends have decided to form a BFD adjacency.

IETF documents are indeed pretty vague about this subjects. However
having implemented this once, it seems to me that the only fool proof
process is to:
  1) Send OSPF hellos normally
  2) Receive OSPF hellos normally
  3) When new OSPF neighbor is detected (and BFD is configured),
     trigger BFD session formation.
  4) Until BFD session is up, keep neighbor in Init -state

-- 
[Ville Hallivuori][[email-masked]][http://www.iki.fi/vph/]
[ID 30EC5DF0][FP20=3B02 94F1 FF6F 9CD0 EC81  0FAE 5B3B 3D21 30EC 5DF0]