Re: So -- what did happen to Panix?

[Jared Mauch <jared () puck nether net>]

Dislcaimer: I work for AS2914

On Thu, Jan 26, 2006 at 02:39:59PM -0500, Todd Underwood wrote:
> Another set of approaches has been to look at alternate methods of
> building filters, taking into account more information about history
> of routing announcements and dampening or refusing to accept novel,
> questionable announcements for some fixed, short amount of time.  Josh
> Karlin's paper suggests that as does some of the stuff that Tom
> Scholl, Jim Deleskie and I presented at the last nanog. All of this
> has the disadvantage of being a partial solution, the advantage of
> being implementable easily and in stages without a network forklift or
> a protocol upgrade, but the further disadvantage of being nowhere near
> fully baked. 
>
> Clearly more, smarter people need to keep searching for good solutions
> to this set of problems.  Extra credit for solutions that can be
> implemented by individual autonomous systems without hardware upgrades
> or major protocol changes, but that may not be possible.
>
> t.
>
> p.s.:  wrt comments made previously that imply that moving parts of
> routing control off of the routers is "Bell-like" or "bell-headed":
> although the comments are silly and made somewhat in jest, they're
> obviously not true.  anyone who builds prefix filters or access lists
> off of routers is already generating policy somewhere other than the
> router.  using additional history or smarts to do that and uploading
> prefix filters more often doesn't change that existing architecture or
> make the network somehow "bell-like".  it might not work well enough
> to solve the problem, but that's another, interesting objection.

        This is something that (as i mentioned to you in private) some others
have thought of as well.  We at 2914 build the filters and such off-the-route
and load them to the router with sometimes quite large configurations.
(they have been ~8MB in the past)

        I'd love to see some prefix stability data (eg: 129.250/16
has been announced by origin-as 2914 for X years/seconds/whatnot)
which can help score the data better.  Do we need a origin-as match
in our router policies?  does it exist already?  What about a way to
dampen/delay announcements that don't match the origin-as data
that exists?

        I think a solution like this would help out a number of networks
that have these types of problems/challenges.  Obviously noticing an
origin change and alerting or similar on that would be nice and useful,
but would the noise be too much for a NOC display?

        - jared

ps. i'm glad our NOC/operations people were able to solve the PANIX
issue quickly for them.

-- 
Jared Mauch  | pgp key available via finger from jared () puck nether net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.