North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Some thoughts on 240/4

  • From: Eliot Lear
  • Date: Fri Oct 19 13:21:31 2007
  • Authentication-results: ams-dkim-1; [email protected]; dkim=pass (s ig from verified; );
  • Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=753; t=1192813964; x=1193677964; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;; [email protected]; z=From:=20Eliot=20Lear=20<[email protected]> |Subject:=20Re=3A=20Some=20thoughts=20on=20240/4 |Sender:=20; bh=ksULmI5RDBlPGOmURvlUaG09g7b3RLLl4YsPdyrtaSk=; b=pUZxyMxSxiX3UrEfroNe3QyHWvfPSob/CbGXkZX+ztZaAHSyzDQ/AxhEJynEjquywBoxbgM7 zBONgndRzB5qIhYN5x2TXaGUSlmiiuMoGIYlJQs9uDBYfICLAuUIt3AE;

> More code, more regression testing, same number of programmers.  Do the math.
> Take it as a given that it *will* slip the schedule some amount, because
> the resources for a 240/4 feature will have to come from somewhere.  So
> how much slippage are you willing to accept?

Let's not go too far here.  As Vince pointed out, the work required is
fairly minimal.  It's not nothing.  Particularly in IOS we do a parser
check for Bogons, and this is done in other platforms as well.  But
still- the code involved is typically removing an entry from one or
several tables.  Regression will vary by platform, but that usually
isn't done on a feature by feature case, and so the costs are not linear
as you suggest.