[98544] in North American Network Operators' Group
Re: [RRG] Routers in DFZ
daemon@ATHENA.MIT.EDU (Eliot Lear)
Sun Aug 12 13:42:17 2007
Date: Sun, 12 Aug 2007 19:36:39 +0200
From: Eliot Lear <lear@cisco.com>
To: "John G. Scudder" <jgs@bgp.nu>
CC: raszuk@juniper.net, Dino Farinacci <dino@cisco.com>,
Peter Sherbin <pesherb@yahoo.com>,
Routing Research Group list <rrg@psg.com>,
bmanning@vacation.karoshi.com, ppml@arin.net, nanog@nanog.org,
Robin Whittle <rw@firstpr.com.au>,
"Ricardo V. Oliveira" <rveloso@CS.UCLA.EDU>
In-Reply-To: <8C669A4F-9CAC-4991-B0C8-488E5E8A2324@bgp.nu>
Errors-To: owner-nanog@merit.edu
John,
> Done. draft-ietf-idr-bgp-multisession-03 provides the necessary
> protocol machinery.
While that draft looks reasonable for its intended purpose, I think Dino
was talking about actually shoveling less crap around, router by
router. That having been said, I've somewhat lost the plot here. Is
the point to allow for priority processing of certain types of
information in the face of a performance problem? If so, that's a fine
*tactical* and incremental approach (although I don't think much of
using a TCP window as application layer flow control - it leads to bad
behaviors on both sides when the number of connections increase [See
RFC-793, Page 42, "Managing the Window").
But to your original point, that one cannot simply assume a linear death
march, I'd agree. I think Tony and others' points were that the issue
here is in cost and development curves, looking many MANY years out. If
we can find an even better approach to avoid brute force with acceptable
trade-offs (and those are a lot of ifs), then we've advanced the state
of the art and that's a good thing.
Eliot
