On Wed, 20 Apr 2016, Lou Berger wrote:
I know. That's why I said:
I like the change of being able to work in the standard and non-standard
modes. I think the only part we really are disagreeing on is default
behavior.
I don't disagree on the default behaviour either, ultimately. As the
commit message said, the aim is to get to a point where there's no
issue in changing the default.
* Flipping the SPF default behaviour will *not* get rid of routing
loops, cause now you get the interoperability problems with new Quagga
and the *old* Quagga.
I don't see this. in the case the new routers will need their config
flipped to the non-standard mode before setting max met.
We're talking about the default. The default comes into play when we're
talking about the case where the admin isn't aware. So, the admin tuning
the configuration knobs is irrelevant in that case (then it's their
responsibility and we're OK).
There's 2 possibilities in terms of the networks:
1. Quagga only networks
2. Mixed networks
Case 1 can not have routing loops today. If we just flip the default SPF
behaviour, then networks with old and new Quagga become at risk of
routing loops.
Case 2 can have routing loops today. If we flip the SPF default, then we
may things between new Quagga and non-Quagga 2328 speakers, but there's
still the issue of the old Quagga speakers.
Note, we can also change the sending behaviour in new Quagga to use
something other than 0xffff (e.g. 0xfffe), that will universally signal
the "transit OK" desired behaviour to all OSPF speakers (2328, old,
new). Doesn't fix the case where an old Quagga or another 2328 router
uses 0xffff.
* There is at one potential way that will give wider interoperability
than just flipping defaults.
can you elaborate on this?
If we can use the H-bit, then we will reliably have a way to signal and
distinguish both "no-transit" and "transit" in an ultimately standards
conformant way, and in a way that can also interoperate with old Quagga
(in an environment where interop with old Quagga is preferred over 2328;
which can be configurable).
"no-transit" we would be able signal with H-bit + 0xffff (0xffff is
required with H-bit). And we could reliably distinguish the H-bit, and
configurably recognise 0xffff.
"transit" we can signal in a universal way.
Assuming H-bit is a goer, that means we could roll out H-bit first,
while leaving the default behaviour. This would have no impact on the
Quagga-only networks. It would also work without any issues on networks
with old Quagga, new Quagga and other implementations that supported
H-bit (and note that you want "recognise H-bit" support enabled in those
other implementations, all across your network at the same time, or
you'll have the exact same SPF routing-loop minor-risk that we're trying
to fix in Quagga).
That's an interoperability improvement over just flipping the default.
So:
Stage 1:
- Get the configuration knobs out there
- Get the UI knobs out there so admins can at least indicate what their
intent is regarding "transit discouraged, but OK" v "no transit".
(Assuming we can rely on H-bit being standardises - in which case,
we'd want to support it, right? And we'd need some UI for it..)
- Write these settings out explicitly, so the admin is more likely to
see them, and so they're more likely to end up in configs. (as we've
done for other noticable behaviour changes)
- Get the new Quagga to use H-bit so releases from them on will be able
to reliably signal what they want, in standards conformant ways (H-bit
0xffff; versus just 0xfffe link-metrics)
Old and new Quagga will then work for all cases. New Quagga will also be
able to signal 'transit' in a way that works with all routers, inc 2328
(but not distinguish for receive; that will default to compat with old
Quagga, but configurably), and also to all H-bit routers for
'no-transit'.
- Wait, hopefully in time admins have upgraded and there's fewer old
Quagga about.
- Change the SPF default. New installs will now also interoperate with
2328, as will admins who havn't saved configs, and admins who have
changed.
Just flipping the default though doesn't make complete sense, if the
concern is routing loops - cause that's just shifting the problem from
"Quagga and others" over to "old and new Quagga". And, who knows, it
could be a bigger problem for the latter than the former class - maybe,
maybe not.
So, I'm a bit frustrated by the flaggelation over "Won't someone
think of the routing loops?!!", while pushing for a fast default change
that just pushes the bubble around potentially. If there was a problem
for one set of users, and if it's possible to fix it *WITHOUT* creating
problems for another, how about we do that?
The way to manage this is to get the configuration knobs out there
first, and be a bit slower on the default change, surely?
And again, this is likely a rare and mostly minor risk. 9 years. One bug
report.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Authentic:
Indubitably true, in somebody's opinion.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
