Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Brian Dickson <briand@ca.afilias.info>]

On Jan 8, 2008, at 2:49 PM, Tony Li wrote:

> On Jan 8, 2008, at 2:37 PM, Brian E Carpenter wrote:
>
> >  I guess I believe that an un-sustainable level of
(edited to get around silly mail filter problem)
> > BGP update traffic will be the first practical consequence to hit us.
It may be an issue at some point.
However, the near-term consequences of growth in the DFZ, are that
*forwarding-plane* (FIB, i.e. TCAM) growth exceeds the hardware refresh
cycle.
(i.e. the bottom line $$$ impact breaks business models substantially,
even universally.)

Heck, it even exceeds the rate at which TCAM manufacturers can up the
size they support.

So, the important thing about LISP, is that it keeps EIDs out of the
DFZ, making the DFZ scale better.
The question is, is there a solution which does this while also ensuring
that the edges scale well?
Both on the control plane, and the forwarding plane?
And with "convergence" (reachability state updates) that are no worse
than they are today?
> This is exactly why we try to focus the issue around clearly 
> quantifiable issues.
>
> Tony 

Incidentally, what about solutions that might improve BGP update rates
themselves?
Would that be an issue for the IDR WG, or is that an RRG thing?
(I'm working on the stuff we talked about before, but my time gets
divided by lots of things, sadly.)

Brian


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg