Hi Shane, As author of simple-va idea in the current form -04 version let me explain few points you have brought below:
SMALTA can be implemented completely local to a one router, several routers or all routers
Exactly same case with simple-va. -- 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.
Same for simple-va
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.
SMALTA if I understand it operates at the FIB level. Simple-VA is a pure control plane intelligent suppression between BGP and RIB. I wonder how many vendors will want to do any code modifications at the FIB level if exactly the same savings can be done at the control plane level ....
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.
That's already much more then needed. With simple-va suppression you do not need even to send routes to RIB and FIB at all if they are suppression eligible. So not only FIB size is small, but also RIB (both CPU and memory wise).
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. :-)
It has been proven that simple-va real and shipping implementation is semantically identical from forwarding point of view as full table download and installation.
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.
Completely not. The NO_EXPORT is in the draft just as a BCP in case you want to inject the default. The default injection or for that matter any aggregate injection are completely not required.
Once you enable the functionality router finds more specifics of any less specific which are eligible for suppression and does not send them to RIB. It also walks back the table in case non eligible for suppression more specific with different next hop get's installed. (That is default behaviour and recommended in the AS wide suppression case. For POP suppression when POP to core boxes carry and install full routes this is not needed).
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.
Simple-VA assures optimal routing of _all_ prefixes by default
The problem is, AFAICT, S-VA makes you identify _and_ maintain those 'popular prefixes' on your own to ensure that you optimally route them.
You are absolutely confusing VA with Simple-VA based on the previous draft readings. Indeed in the earlier versions of simple-va document the functionality was not described to reflect real feature behaviour which I have envisioned. Now this is corrected.
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?
Again there is no notion of any concept of "popular prefix" in simple-va-04 document.
Many thx, R. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
