[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Tony,

> What we see today is that convergence is slowing,

That is good observation ... but I want to also point out that there is already a deployed technology to offer prefix independent convergence.

So far deployed within an AS scope .. but very possible to be deployed system-wide if we go to two tier BGP hierarchy.

We have said that control plane is pretty much not the issue. So perhaps we should shift the discussion into ways to fit control plane into data plane so PIC would be achievable system-wide ?

Cheers,
R.

On Jan 8, 2008, at 2:37 PM, Brian E Carpenter wrote:

 I guess I believe that an unsustainable level of
BGP update traffic will be the first practical consequence to hit us.


The two router vendors that are vocally represented here don't seem to support that view, however. How do you define "unsustainable"? You can create non-convergence today in the lab by simply causing a set of BGP speakers generate flap faster than the unit under test. You can also create that in the field today by putting woefully underpowered CPU (anyone still got a CSC-4 handy? ;-) in the core. What we see today is that convergence is slowing, but it's difficult to argue about when (or if) it will get to non-convergence, given Moore's law and technology refresh cycles. This is exactly why we try to focus the issue around clearly quantifiable issues.

Tony






--
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