[j-nsp] Summarize Global Table

[Robert Raszuk]

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.