Subject: RE: [Idr] New "BFD session down" error sub-code for the BGP CeaseNOTIFICATION message.

From: "Bruno Rijsman" <[email-masked]>
Date: Fri, 8 Dec 2006 10:03:36 -0500

MitchellErblich> Does this mean that the state variable
"bfd.SessionState" is Down or AdminDown? Or both?

That is actually a very good question.

The cease notification with subcode "BFD session down" should be sent
when the BFD session transitions from "Up" to "Down".

In other words, the notification indicates that the session *went*
operationally "Down" and not that the session *is* operationally "Down".

I should probably rename the subcode to "BFD session lost" or "BFD
session went down" to clarify this.

Just to give some background information: all BFD for BGP
implementations which I am familiar with (include one from another major
vendor) work as follows:

(1) When the BGP session reaches state established (or sometimes
earlier), a BFD session is initiated to the address of the BGP neighbor.

(2) If the BFD session fails to come up (e.g. because BFD is not
configured on the remote side) the BGP session is still allowed to stay
in state established. So, the fact that the BFD session is "Down" at
this point does *not* trigger BGP to send a notification.

(3) Let's assume that the BFD session does come "Up" at some point in
time.

(4) If the BFD session goes "Down" after that, the BGP session will be
terminated, and BGP will send a notification with the new error subcode
"BFD session (went) down".

(5) We should not send the notification when BFD goes from "Up" to
"AdminDown" (e.g. when BFD is unconfigured) because this transition does
not indicate a failure.

Someone (*) pointed out that if the BFD session went down because of a
real link failure, it is unlikely that the notification will make it to
the other side. The new error subcode is still useful:

- To detect false failures: BFD session went down despite the fact that
the link is still up (e.g. BFD timers too aggressive for a given
implementation).

- For local side debugging: even though the notification would not make
it to the other side, many CLI and MIB implementations report the error
code and subcode of the most recently sent notification.

(*) = The reason I don't credit the person by name is that I assume that
person doesn't want his name on a public mailing list since he sent the
comment only to me.

-- Bruno 

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Erblichs <[email-masked]>
Date: Mon, 11 Dec 2006 12:50:18 -0800

Bruno Rijsman,

	You seem to separate the message notfication from the
	actual  status of the link....

> operationally "Down" and not that the session *is* operationally "Down".
	
	Which seems to be opposite of
	6.7.5. Detecting Failures with the Echo Function.

	IMO,,

	1) If the local BFD doesn't see an echo, it should somehow
	   generate a local BFD session down and get the error sub-code
	   to the local BGP. This is a guranteed deliverable msg.

	2) It would seem here that if the session "went" operationally
	   down then it "is" operationally down. At least until we see
	   a new echo / hello / alive type pkt.

	--
	This is when the endpoint can only REALLY state that I am here, by
	the sending of echos / hellos / alive pkts.

	So, the problem I see is that if you timers are functionally correct
	the message is only generate locally. So, we already have that in
	6.7.5 and the non-recievable message is not sent as you already
	stated.

	And that if your timers are too agressive you will take down the
	BFD and the BGP session / connections..

	Thus, I don't know why you just don't determine the session condition
	and notification locally by section 6.7.5.

	Mitchell Erblich