The sampling Curtis mentioned on the NSS routers is a bit different.
For one, it doesn't really impact forwarding performance (and hopefully,
if/when implemented on the Bay, will not impact forwarding performance).
Secondly, there's a lot more information available if you need it (packet
headers or even payload).
But what we're specifically looking for in terms of continuous sampling
(such as that we do on the NSS routers) is a net matrix... if you
changed the Cisco flow switching stuff to use network numbers (and
mask), you'd have something very much like what we're looking for in
terms of continuous sampling. From there we build AS matrices, etc.
The other thing about the flow-switching data that's different than the
NSS (and probably what we'll get from Bay) is that there aren't really
any nice ways of retrieving/storing the data automatically.
As Curtis pointed out, the data is mostly used for capacity planning and
other network architecture issues. I have not receieved a request to
track down a cracker with this type of data in a very long time. Maybe
I've just been lucky. 
Daniel
The sampling Curtis mentioned on the NSS routers is a bit different.
For one, it doesn't really impact forwarding performance (and hopefully,
if/when implemented on the Bay, will not impact forwarding performance).
Not to pick nits, but what I quoted was a cache snapshot; caches
don't impact performance under normal circumstances, though their
construction may do so.
But what we're specifically looking for in terms of continuous sampling
(such as that we do on the NSS routers) is a net matrix... if you
changed the Cisco flow switching stuff to use network numbers (and
mask), you'd have something very much like what we're looking for in
terms of continuous sampling. From there we build AS matrices, etc.
Yes ... but you shouldn't need anything special for that. We have
been doing the same for a long time, using regular IP accounting on
the edge routers, which is then summarised over a full routing table.
The only discrepancies that occur are if changes in routing occur
between the time of accounting and processing, but this tends not to
be a problem.
The other thing about the flow-switching data that's different than the
NSS (and probably what we'll get from Bay) is that there aren't really
any nice ways of retrieving/storing the data automatically.
This used to be true, but "probably" isn't true any longer.