libospf.h is correct, imo.

It has a small set of #define's that are used by both ospf and ospfv3.

I agree with Michael that his proposed patch is the correct patch to fix
this issue.

donald

On Tue, Sep 29, 2015 at 10:13 PM, Martin Winter <
[email protected]> wrote:

> Michael,
>
> your patch fixes at least some of the issues (maybe all). Thanks.
>
> I’m rerunning the full OSPFv3 suite again with the patch and will know
> the details in another 24hrs.
> But looking good…
>
> For Paul and others questioning why this happens
> $ grep libospf.h *
> ospf6d.h:#include "libospf.h"
> ospf6_network.c:#include "libospf.h"
>
> So it seems ospf6d uses libospf.h.
>
> Now if this is a mistake, bad design or ok, is up to the community
> to decide.
>
>
> - Martin
>
>
> On 29 Sep 2015, at 6:06, Michael Rossberg wrote:
>
> > Martin,
> >
> > I did not have the chance to look at v6. Could you have a look whether
> the attached patch
> > fixes the behaviour?
> > Thanks
> >
> > Michael
> >
> >
> >
> >
> >> On 29 Sep 2015, at 13:23, Martin Winter <[email protected]>
> wrote:
> >>
> >> Found the bad commit. This is the source of at least 3 of the OSPFv3
> failures
> >> (I have not verified it for all to save time)
> >>
> >>
> >> commit 2ef762ed9b88e5745012c5829f8f526c95443ddf
> >> Author: Michael Rossberg <[email protected]>
> >> Date:   Mon Jul 27 07:56:25 2015 +0200
> >>
> >> ospfd: Fast OSPF convergence
> >>
> >> When considering small networks that have extreme requirements on
> >> availability and thus convergence delay, the timers given in the OSPF
> RFC
> >> seem a little “conservative”, i.e., the delay between accepted LSAs and
> the
> >> rate at which LSAs are sent.  Cisco introduced two commands 'timers
> throttle
> >> lsa all’ and 'timers lsa arrival’, which allow operators to tune these
> >> parameters.
> >>
> >> I have been writing a patch to also support 'timers lsa arrival’ fully
> and
> >> ‘timers throttle lsa all’ (without the throttling part) also in quagga.
> >>
> >>
> >> Not sure how this affects OSPFv3. (Maybe lib/libospf.h is used by
> OSPFv3 as well?)
> >>
> >> I’ve added one of the failing tests (ANVL-OSPFV3-8.9) to the limited
> set which
> >> I run on every commit and restarted the test for proposed and accepted
> branch.
> >> (see https://ci1.netdef.org/browse/QUAGGA-QMASTER2/latest for results
> on
> >> accepted/3 branch)
> >>
> >> - Martin Winter
> >> [email protected]
> >>
> >>
> >>
> >> On 27 Sep 2015, at 3:34, Martin Winter wrote:
> >>
> >>> Full compliance run is done for the accepted patches @ commit d3ac733
> >>>
> >>> Most of it looks the same as the last release.
> >>> With the exception of OSPFv3, approx 4 results have changed:
> >>>     - new ISIS Ipv6 failures: ISISV6-26.2 & ISISV6-28.3
> >>>     - OSPF-12.4 now unpredictable (inconsistent results, was good
> before)
> >>>     - OSPF-24.6 now fixed.
> >>> I’ll analyze them on monday to make sure they are real issues.
> >>>
> >>> OSPF IPv6 on the other side looks much worse.
> >>> Comparing to Git master @ 6064613 (2015-08-04), we have approx 20 new
> >>> failures. (and I have not yet looked at the specifics either)
> >>>
> >>> Here is a quick list of the tests which now fail:
> >>>
> >>>                     Quagga     Git Master   Git Master   Git Master
> Git Accepted
> >>>                     0.99.24
> Round-3
> >>>                     f191f1e     f1fc327      55cfa2f      6064613
> d3ac733
> >>>                   2015-03-02   2015-05-14   2015-06-03   2015-08-04
>  2015-09-24
> >>>
> >>> ANVL-OSPFV3-8.9    MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-16.5   MUST   UNPREDICT      pass      UNPREDICT
>  pass        FAILED
> >>> ANVL-OSPFV3-16.14  MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-16.15  MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-16.16  MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-17.1   MUST   UNPREDICT      pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-18.1   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-18.23  MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-20.1   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-24.1   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-25.3   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-25.4   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-26.5   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-26.10  MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-28.6   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-41.2   MUST   UNPREDICT    UNPREDICT      pass
>  pass        FAILED
> >>> ANVL-OSPFV3-43.6   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-43.7   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-43.8   MUST     pass         pass         pass
>  pass        FAILED
> >>> ANVL-OSPFV3-43.9   MUST     pass         pass         pass
>  pass        FAILED
> >>>
> >>> For details (and some basic test description), see PDF on
> >>>
> https://drive.google.com/file/d/0B9on53yIVRYVNnQzY3lBbGI1WEU/view?usp=sharing
> >>>
> >>> I’ll do some git bisect on monday and look into the details, but if
> someone wants to
> >>> guess which commits in the accepted branch may break OSPFv3, then
> please let me know.
> >>>
> >>> - Martin Winter
> >>> [email protected]
> >>>
> >>>
> >>> On 26 Sep 2015, at 1:31, Martin Winter wrote:
> >>>
> >>>> I’ve noticed that Paul (I assume) started a branch for accepted and
> rejected patches.
> >>>>
> >>>> I’ve added the branch with the accepted commits to the CI system
> >>>>
> >>>> https://ci1.netdef.org/browse/QUAGGA-QMASTER and then select the
> branch next to title.
> >>>> You should see the “volatile-patch-tracking-3-accepted” branch there.
> >>>>
> >>>> Whenever a new commit is pushed, it should get kicked off
> automatically. (But with some delay
> >>>> as our git mirror only syncs up to savannah every hour).
> >>>>
> >>>> At the current time (at commit d3ac733) it passes the build and the
> basic compliance tests.
> >>>>
> >>>> Disclaimer: the —enable-werror is NOT yet pushed and not specifically
> selected in my build,
> >>>> so warnings won’t fail the build at this time.
> >>>>
> >>>> As it currently passes the basic checks, I’ve kicked off a full RFC
> compliance run for it.
> >>>> I will have the results by Sunday evening latest.
> >>>>
> >>>> Regards,
> >>>> Martin Winter
> >>>> [email protected]
>
> _______________________________________________
> Quagga-dev mailing list
> [email protected]
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to