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

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.
Thanks for pointing that out.  I'm no expert in PIC, but it would seem 
to address purely the cases where there is little state flux in the 
control plane.  Consider the case of when a new router first joins the 
BGP mesh today.  This is when we will see the biggest impact in the 
number of prefixes carried.
That's as you may perhaps noticed I am a big supporter of two stage 
tunneling within each AS or within each POP. So only very limited number 
of routers per domain would need to go via this biggest impact cycle .. 
clearly not all of them. And as we all know we do have tools to allow 
for graceful initial convergence.
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 ?
I guess I'm disagreeing with you.  The control plane is very much the 
issue.  The control plane *mechanism* is not the issue, but the 
scalability of the data manipulated by the control plane very much is at 
issue.
I am not questioning that at all ... especially thinking about the scale 
involved going into the future. I am just trying to determine if current 
mechanics of the control plane .. when decoupled from being responsible 
for fast locator/next hop reachability vehicle could not meet the new 
scale requirements. And if not ... why.
I guess the real question get's down to either carry or not to carry all 
EIDs at each let's call it default mapper or even as in NERD each ITR. I 
 am not sure if on demand caching will be the answer to this question. 
Personally I doubt it.
Cheers,
R.


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