[j-nsp] Summarize Global Table

[Shane Amante]

Robert,

You are correct that I was referring to "full VA" vs. "simple VA".  Having gone back, just now, and read "Simple VA", I'm still not convinced it's the better direction to go -- but, we'll likely have to agree to disagree, I guess.

On Oct 25, 2011, at 11:56 PM, Robert Raszuk wrote:
[--snip--]
>> 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.

Er, I'm not sure that's correct.  A SMALTA router would still receive a full RIB and calculate an overall Loc-RIB just like it does today; however, it's only during the final step of computing a FIB from either a BGP Loc-RIB or the implementation-specific/dependent view of the RIB that accounts for all source of routing information on the box, (e.g.: BGP, OSPF/IS-IS, etc.).


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

I don't buy this argument.  An implementation of a SMALTA-type router is, most likely, going to calculate a "optimal FIB" on it's RE/RP and *then* download it to the actual TCAM/SRAM/fwd'ing HW (line cards).  I don't see that as any more challenging to implement vs. Simple-VA.  If anything, both proposals are nearly identical in this regard -- both are (likely) either implemented at the point after either: a) BGP calculates a Loc-RIB and hands it off to a local Route Table Manager (RTM); or, b) inside an RTM as it's computing a FIB that gets will get downloaded from the RE/RP to the FIB on the LC's.  IMO, it's the size of the FIB in HW that will dictate at which point one chooses to put any change.  IOW, since IGP size (in well-design networks) is typically very tiny, putting this code in the RTM is probably not worth it, in the grand scheme of things, in which case doing it at the BGP Loc-RIB -> implementation-dependent RIB is more appropriate.


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

So, the above raises a question, which I found confusing in the Simple-VA draft.  Take the following from the 5th paragraph of Section 1 of the Simple-VA draft:
---snip---
   Core routers in the ISP maintain the full DFRT in the FIB and RIB.
   Edge routers maintain the full DFRT in the BGP protocol RIB, but
   suppress certain routes from being installed in RIB and FIB tables.
   Edge routers install a default route to core routers, to ABRs which
   are installed on the POP to core boundary or to the ASBR routers.
---snip---

There sounds like there's a contradiction in the above.  Specifically:
1)  Edge routers maintain the "full DFRT" -- presumably, "full DFRT" equates to a full DFZ, correct?
2)  "but [Edge routers] suppress certain routes from being installed in the **RIB** and FIB tables";
3)  If these are Edge routers (specifically, FSR's in the context of Simple-VA), how can one suppress routes in the RIB, yet be expected to pass a full DFZ view, in eBGP, to downstream CE's that /demand/ a full DFZ, (because those customers are multi-homed to several SP's simultaneously)?  If I were to hazard a guess, you presumably mean that the BGP Loc-RIB still maintains a full-DFZ; however, the router is suppressing routes during the step of pushing routes from the BGP Loc-RIB to an implementation-specific/dependent RIB view (i.e.: the RIB containing routes from not only BGP, but also other routing sources as well, e.g.: OSPF, IS-IS, etc.)  Hrm, sounds an awful lot like SMALTA … see above :-)


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

Oh, so you're instead saying that you want an operator to /manually/ configure the FSR's with one or more "VA prefix" and it's associated next-hop, to one or more FIR's, in order that the FSR's can then begin suppressing routes?  That might sound good in theory, but won't be tenable in practice.  :-)


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

And, this brings up the final point I'll raise on the subject.  Simple-VA seems to be bucking current trends in the industry of:
a)  Control Plane-only RR's; and,
b)  Reduced FIB-size "Core LSR's", cf: Juniper PTX, etc. -- clearly, some or all traffic from a FSR needs to 'hairpin' through a Core LSR to get to another FSR in the same POP, (depends on the amount of FIB suppressing VA-prefixes exist).

Of course, different strokes for different folks.  :-)

-shane