[51647] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: AT&T NYC

daemon@ATHENA.MIT.EDU (Feger, James)
Tue Sep 3 12:23:14 2002

Date: Tue, 3 Sep 2002 11:22:40 -0500 (CDT)
From: "Feger, James" <jfeger@feger.net>
To: <nanog@merit.edu>
In-Reply-To: <Pine.LNX.4.10.10209031056100.4454-100000@s1.yuriev.com>
Errors-To: owner-nanog-outgoing@merit.edu


You keep referring to the problem of OSPF causing the outage
for AT&T and unaffected customers.  The AT&T released RFO simply states
that OSPF network statements were removed.  That can happen just as easy
with static routes and BGP network/neighbor statements.

OSPF did what it was instructed to do, just as BGP would have done if it
were told to drop neighbors, or networks.

-jf


On Tue, 3 Sep 2002 alex@yuriev.com wrote:

>
> > Since when is BGP a bug-free protocol? Let's not forget the BGP best
> > path selection algorithm itself is broken (there are circumstances under
> > which it will NEVER converge on a best path see ietf draft on IDR route
> > oscillation). Not to mention the various malformed AS-Path bugs which
> > have shown up over the years. I took a vendor class once where they made
> > us do a lab where we had to run BGP w/o an IGP, in a later revision of
> > the class they removed that lab because they decided it was too much of
> > a nightmare even for a lab environment.
>
> BGP is not a bug-free protocol.
>
> BGP is the easiest protocol to *debug* when the problem shows up.
>
> BGP does not help to accidently affect *unaffected* paths when a problem
> shows up.
>
> It looks like everyone forgot the reason for this discussion to begin with.
> It is the outage caused by a mistake on a single router that affected parts
> of the network that were *NOT* affected by the original mess.
>
> Please not that this discussion tends to get restarted whenever we have a
> real OSPF (or ISIS) caused mess.
>
>
> Alex
>


home help back first fref pref prev next nref lref last post