[c-nsp] BGP DFZ convergence time - FIB programming

[Robert Raszuk]

> There is nothing to stop me creating a horribly complex iBGP policy

Decent bgp implementation should not allow iBGP learned routes to be
subject to any bgp policy as doing so will easily result with inconsistent
routing. So on this ground there can be bgp code path differences on how
the routes are processed.

But if you have accept all policy for eBGP without any inbound
modifications (match/set) then iBGP vs eBGP should indeed be pretty
similar. Other processing ie. best path selection, rib insertion then fib
insertion should be quite similar timing wise regardless of the type of the
route.

Thx,
R.






On Thu, Oct 11, 2018 at 10:38 PM James Bensley <jwbensley at gmail.com> wrote:

> On Thu, 11 Oct 2018 at 15:30, Robert Raszuk <robert at raszuk.net> wrote:
> > I think the difference Mark may have in mind that iBGP routes say from
> RR are advertised from RR's control plane. Many RRs today are just x86
> control plane boxes with no forwarding.
> >
> > On the other hand number of implementations before sending route over
> eBGP must make sure that those routes are installed in data plane locally
> before being advertised.
> >
> > Of course non of this really matters if those routes are already
> installed when you trigger advertisements to UUT.
>
>
> Hi Rob, Mark,
>
> So that's not really an apples to apples comparison then. Are you
> interested in seeing the different in vRR vs. physical RR vs physical
> PE?
>
> > There are also few more little "delays" for eBGP vs iBGP depending on
> your BGP code base - regarding policy processing or origin validation :).
>
> There is nothing to stop me creating a horribly complex iBGP policy so
> I'm not sure policy length that is a factor. I was referring strictly
> to the code performance, e.g. router model A, with firmware version B,
> receives the exact same route set from an eBGP and iBGP neighbor (and
> those two neighbors are the exact same spec). Is there till scope for
> a difference in convergence time here?
>
> Cheers,
> James.
>