[arin-ppml] IPv6 Non-connected networks
christopher.morrow at gmail.com
Mon Feb 22 00:02:22 EST 2010
On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser at seven.com> wrote:
>> The current kit deals with packets rather than flows. Flows was
>> investigated thoroughly and looks very much like a blind alley. It has
>> some useful niches but the failure modes are catastrophic.
> Yeah, I know that, but they tend to cache information regarding a flow.
huh? a CRS or T-series device doesn't cache anything about flows. each
packet in turn on input is looked up in the FIB for send to the proper
output interface. (extreme, as another vendor also doesn't cache flow
> The cache isn't big enough is the problem I am worried about. Some gear
> likes to populate the routes (FIB) in hardware and if you don't have
> enough space, they don't all get in there. Chip density being what it
> is, I would think that more storage is available in the same form factor
> today than was available when the module was initially designed. It
See scudder's talk about 100g and how long you have to lookup before
your input buffer is full with a full interface.
There are 2 parts to this problem (and this is wandering way off
topic) size of the FIB and rate of change of the FIB.
Back to the original topic though... As to providing globally unique
addresses to end sites who want this for their internal uses only,
that seems like a worthy goal, to me. I have 2 concerns:
1) creating another rfc1918-ish block. (registration of this space
seems to avoid this)
2) leakages into the global table, unintended ones. (pulling from a
set supernet seems to cover this concern as well)
More information about the ARIN-PPML