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