North American Network Operators Group

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

Re: Why doesn't BGP...

  • From: Chris A. Icide
  • Date: Sat Nov 09 21:18:22 1996

At 09:33 AM 11/9/96 -0800, Ed Morin wrote:
>Look, I can do a "show interface" on any interface and see what speed
>it's running at and if it's dropping packets.  If BGP hears a route
>on an interface that isn't dropping packets shouldn't _that_ route
>be considered "best" all other things being equal (hop counts and
>all)?  You can't tell me the router doesn't know this information
>because _I_ get the information from the router itself!!
>I understand about route instabilities, etc.  All I'm talking about
>here is a better "tie breaker" than ordinate numbers of IP addresses.


One major problem that you have overlooked is what happens 
when this wonderful automagic route protocol does exactly what
you suggest?

You have two wonderful paths to a wonderful location in a
wonderful world.  However, some wonderful traffic has wonderfully
overwhelmed one of your links, and you have (not so wonderful)
packet loss.  Immediately your routing protocol senses this, and
begins to prefer the other route.  But a strange thing happens, the
packet loss disappears on the first route and appears on the second
and all of the sudden you have packet loss on the second link.

Now I was not involved in the designing of the BGP (any rev level)
specification, so the next bit of text is MHO of some of the thought
process that may have gone into the development.

Making something "fool-proof" tends to induce ignorance of the 
process and sloppy (if not negligent) engineering.  BGP is NOT
designed as the end all be all solution for networking.  This still
requires the human brain.  I think perhaps the folks who designed
BGP might have had this in mind.

The phrase, "When all you have is a hammer, everything looks
like a nail" comes to mind. 

Don't think of BGP as your hammer, it's a tool in a bag of tools.

Of course there are always two necessary things one should
know before using a tool:

1.	What was the tool designed for?
2.	What are all the features of the tool, that allows one to
	use it to it's fullest capability.

And finally, I'm going to throw in my personal humble opinion...

If you are having packet loss constantly on your network, and 
it's within your control, you need to re-engineer your network.  If
it's out of your control, you need to re-engineer your network to
bring it within your control.

<hops off soapbox>

Chris A. Icide
Nap.Net, L.L.C.
- - - - - - - - - - - - - - - - -