[quagga-dev 9626] Re: [PATCH RFC] OSPF vertices memory exhaustion

Joakim Tjernlund joakim.tjernlund at transmode.se
Fri Aug 3 18:20:36 BST 2012


Paul Jakma <paul at jakma.org> wrote on 2012/08/03 17:28:51:
>
> On Fri, 3 Aug 2012, Paul Jakma wrote:
>
> > Actually, I know why we have to do the W->V check at this stage, because W
> > can be connected by both an invalid V->W and other valid, non-root-parent
> > ones. SPF next will filter out exploration of Ws via the invalid links, but
> > when it finds Ws via valid ones, the nexthop calculation will still run
> > across the invalid ones when trying to find the correct one. I think that's
> > why this is so.
>
> Ah, I wrote the above after the below:
>
> > To really make this code follow the spirit of the RFC, nexthop-calculation
> > shouldn't have to worry /at all/ about back-links not being found. The
> > higher-level spf_next function should have filtered those out.
>
> So I think it's just because spf_next has lost the backlink context.
> Perhaps it might be possible to:
>
> - extend ospf_lsa_has_link take the link from V->W under consideration
>    as an argument
> - return the backlink that matches that link, in a form suitable
>    to be passed on to ospf_nexthop_calculation, so that it doesn't have to
>    replicate that.
>
> I think it could be a lot of work, if it's possible. Unfortunately, it
> could also be that the apparently simple language of the RFC simply hides
> a lot of detail that's just hard to consolidate. I remember I tried to do
> at the time, but couldn't, at least.

I think to it its hard to do too, it might be better/easier to just defer
to check to nexthop_calc because I don't think it is possible to find the exact
link in all cases so better to let nexthop_calc do it instead and possibly cheat when one
cannot find the exact link. Possibly one could have different return values:
0 - no link/nexthop fond.
1 - ANY link and nexthop found
2 - correct backlink and nexthop found.


 Jocke




More information about the Quagga-dev mailing list