Hi Mark,

On Oct 25, 2011, at 8:09 PM, Mark Tinka wrote:
> On Wednesday, October 26, 2011 05:12:09 AM Richard A 
> Steenbergen wrote:
> 
>> c) Vendors would much rather sell you new cards wih more
>> FIB capacity than find a way to implement a "free"
>> solution in software (big shocker, I know). :)
> 
> I've been chatting with a major vendor about their interest 
> in implementing S-VA:
> 
> http://tools.ietf.org/html/draft-ietf-grow-simple-va-04
> 
> 
> There may be hope yet.

IMHO, the following draft is much more beneficial:
http://tools.ietf.org/html/draft-uzmi-smalta-01

SMALTA can be implemented completely local to a one router, several routers or 
all routers -- the whole point is that:
   i)  the SMALTA algorithm is supposed to be designed to ensure FIB 
correctness, at all times, without any neighbors knowing.
   i)  to say it again: there are no protocol changes or configuration changes 
to existing protocols -- although, arguably, you may want knobs from your 
vendor(s) to tweak the interval at which the "one-shot aggregation" occurs.  
Most of the time, SMALTA attempts to use the least CPU time in order to 
calculate an 'optimal' version of the FIB every time it sees UPDATE's & 
WITHDRAW's in the RIB.  Over time, this results in a FIB that deviates anywhere 
from a few % to, perhaps, 20% of what you could optimally achieve (based on 
theoretical modeling by the draft's authors), which is why you want it to 
periodically run "one-shot aggregation", to get back to the most optimal 
version of the FIB.  IMO, it sure would be nice to have a prototype 
implementation of SMALTA to stick in an actual network and see how well theory 
holds up to practice.  :-)

With respect to S-VA, it appears you would need to play games with carrying 
either a default route or less specifics (aggregates) with NO_EXPORT, etc. 
around your network and having the potential to accidentally leak them beyond 
your network.  However, what's more concerning is clearly some prefixes (more 
specifics) are going to be responsible for carrying *a lot* of traffic, (think: 
popular CDN's, portals, etc.), which you want to ensure are optimally routed.  
The problem is, AFAICT, S-VA makes you identify _and_ maintain those 'popular 
prefixes' on your own to ensure that you optimally route them.  In theory, one 
might use Netflow to periodically determine and adjust the list of "popular 
prefixes", but what happens when you experience a sudden influx of traffic?  
How fast are you going to be able to react?

-shane
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to