Hi Paul, Thanks for the response.
Top post/main point first (sorry): 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. Why am I saying this? Because if this one patch is blocking progress on 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. If interested, see below for specific responses. On 4/20/2016 6:25 PM, Paul Jakma wrote: > 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. excellent -- then I I think we agree on the most important part of this discussion. >>> * 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. 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. 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. > 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. A user can always choose to this on their own. >>> * 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). As long as the H bit usage follows the latest WG draft -- no need to introduce something quagga specific here... > "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? 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. > 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. 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. I think we understand each others positions at this point, and should just agree to disagree on how to get to the same end point. 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... Lou > regards, _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
