On Thu, 21 Apr 2016, Lou Berger wrote:
If the routing loop issue is serious, then we should take it seriously.
I know we disagree on this -- I personally see loops with standard
routers as a bigger deal as the loop can introduced on a change on the
standard router,
while in the quagga only case we can document the issue (either use fffe
0xfffe is the signalling side. It means 'new Quagga' wouldn't cause a loop
anywhere if it went stub-router and sent that.
However, on the receiving side, flipping the SPF behaviour default now
/introduces/ the potential for loops on networks that do not currently
have this. Those might be Quagga-only networks, but even currently mixed
networks could go from "no problem" to "problem". We are agreed instances
of the problem should be quite rare, but also agreed routing loops are
bad. Ergo /if/ this can be avoided, it should be, to my mind.
The admins that are most likely aware of this issue, are any admins who
have seen this issue. We should err on the side of having them take
configuration action - at least initially - rather than putting that onus
on the unaware ones.
We can ship a Quagga that will at least write out a new flag to
'running-config' that might catch the notice of the latter set of admins.
If they're curious they can look in the docs. Further, it will be written
out. That version of Quagga can at least continue to work just fine with
old Quagga, by default, in all cases. That version can lay the ground-work
for awareness of the issue, and changing the default in the future.
or the new config option, if present -- not sure where would be the best
place, perhaps the ospf manual section?) and inform the quagga users
about the risk.
My patch updated the ospfd.texi docs, and tried to explain the trade-offs.
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),
I like the config option, but given a choice between conformant and
no-config, I'd take the former for the reasons as above.
With all due respect, that's a false dichotomy. That is not the option.
and also it's worth bearing in mind that H-bit is on the horizon, and
see if we can wait for that.
I think is a reasonable, but not necessary feature to support.
Sure, agreed.
However, /if/ H-bit is coming along soon, then H-bit potentially help
reduce the interoperability concerns.
If those concerns are serious, then we should seriously evaluate things
that can reduce that risk.
If not, then we have plenty of time anyway, and perhaps we don't need such
a heated thread on this.
Either way, THE PREVIOUSLY SUBMITTED PATCH WAS **NOT SUITABLE**.
I accept that it may not have been optimal, but I think this is just one
perspective.
It needs a config option. Come on.. If routing loops are such a serious
concern, then we shouldn't risk screwing over existing networks. Sometimes
there are devices that can't be upgraded easily.
yes loops are bad. The possibility of changing a config on a major
vendor router, e.g., cisco or juniper, and having the network melt due
to quagga non-conformance (which is likely to be viewed as a bug by
most) would be *really* bad for quagga- IMO...
Aha. So now it's a serious issue again? :)
Similarly, if we update Quagga with just the flipped SPF default, and an
admin starts rolling out a new Quagga and /that/ triggers the melt-down -
that wouldn't look good either, would it?
And note that even a mixed-network today might not be at risk with
old-Quagga, but then be at risk if some Quagga were upgraded with an
SPF-flip and others were not (e.g. cause they can't be cause of vendor
updates or whatever).
Try leave the sleeping dogs to lie, while dealing with just the one that
is barking.
I think we're both repeating ourselves at this point - so let me up level:
1) how do we move forward on the max cost behavior
I'd like to find a way that minimises adding problems.
I was actually persuaded by Donald the routing-loop issue was serious.
However, given that, given previous conservativism on behavioural changes,
and talking to Alvaro Retana (stub-rfc author), made it clear the
transition from old to new probably then would also need to be managed -
not just flipped.
Within those constraints, my feeling is the SPF default change should be
staged over time and at least 2 releases.
I'm happy to split out that from the first draft patch I submitted, credit
the Cumulus patch, and have that go in with SPF behaviour staying as is,
and max-link-metric sending 0xfffe.
Further, given OSPF WG seem to be standardising signalling for the
/current/ Quagga behaviour anyway. It may be prudent to avoid churning
that aspect of our behaviour, and just wait for the H-bit. It's not a
necessary feature of course, but anyone using stub-router today in Quagga
will be used to the "no-transit" behaviour that H-bit is being
standardised for.
I'm going to be somewhat stubborn on the default question.
I've been berated for not taking a serious issue seriously enough, even
though we're only here cause I *did* take the issue seriously, and agreed
it could be serious. Then somewhat berated for taking it too seriously,
even though it is still serious. I really don't know how to collapse that
particular wave function to the nuanced point on the seriousness spectrum
which others can see. So, I'm just going with 'serious' on a binary
'serious-or-not' scale. Which, to me, means it should be staged.
I'm flexible on the H-bit issue. However, if we leave that for later, note
that a series of changing behaviours wrt stub-router support over time can
also be quite annoying to users. That should also be avoided, if possible.
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
The only constant is change.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
