[j-nsp] Summarize Global Table

[Robert Raszuk]

Hi Shane,

First I would like to actually thank all who provided some points reg 
simple-va during the discussion since yesterday.

By all means I agree in some concerns expressed if additional CPU or 
RIB/FIB installation times for possibly batches of more specifics in 
relatively short time window caused by the trigger would be something 
definitely worth of measuring. However it very much depends on how 
simple-va are deployed, what is the network, what is the device etc ... 
therefor I do not have any measurement to share. However this has been 
tested in production network and gain reported in memory saving has been 
very significant.

Now back to the specific questions ...

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

In number of routers RIB is IPC-ed and kept on the linecards. So you are 
either proposing to redesign those platforms or running SMALTA on a line 
cards.

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

Sorry but this is not always the router's architecture especially if you 
are talking about hardware based forwarding.

In software based routers I could perhaps agree that the difference in 
the point of processing becomes not that different.

> I don't see that as any more challenging to implement vs. Simple-VA.

See above. It is much much easier and simpler to do it in BGP then to do 
it in any lower component. Especially that all you are after is to 
"compress" the BGP routes.

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

Yes this is exactly what smiple-va does.

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

So we agree provided SMALTA does not require full RIB as input not size 
wise but algorithm wise.

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

Yes. Sorry just reused some terms from main VA spec.


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

That is exactly that. BGP still has full table. Only RIB and FIB have 
only necessary subset.

> Hrm, sounds an awful lot like SMALTA … see
> above :-)

Is it a good or bad thing. I think this is good think :)

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

No. On the pop to core boundary you inject default from your ABRs into 
the POP. Of course this works the best when your network is structured 
accordingly.

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

Nope. Completely not. I am not even sure how did you got to such 
conclusion that simple-va is bucking the lean core.

The typical design is to interconnect POP to core ABRs with MPLS LSPs 
and not to extend full mesh of TE LSPs between your 1000s of PEs.

However this is orthogonal to simple-va. Simple-va is local and works in 
it's default mode equally well on the edge or in the core.

However if you would like to use cheaper boxes on the edge I have only 
provided a way how constructing a POP may allow for even further and 
better savings on the edge or possibly extra CPU reduction cycles.

Many thx,
R.




>
> -shane
>