[myasntesting] New alarm types (proposal)

Hi,

I've been playing about with the myasn system, and it's impressive, but it
doesn't quite work the way we'd like to it.

While the objective of the project is described as "an alarm notification
system that monitors the propagation of eBGP routes" the biggest problem
we face is the _non-propagation_ of eBGP routes. I've seen countless cases
where our peers (or our peers peer) prefix filters were blocking routes we
were attempting to annouce to them, but few incidents of route leaks or
actual hi-jacking in comparision.

With this in mind, I'd like to suggest two new types of alarm:


Expected Transit Alarm

A Transit Alarm currently goes off when a prefix/AS appears to receive 
transit
from an unspecified provider. Our peering relationships are complex, with
multiple upstreams and presence at multiple exchanges. It would be complex
to list and maintain our entire peering structure in myasn.

An Expected Transit Alarm would sound when a prefix/AS _doesn't_ recieve
transit from a _specified_ provider.

(The difficulty with this alarm is, of course, that perhaps your routing
beacons do not ever see the expected AS path.)


Comparision Alarms

This would allow you to specify groups of prefixs that ought to have
idenitical AS paths, past a specified (common) point.

For example: AS1 is providing identical global transit to AS's 2, 3 and 4,
and identical partial transit to AS's 5, 6, 7. For the global transit
after ^2_1_ , ^3_1_ and ^4_1 the paths seen should be idenitcal. Likewise
for ^5_1_ , ^6_1_ and ^7_1_ .

A comparison alarm would go off when differing AS paths are seen within
the given groups.

With some extra thought on how to specify the common points in the AS
path, AS 1 could also compare it's global annoucements to those it
annouces for ASs 2, 3 and 4 etc.

When setting up new transit and peering arrangements we would use this to
check the propogation of prefixes against known working annoucements. It
would also guard against indiviudal prefixes suddenly being filtered at
some future point.

The nice thing about this is that it only compares, so you don't actually
have to maintain the AS paths you expect to see.


Just some suggestions - I'd be interested in what the implementors think 
about the feasibilty of these.

Sam