On Jul 9, 2007, at 8:56 AM, Marcus H. Sachs wrote:
If we had routing registries that were accurate and authoritative
Irrespective of the stat us of s*BGP deployment, following existing
BCPs with currently-deployed techniques/functionality/features would
have prevented the issue
On Mon, 9 Jul 2007, Cat Okita wrote:
As far as needing a verification system, is there something deeply
problematic about filtering your customers? It's a fine example of
thinking globally and acting locally.
That's what I'm curious about...this boils down to L3 not properly
filtering
following existing BCPs with currently-deployed
techniques/functionality/features would have prevented the issue
described in the post.
knowing that level(3) is one of the most serious deployments of
irr-based route filters and other prudent practices, perhaps we should
wait for a post mortem
Does anyone have further information on the Vericenter Denver outtage?
Support is aware of the issue, however, they could not feed me a
problem description at the time of ticket creation or an ETR?
James Baldwin
Outtage with the primary sprintlink connection. Still no ETR.
James Baldwin
On Jul 9, 2007, at 2:09 AM, James Baldwin wrote:
Does anyone have further information on the Vericenter Denver outtage?
Support is aware of the issue, however, they could not feed me a
problem description at the
On Mon, 09 Jul 2007 02:18:25 -, Chris L. Morrow said:
While S*BGP seem like they may offer additional protections and additional
knobs to be used for protecting 'us' from 'them', the very basics are
obviously not being done so added complexity is not going to really help
:( Or, perhaps
On Mon, 9 Jul 2007 [EMAIL PROTECTED] wrote:
On Mon, 09 Jul 2007 02:18:25 -, Chris L. Morrow said:
While S*BGP seem like they may offer additional protections and additional
knobs to be used for protecting 'us' from 'them', the very basics are
obviously not being done so added
On Jul 9, 2007, at 10:47 AM, [EMAIL PROTECTED] wrote:
On Mon, 09 Jul 2007 02:18:25 -, Chris L. Morrow said:
While S*BGP seem like they may offer additional protections and
additional
knobs to be used for protecting 'us' from 'them', the very basics are
obviously not being done so
On Mon, Jul 09, 2007 at 02:31:10PM +0800, Randy Bush wrote:
following existing BCPs with currently-deployed
techniques/functionality/features would have prevented the issue
described in the post.
knowing that level(3) is one of the most serious deployments of
irr-based route filters
Tony Tauber wrote:
On Mon, Jul 09, 2007 at 02:31:10PM +0800, Randy Bush wrote:
following existing BCPs with currently-deployed
techniques/functionality/features would have prevented the issue
described in the post.
knowing that level(3) is one of the most serious deployments of
irr-based
On Tue, 10 Jul 2007, Randy Bush wrote:
the space of routing data validation is large, we can explore it at our
leisure, and we have been for some years. but my point was that it is
silly to indulge in conjecturbation on the cause of the recent event and
excoriate l(3), hanaro, or john curran's
On Mon, Jul 09, 2007 at 01:23:46PM -0500, Borchers, Mark M. wrote:
Jared Mauch wrote:
The simple truth is that prefix lists ARE hard to manage.
Medium-hard IMHO. Adding prefixes is relatively easy to implement.
Tracking and removing outdated information significantly more challenging.
On 9-Jul-2007, at 16:13, Jared Mauch wrote:
Some have automated systems, but they're dependent on IRR data
being correct. There are even tools to automate population of IRR
data.
Building customer filters from the IRR seems like it should fall in
the easy bucket, given how long
On Mon, Jul 09, 2007 at 04:50:56PM -0400, Joe Abley wrote:
On 9-Jul-2007, at 16:13, Jared Mauch wrote:
Some have automated systems, but they're dependent on IRR data
being correct. There are even tools to automate population of IRR data.
Building customer filters from the IRR
On Mon, Jul 09, 2007 at 04:50:56PM -0400, Joe Abley wrote:
SIDR is only of any widespread use if it is coupled with policy/
procedures at the RIRs to provide certificates for resources that are
assigned/allocated. However, this seems like less of a hurdle than
you'd think when you look
Shane- Please redirect your email questions to ARIN ppml or discuss. That
will be a better forum for you with these type of questions. I will also email
you on the side.
Cheers!
Marla Azinger
Frontier Communications
AC Chair
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
There is some misinformation in previous posts that I would like to
clarify on the Level 3 side of things.
Every transit-like connection on AS3356 is prefix-filtered including all
parties in this event. On AS3356 all prefix filters and import policies
on BGP sessions are audited and
On Mon, 9 Jul 2007, Kevin Epperson wrote:
There is some misinformation in previous posts that I would like to
clarify on the Level 3 side of things.
and I'd apologize for hinting that that might be the problem :(
Level 3's own registry and known public route registries. As several
18 matches
Mail list logo
