On Tue, 19 Apr 2016, David Lamparter wrote:
On Tue, Apr 12, 2016 at 12:58:44PM +0100, Paul Jakma wrote:
- Makes the SPF behaviour configurable with a
"compatible max-metric (infinite|follow)"
The default state of this seems to be "infinite", which is not
RFC-compilant behaviour. There was unanimous consent in the monthly
meeting that RFC-compliant behaviour should be the default.
This is behaviour we've had for 9 years. Further, the existence of the
H-bit proposal shows it is also desirable behaviour.
If we change the default without warning, you go from "no transit traffic
(and maybe loops >1-hop away from the router, or blackhole for a
neighbour, in a mixed environment - whether this + "no-transit" is worse
than "no loops, but transit" for any given admin we can't know).
We've been very conservative about changing defaults in the past. E.g.,
we've still not been able to change the link-detect default, based on
your concerns there might be some (broken) setups out there that
relied on this.
So, given that + the 9 years we've had this behaviour, we can be
conservative on changing this one too, and do it by adding a flag + config
option but leaving the default (and always writing out the state). Then in
some future release, when H-bit is out there, flip.
Note that the H-bit has the pretty much the exact same compatibility issue
(though, with the other sense - same consequences in mixed envs though),
but the OSPF WG is advancing that to standards track anyway. Plus, we know
of one bug report in those 9 years.
So, it's not critical, and we can come up with a sensible transition that
is flexible for everyone's needs and minimises further breakage.
I also have the following review comments:
- I could not find a rationale for above new command in either the patch
description or inline comments.
There was documentation in the patch that should explain it. What
specifically was missing?
I do not see the utility of the
config switch, since:
- in a mixed domain of Quagga and other implementations, SPF is
already broken with possible loops. The negative impact of fixing
ospfd's behaviour may change a network from "broken in one way" to
"broken in another way", but the compat switch can't add any
guarantees.
- for a pure Quagga domain, there already is an easy migration path by
configuring 0xfffe instead, as you've pointed out. The
administrative effort of this is no lower or higher (ensuring proper
configuration on all routers) than the new switch.
Again, the admin may really want "no-transit".
So, since the proposed new switch adds complexity without providing any
benefit, it should not be implemented.
So, in the future, it will be possible to signal "no transit" and "transit
discouraged, but still acceptable" in standards-conformant OSPFv2.
If we want to expose that to administrators, we need a UI for it. I'm open
to suggestions on what should be. Adding a "transit" flag to get
"max-metric router-lsa [transit]" seemed sort of reasonable, but suggest
something else.
This UI question is completely independent of the question of the SPF
behaviour and the defaults there.
Are you against allowing the admin to configure whether OSPF should signal
whether transit is or is not allowed, when possible?
- H-bit support, while related by topic, should probably be split of
into its own separate patch.
Yes, it could easily be. Was useful to do it as one patch initially.
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
non-redundant fan failure
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
