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 cisco.com/amsdkim1002 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; d=cisco.com; [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;
Valdis,
> 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.

Eliot