[arin-ppml] IPv6 Non-connected networks

[Michael K. Smith]

On 2/21/10 9:02 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

> 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
> info...)
> 
>> 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)
> 
Why wouldn't we just allocate them normally, like any other block?  If we
don't give them the 1918'ish status then we don't have to worry about
unintended consequences.  Instead, it's up to the end user to make sure the
routes are not leaked but, if they are, they just end up in the DFZ with
everything else.

I guess I'm thinking that it would be better to change the restriction on
6.5.1.1 than create a new set of policies for "unconnected" networks.

Regards,

Mike