At 1:57 PM +0000 6/22/03, - jvd wrote: >Thank you for your answer Howard. Unfortunately I don't have enough >experience to answer in such depth as you did but maybe one day I'll get >there. :-) > >PS. Isn't it good to see that experts participate in this forum too? >
Ah, but you are missing some of the nuances of what the experts say: they _know_ they don't know. Incidentally, we divide the problem into three parts: eBGP convergence (with one and multiple peers, with no policy or route selection modifiers to start), iBGP convergence within an AS, and Internet-wide convergence. Our focus is on the first and second, while some of the best work on the others comes from people like Craig Labovits, the late Abha Ahuja, etc. There's yet a different issue of route stability across the Internet, explored at length in Vern Paxson's PhD dissertation. A little history about how our BGP work got started. One fine day, when I was working at Nortel as a router designer, somebody from sales came running in asking "how many BGP peers can we have?" I started to explain the honest answer of "it depends." It should be pretty intuitive that you can have more peers that are customer routers accepting default and announcing a couple of routes, than you can routers that are exchanging 100,000+ routes. That wasn't what sales wanted to hear. What they wanted to hear simply was that we did more than Juniper. They only wanted that one number, while the reality is that there are lots of things that you can't meaningfully reduce to one number. So, I wrote the first draft of BGP convergence definition, first as an internal document, then as an individual submission from the IETF. Very quickly, we found that engineers at other router and router code manufacturers were being driven crazy by sales as well -- so we rapidly had a team involving Cisco, Nortel, Juniper and NextHop (the last makes OEM router software -- the commercial GateD). Test instrument vendors got interested because they wanted to have a clear measurement to build against. Incidentally, credit where credit is due -- one of the silly things holding up our final publication is an IETF (actually IESG) rule that an RFC can just have five authors. We have six active participants. Alvaro Retana, our team member from Cisco, gracefully volunteered to have his name moved to the acknowledgement section to get around the problem, but he is as major a contributor as anyone else. Unfortunately, we slowed down on the measurement methodology with about half of us losing jobs, being reassigned, etc., but we are hoping to get personal time to finish it. We had three measurement testbeds, at Nortel, Cisco, and NextHop. (No, we aren't going to release the actual numbers--that's not what the IETF is for). It is interesting, however, to find that convergence times will be different, with exactly the same number of routes and other parameters, between a Cisco and a Cisco, a Juniper and a Cisco, a Juniper and a Juniper, etc. There are pure implementer decisions that can slow down -- or in one case speed up -- talking to a router with different internal assumptions on the way you store the Loc-RIB or the order in which you send prefixes in updates. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71093&t=70960 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
