|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Network for Sale
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. :) Jay, 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. --- John Fraizer EnterZone, Inc
|