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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
