preventing future situations like panix


    > The idea is simply to consider 'suspicious' looking routes as a last
    > resort in the decision process (~1 day). Thus if no alternative route
    > for a prefix exists, the suspicious route is used regardless, no harm
    > done.

It seems like most of the routers which would need to make this decision
wouldn't have adequate information upon which to do so...

not necessarily. the decision could be made in "near real time" by
building prefix filters based on the algorithms that josh and co have
worked on and leaving a 'default deny' in place. this moves the
routing decision off of the router (which i agree does not have the
history or resources to take these additional vectors of information
into account) and over to a server with more storage and computational

it has the side effect of denying announcements of valid prefixes from
customers that are not in the prefix list until the list is next
updated, but we already pay that price now; well, networks that
maintain prefix filter lists on customer-facing ports pay that price
now. this just describes a different way of building and maintaining
those lists.

the idea of incorporating history into the validation process for routing
tremendously useful and worth considering seriously. at least until we
get all signed updates. how is that whole thing going? :slight_smile: