North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Network for Sale
- From: John Fraizer
- Date: Tue Feb 20 04:54:28 2001
On Tue, 20 Feb 2001, Jay wrote:
> On Tue, 20 Feb 2001, John Fraizer wrote:
> > The last time I checked, BGP4 didn't do _ANTHING_ static. Perhaps the
> > kind folks at OPNIX would like to tell us something we don't know about
> > BGP. After all, they did manage to create a new tier.
> "Static" certainly isn't the right word -- I'll agree with that. The
> marketing department apparently liked it. :) Again, just as with all the
> "Tier-n" garbage, that language will be changed in the new version of the
> web site.
> However, the point is simply that BGP4 makes routing decisions based on AS
> hops. Yet, AS hops really don't mean anything when it comes to
> performance. The stuff that matters is things like latency, packet loss,
> etc... Granted, more AS hops MIGHT have more latency/packet loss, but
> that's not always the case. :)
You'll be hard pressed to find a border router of a BGP speaker that makes
routing decisions based soley on AS path length. There are many variables
that a peer can take into account to decide best-path and most of us use
those variables to "shape" traffic in some way-shape-form.
I suspect that your new technology simply adds another variable to the
best-path-selection process based on your ping/traceroute script RTT's to
a specific network based on what you have divolged thusfar.
If this is in fact the case, I have two problems with the technology:
(1) To interwork with existing routers, it has to do ebgp-multihop to
peers and then send its tables to the "REAL routers." This adds a point
of failure to the mix. (subtract several 9's)
(2) In order to have an ACCURATE picture of the global internet, your
software will have to constantly probe remote networks to establish the
best RTT path which in turn will create N^routing_table_size traffic on at
least ONE link (if you do it the lazy way) and N*X^routing_table_size
traffic if your do it from multiple points to establish a "mean RTT".
Both of the above have CONS which outweigh any potential benefit that may
be obtained and the second has the potential, if deployed on any large
scale, to create a 1:10,000(+) S:N ratio on the internet as a whole as
every router aggressively seeks out a better path to the each network.
My alcohol induced deductions based on the limited information you have
provided lead me to believe that your product, if it in any way is like I
imagine it to be, will do more harm than good and as such, should be
squashed like a fly.
Feel free to embarrass me by releasing the protocol and showing that what
you're doing is in no way like what I have outlined above.