North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: [RRG] Routers in DFZ

  • From: Eliot Lear
  • Date: Sun Aug 12 13:42:29 2007
  • Authentication-results: ams-dkim-1; [email protected]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; );
  • Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1130; t=1186940480; x=1187804480; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; [email protected]; z=From:=20Eliot=20Lear=20<[email protected]> |Subject:=20Re=3A=20[RRG]=20Routers=20in=20DFZ |Sender:=20; bh=DXAz46Jg71biM3qsSqk4RA5p0f3M86x5/9cA8RBgH34=; b=PRCEtnyUWy8XCT4YZSusUMKqJc4I+gLlHYnSlKgiaV8qg4rajrzoj4lwYtxKI2ydHq1Mi+K6 ELlRae0Sw0eni/qVJrx2LTGG4oMkjIesdexl40JGXEPm/cyHCakHKdO9;

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