Re: So -- what did happen to Panix?

From: John Payne (no email)
Date: Wed Feb 01 2006 - 15:49:07 EST

  • Next message: Richard A Steenbergen: "Re: 74/8 75/8 76/8"

    On Jan 30, 2006, at 5:02 AM, Richard A Steenbergen wrote:

    >
    > On Mon, Jan 30, 2006 at 09:48:13AM +0000,
    > wrote:
    >>
    >>>> Wouldn't a well-operated network of IRRs used by 95% of
    >>>> network operators be able to meet all three of your
    >>>> requirements?
    >>>
    >>> We have such a database (used by Verio and others), but the Panix
    >> incident
    >>> happened anyway due to bit rot. We've got to find a way to fix the
    >> layer 8
    >>> problems before we can make improvements at layer 3.
    >>
    >> If an IRR suffers from bit-rot, then I don't consider
    >> it to be "well-operated" and therefore it cannot be
    >> considered to be part of a well-operated network of
    >> IRRs.
    >>
    >> The point is that the tools exist. The failing is in
    >> how those tools are managed. In other words this is
    >> an operational problem on both the scale of a single
    >> IRR and on the scale of the IRR system. Is this
    >> what you mean by a "layer 8" problem?
    >
    > Take it up with the people putting data into the system, not the IRR
    > operators. Anyone who is behind an IRR-based provider (like Verio) has
    > motivation to put data into the system ("hey look I do this and now
    > routing works"), but there is no motivation to take stale data OUT
    > of the
    > system.

    It gets even more fun if you're delegating route-origination to 3rd
    parties.
    Add a mnt-routes: so they can create a route object, but then you
    can't remove that inetnum block whilst their route object exists (nor
    remove the mnt-routes).

    *sigh*


  • Next message: Richard A Steenbergen: "Re: 74/8 75/8 76/8"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD