On Wed, 20 Apr 2016, Lou Berger wrote:
To up level a moment: to me the most important thing is to keep
fixes/improvements rolling into the quagga base and not let a single
patch block overall progress on improving the code base. I liked the
idea of proposed branches floated awhile back on the list (don't recall
who sent it) but any approach that brings in patches would be good.
We were doing that. Rounds of integration.
Kicking off the latest round seems to have stalled. Not sure why.
the whole project, then I think it's better to accept *something* and
move on, then to argue about what is *optimal* -- which I think we're
not going to agree on.
See my reply to Martin.
If the routing loop issue is serious, then we should take it seriously.
And the prior patch just flips the SPF behaviour and doesn't provide a
config option. So in the interim, it might just increase the number of
networks that see this issue.
If it's not serious at all, then it still needs config options (first
patch was missing those), and also it's worth bearing in mind that H-bit
is on the horizon, and see if we can wait for that.
Either way, THE PREVIOUSLY SUBMITTED PATCH WAS **NOT SUITABLE**.
(And Cumulus were extremely slow in engaging on comments on that patch -
I'm sure it's been over a year since I first tried to have a dialogue
about that patch with them).
So this is where I think we're going to disagree. I just don't see
folks operating their networks with max link cost in the normal case, so
I'm not really too concerned about the old Quagga routers. I accept
this is a matter of perspective, and unless an operator/user stands up
and starts arguing this -- I suspect we're going to continue to
disagree.
I agree with you. I don't think it's a major issue at all generally.
Others raised concerns that it could be though. So, even on mixed networks
that have topologies where this loop is *possible*, I suspect it's rare
it's ever an issue. However, /if/ it's an issue, I could agree it'd be an
annoying one ("Hmm, why are my switches melting?").
As I said above, I think getting *a* fix in for this, and getting code
base moving is more important than getting the default "right" -- again
just one opinion.
That's great. But if it's not an issue, there's no issue in disregarding a
patch that lacks the config option, and then waiting for one that does
have it (which now exists).
It's potentially also not an issue - given how long Quagga has had this
behaviour - to wait for H-bit.
As long as the H bit usage follows the latest WG draft -- no need to
introduce something quagga specific here...
H-bit support would be fully conformant, in the sense it would be acted on
regardless of the 0xffff SPF compatibility setting. In the patch I sent.
this is the crux of disagreement - I think you're proposing going
through a lot of work for a set of corner-case users that don't exists
(those who run quagga and today use max cost in every day stable
operations.) Maybe I'm wrong and my perspective is influenced by
non-quagga usage.
Well, I've had people telling me how bad routing loops are, and won't
someone think of the routing loops! (humour), so forgive me if I went and
took those concerns seriously.
It's frustrating to have to deal with ever shifting concerns. At a purely
logical level, if routing loops are an issue then the first Cumulus patch
was insufficient and more work was needed; if not such a huge issue, then
what is the issue in setting it aside and taking the time to see if both
current Quagga and "transit OK" behaviour could be accommodated together
(and the Quagga behaviour is actually useful - a standard is proposed to
allow that behaviour to be signalled)?
The responses I've had do not make logical sense to me. Particularly
viewed in the context of how we've treated other interoperability/default
issues (interoperability with system configuration like link-default; or
with RFCs, like the RIP auth bug of ages ago, or this).
Apparently the issue is serious enough that WE MUST APPLY A PATCH! So
urgent, we must apply one that /extends/ the issue that is so concerning
to further networks in the interim, but we don't have to look at patches
that try minimise that and make it configurable cause the issue isn't
serious.
Baffling really.
I suspect it (stable usage of max cost) is rarely used so am really just
arguing against all the extra work (and time) to get to same end state.
Max cost would be used for limited windows of time. The concern seemed to
be those windows can be long enough for routing loops to be nasty.
Again, IMO it would be better to get *something* in that allows either
operation under config control while we/whoever wants continues this
debate on the default behavior...
Agreed.
****There is only 1 patch that adds config options***!!!!!
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
BASIC, n.:
A programming language. Related to certain social diseases in
that those who have it will not admit it in polite company.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
