North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Deaggregating for emergency purposes

  • From: ril_phosenthal
  • Date: Wed Aug 07 17:18:44 2002

I agree that the thread needs to die.  Anything useful that could be said has been said, and I'm the one who said it.

The end result is, the proper thing to do is make sure your upstream allows you to announce any more specifics than what you have in the IRR.  They should not limit the number of announcements they hear, either.  Equipment is cheap enough that upstreams should provide a dedicated 7200-series router for each customer.

Filters should also apply to everone but me.  I have excellent connections and clue to spare, and want everyone to trust my announcements.  I'm almost a Tier 1 now, but unfortunately the old Tier 1's don't understand this.  Maybe their should be an IRR object where providers can indicate their clue level.

Use your best judgment in deaggregating, and it is always better if you can get it fixed by having the offending party stop announcing, or their uplinks filter.  However, this can be difficult, and sometimes take in excess of five minutes.  It is far better for all providers to mirror each IRR every hour so I do not have to deal with this stress.

Until secure BGP exists there's no reason not to take a brute force approach to squash out occasional misconfigurations that can be so painful to deal with when they do occur.

The final piece to this puzzle is an OOB messaging protocol to tell all other providers to synchronize with the IRR emergency entries.  Hijacking won't be a problem if we create another registry to authenticate OOB push messages.

In fact, I think we can automate the entire NOC paradigm in favor of totally automated route management.

--Ril


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople