Subject: BFD MIB comments

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Sep 2008 14:45:19 +0530

Hi Tom/ Zafar/ Nobo,

I noticed some small changes required in the MIB which need some
consideration, while working on the BFD.

1. In the session table I find there is an object which states BFD
SessionAuthenticationType. We also talk about KeyId.

The idea of KeyId is to be able to use any algorithm and Key and hence
allow Key changing (for Key rollover)  and authentication type
changing at run time. So a KeyID indexes information which tells the
authentication and the Key to be used. When we want to change either
the algorithm or the Key at either end. We first allow another Key
ID's to be enabled for packet reception while still using the old one
for sending out packets. When all the routers have been configured
with this change we can actually do a Key switchover, by changing the
configuration for sending packets. There however seems only 1 KeyID
overall for receiving and sending.

In my view we can have a separate table of all KeyId's which is
indexed by each session, just like the session performance table. The
table itself contains KeyId (the Index to the table) active/ inactive/
algorithm to use and direction (outbound/ inbound/ both). There can be
only one sending but multiple reception Keys active at one time (so if
another is made active the otehr row needs to be made inactive).

2. I also noticed that bfdSessOperMode, some values talk about Fun and
others Function. We can make that uniform, preferably the full term to
be used.

3. I think BFDSessionPerfEntry needs to have counts of at least
packets which were discarded - if not count of the reasons of each
kind of packet discarded.

4. I think we need to add number of packets for which authentication
failed. It is very helpful and essential and figuring if there are any
misbehaving packets being received.

If you need help with this, do let me know and I can update this myself too.

Thanks,
Vishwas

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 17 Sep 2008 10:50:55 +0100

> another is made active the otehr row needs to be made inactive).

	This is a pretty significant change. I'd like to hear from the  
vendors who are implementing this to see if this is really needed in  
their implementations.

> others Function. We can make that uniform, preferably the full term to

	ACK.

> kind of packet discarded.

	This is very difficult to do in a real implementation -- especially  
one that is highly optimized for the positive case; therefore, I do  
not think we should do this. At best I would say counting discards  
without a reason is the way to go here.

> misbehaving packets being received.

	The alternative to counting, is to just have a time stamp for the  
last failure. Operationally it is not the number of failures on a  
session that matter (most of the time), but when the last time it  
happened.

	--Tom

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Sep 2008 15:37:13 +0530

Hi Tom,

> vendors who are implementing this to see if this is really needed in their
> implementations.

Yes this is a significant change. But it meets the requirement of what
is explained in the MIB draft itself of allowing multiple KeyID's. We
currently talk about allowing multiple KeyId's active however the
session has only 1 KeyId field.

Yes, we are implementing it. This thing is already there in our other
protocol implementations.

> one that is highly optimized for the positive case; therefore, I do not
> think we should do this. At best I would say counting discards without a
> reason is the way to go here.

Yes that would be ok too. Though I would prefer more diagnostics information.

> last failure. Operationally it is not the number of failures on a session
> that matter (most of the time), but when the last time it happened.
Yes, agree. However if you see the security perspective, you would
want to know how many times there have been tries to test the security
of the system.

>> If you need help with this, do let me know and I can update this myself
Ok, this offer is still open. :)

Thanks,
Vishwas

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 17 Sep 2008 11:27:52 +0100

> protocol implementations.
	
	I am sure that you are. *)  I want to know who all else is using it.

	--Tom

>> not
>> session
>>> If you need help with this, do let me know and I can update this  
>>> myself
>>> too.