- Test - lists.nanog.org

Re: Why doesn't BGP...
by Peter Lothberg 12 Nov '96

12 Nov '96

> * Why doesn't BGP pick the link with the highest bandwidth, or, better > * yet, pick the link with the highest bandwidth AND least congestion to > * label as the "best" available route? The needed information is avail- > > The first one is easy, in fact you can do that yourself by fiddling > with metrics or such on the different BGP sessions. The second one > would have dramatic consequences in terms of route instability. You > pick one route now because of load on the link, the load changes and > you pick the other, now BGP will have to change the announcement of > this network to other peers. So, now we not only have flaps because of > links/routers going up and down, we also have flap because of load > changes on the network. The result: you are dampened out forever, or > the network falls over. > > -Marten On the radio1:: "101 north is congested, take 280 instead" Guess what hapens 5 minutes laster; On the radio2:: "280 north is congested, take 101 instead" goto on the radio1 --Peter

6 6

Re: Why doesn't BGP...
by Tine Hutchison 11 Nov '96

11 Nov '96

---------- : From: Vadim Antonov <avg(a)pluris.com> : Seriously, the load-sensitive traffic management _can_ be done, : but to do it you a) need full knowledge of the load patterns, : plus some historical data, and b) have a way to control system : in steps less drastic than rerouting an entire flow. : : Can't be done with ciscos, or any existing routers... : : --vadim Not true... 3Com's Internet Backbone class router will do it! Well, someday it will, maybe, if that's what we really want, it could... perhaps. Tine Hutchison Network Engineer Interaccess Co. tine(a)interaccess.com 312/496-4653

2 1

Small update on CIDR Report
by jerryp＠mailserv.pcqt.com 11 Nov '96

11 Nov '96

You can now check this on a daily basis via HTML at the following URL http://www.employees.org:80/~tbates/cidr-report.html This is just a very basic translation of the CIDR report I send out once a week but now updated on a daily basis. I will continue to send out the weekly mail updates. I'll be adding more to the Web interface as time permits. For those interested in todays report it highlights a very large leak of almost 1200 routes by AS719 which they wish to take a look at. I'll let others draw their own conclusions from the rest of the data. Regards, --Tony --------------------------------- Jerry Phannenstill jerryp(a)pcqt.com jerryp(a)mcs.com "Where you want to go today is not neccessarily where you want to be tomorrow" ---------------------------------

1 0

Re: XPs overloaded?
by Paul Ferguson 11 Nov '96

11 Nov '96

Cute. ;-) - paul At 07:32 AM 11/11/96 -0500, Bradley Dunn wrote: >Next time someone tries to tell you that the NAPs and MAEs are overloaded, >just point them to: >http://www.mfs.net/MAE/ny.cat1.overlay.html > >:-) > >-BD > > >

1 0

XPs overloaded?
by Bradley Dunn 11 Nov '96

11 Nov '96

Next time someone tries to tell you that the NAPs and MAEs are overloaded, just point them to: http://www.mfs.net/MAE/ny.cat1.overlay.html :-) -BD

1 0

Re: Why doesn't BGP...
by Peter Lothberg 11 Nov '96

11 Nov '96

> 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!! And the next hop router? ? And the dampening? > Ed Morin > Northwest Nexus Inc. (206) 455-3505 (voice) > Professional Internet Services ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --Peter Using the internet for a hobby

1 0

Re: Why doesn't BGP...
by William Allen Simpson 11 Nov '96

11 Nov '96

> From: Vadim Antonov <avg(a)pluris.com> > Regarding BGP metrics -- there's a problem with a single "universal" > metric in an exterior routing protocol, namely the absense of a single > authority to assign those metrics. Different networks may have very > much confiliciting interests in how to assign BGP metrics. > Wasn't there a draft somewhere along the way on a global guidelines on how to set the metrics? > Some time ago i wrote a draft (which didn't get any support and quietly > expired) regarding BGP metrics -- the idea was to have a vector of > metrics (one per AS hop) instead of a single scalar metric; and allow > network operators to calculate weighted sums to obtain the locally > significant scalar metrics. I.e. a network operator may decide for > himself how to interpret BGP metrics coming from different AS-es > (or by different paths). > Yeah, I seem to remember liking that. You mean that Tony and Yakov didn't support it.... ;-) And some of the other ideas were similar to Nimrod policy selection.... > If there's any interest i can dig the draft out and place it on my www > server. > Sure. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: Provider credibility - does it matter? was Re: Inter-provider relations
by Vadim Antonov 11 Nov '96

11 Nov '96

Roger Bohn <Rbohn(a)UCSD.edu> wrote: At 8:36 PM -0700 10/24/96, Vadim Antonov wrote: >Note that i didn't even talk about less measurabe, but way too >more important things like hosting of information suppliers. >Say, Big Provider connects 1000 web sites; Small Provider hosts >1 site -- benefit from peering in terms of Web site diversity to >the Big Provider's customers is 0.1%. To Small Provider's >customers the benefit of peering is 99.9%. >Oops, this has an arithmetic fallacy. Assuming that Big Provider also has >1000x more customers than Small Provider, and that all 1001 web sites are >equally attractive, then there are 1000 BP customers each with a .001 >chance of wanting to surf the SP web site. Compare this with 1 SP customer >with a .999 chance of wanting to surf a BP web site, and a .001 chance of >surfing the SP web site. No, this is not about mutual traffic -- this is about benefit to _a_ customer. Your computation is correct but is completely irrelevant from the point of view of a customer. They're interested in reacheability, not traffic at some exchange point. I.e. each small ISP's customer derives 99.9% of benefit from the peering, while large ISP's customer derives only 0.01%. Hence, the large ISP can force small ISP to pay up -- without connectivity to a large ISP the small ISP will be dead pretty soon. This is exactly like grocery chains which can (and do) force consumers to pay up for food -- although you can grow your own tomatoes in your backyard and probably sell them to those grocery chains. Good chances are, they're not interested. --vadim

10 21

Re: Why doesn't BGP...
by Vadim Antonov 10 Nov '96

10 Nov '96

William Allen Simpson <wsimpson(a)greendragon.com> wrote: >Wasn't there a draft somewhere along the way on a global guidelines on >how to set the metrics? I remeber seeing something like that. However i went further by explicitly separating per-hop metrics into static (administrative) and dynamic (injected from IGP) parts, with an explicit visibility scope for the dynamic part. > If there's any interest i can dig the draft out and place it on my www > server. > >Sure. Ok, it is in http://www.pluris.com/avg/draft-bgpmetric.ps and .txt. --vadim

1 0

RE: Why doesn't BGP thread...
by ALAN DORN HETZEL JR 10 Nov '96

10 Nov '96

It's not a perfect solution, but you might consider applying a weight to the routes received over each link based on the speed (or some arbitrary quality factor) of the link. This will sort of get you what you are describing. -Dorn

1 0