[quagga-dev 15107] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On 20 Apr 2016, at 7:41, Paul Jakma wrote: On Wed, 20 Apr 2016, Daniel Walton wrote: If you are not willing to say "ok I disagree with the quagga community but I am going to accept this patch anyway" then the reality is that it is your word no matter what. As far as I know, the community also wants significant behaviour changes to be handled in a staged way. The community has a split-brain on that. I can’t remember this to ever been asked for a bug fix. It was discussed about changing defaults a few times. And in all cases, none of the choices on defaults violated RFCs. - Martin ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15106] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
Paul On 19 Apr 2016, at 15:37, Paul Jakma wrote: On Tue, 19 Apr 2016, Lou Berger wrote: IMO non compliance with requirement behavior of an RFC should be viewed as a bug and fixed. I just don't agree. We should what is pragmatic and best for our users. I agree with Lou. Non-Compliance of the RFCs should be seen as a bug and fixed. Only exception I can see is if various other vendors are non-compliant (by choice or accident) and we have to derivate from the RFC to avoid problems. This does not seem to be the case. In this case, QUAGGA seems to be different and causes the issues. No need to “migrate” a 9-year old bug. Let’s just fix it. - Martin Winter The vast majority of the time that may very well mean doing what the RFC says. However, if users' best interests are served by deviations, then that's what we should do. Whether it's cause some RFC behaviour is silly (not common, but not at all unknown either, by any means; be it just universally silly, or something that seemed a good idea X time ago but less so now), or whether it's cause we have a historical deviation and we now have to manage that, or whatever else. I bet with a bit of digging I could find a behaviour deviation somewhere in Quagga that people would object to changing. E.g., our BGP decision process does not comply with RFC4271, for one thing, AFAIK. The "prefer the older route" step is non-compliant I think, and causes bgpd to calculate different best routes to the RFC behaviour in some cases. Shall we remove that then? Also, on this particular OSPF one, see below... I'm fine having config support for 'non-standard' modes of operation, but they shouldn't be default and be clearly be labeled as likely to break interop (e.g., by introducing routing loops) with standards complaint implementations. The OSPF WG has a draft RFC, adopted for it to try progress to standards track which *standardises the exact same routing loop risks in mixed environments*. Even if we change Quagga tomorrow, there will still be old Quagga routers out there, and even when they get updated, there'll be more and more routers supporting H-bit (Quagga or not), and operators will face *the exact same trade-offs* - and completely outwith our control. So, please, can we keep a sense of perspective on this? :) The patch I sent leads to these interoperability concerns and this potential transition plan: https://mailarchive.ietf.org/arch/msg/ospf/UwvoWeOv6GS51_sLjMVTdW-A9rY Which the OSPF WG chair has indicated is reasonable. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15105] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
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 0x (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 0x. 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 + 0x (0x is > required with H-bit). And we could reliably distinguish the H-bit, and > configurably recognise 0x. > > "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
[quagga-dev 15104] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
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 0x (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 0x. * 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 + 0x (0x is required with H-bit). And we could reliably distinguish the H-bit, and configurably recognise 0x. "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 0x; 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 most
[quagga-dev 15103] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, Apr 20, 2016 at 04:13:13PM +0100, Paul Jakma wrote: > The application I developed it for. Being able to take down routers in a > staged way [...] > The OSPF WG is actually standardising behaviour for that. It's useful > enough they've re-allocated a previously allocated and very precious > OSPF option bit for it. Mhm... things got mixed up somewhere. The OSPF WG is pushing along the H-bit for systems that want the OSPF topology (and have more than 1 link), but can't/shouldn't route traffic. That's primarily BGP Route Reflectors, some MPLS/PCE stuff, and VM-hosts hosting/routing previous two things as service. I remember some discussion at an IETF meeting (I think it was @ 93; last time the draft had a presentation slot) whether this is also for taking routers out of service. The result was "no, 6987 / 0x remains for that", with the rationale of "if the last path to some prefix is through that router, it should still be reachable, making the problem apparent to an administrator or automated NMS looking at the LSDB / SPF result, without/before causing actual breakage." This is also reflected in RFC 6987's and draft-hbit's introduction sections; 6987 does list disabling a router while draft-hbit doesn't. The two are really quite orthogonal in applicability. -David ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15102] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
Paul, On 4/20/2016 1:24 PM, Paul Jakma wrote: > On Wed, 20 Apr 2016, Lou Berger wrote: > >> Given the points above, I think there is strong reason to have the >> default be the interoperable/standard setting and have a config >> parameter to enable the non-standard maintenance mode. > Adding a config option is *exactly* what that patch-set is doing. 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. > To quote from the commit message again: > > " If and when the H-bit is widely recognised, and has been deployed in >Quagga for long enough, we may be able to change the SPF behaviour >default to the standards behaviour of "follow". " > > Step 1 is getting the config option in, and documenting the issue, and > writing out the config explicitly, and getting it in a release. > > Step 2 is to wait for N time and/or M releases. > > Step 3 is to change the default. > > We've had to do this before. The time is easily negotiable. > > How to handle defaults and significant changes in behaviour is also > negotiable. However I'm going to get a bit grumpy if I start to get > personal comments, I can't speak to others, but I certainly hope hope tone hasn't come off as personal - and please let me know if it has and I'll certainly apologize publicly. > just because I've followed precedent on how such > behaviour changes are done in this patch. > If the concern is routing loops, then just flipping the default on the > SPF behaviour *also* causes loops with older Quagga versions. > > Let's calm tfd, stop personalising this, and just manage the problem at > a technical level in a way that minimises issues for users. > > * 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. > * There is at one potential way that will give wider interoperability >than just flipping defaults. can you elaborate on this? > * This has been like this for 9 years, and there's been 1 bug report >AFAIK. > > I can think of lots of technical discussions on this, e.g. whether or > not we can wait for the H-bit. What should the UI be for the "transit" > and "no-transit" cases, etc. > > How about we have those instead? They'd be a lot more interesting. I'm not sure what you're proposing here. Lou > regards, ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15101] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, 20 Apr 2016, Lou Berger wrote: Given the points above, I think there is strong reason to have the default be the interoperable/standard setting and have a config parameter to enable the non-standard maintenance mode. Adding a config option is *exactly* what that patch-set is doing. To quote from the commit message again: " If and when the H-bit is widely recognised, and has been deployed in Quagga for long enough, we may be able to change the SPF behaviour default to the standards behaviour of "follow". " Step 1 is getting the config option in, and documenting the issue, and writing out the config explicitly, and getting it in a release. Step 2 is to wait for N time and/or M releases. Step 3 is to change the default. We've had to do this before. The time is easily negotiable. How to handle defaults and significant changes in behaviour is also negotiable. However I'm going to get a bit grumpy if I start to get personal comments, just because I've followed precedent on how such behaviour changes are done in this patch. If the concern is routing loops, then just flipping the default on the SPF behaviour *also* causes loops with older Quagga versions. Let's calm tfd, stop personalising this, and just manage the problem at a technical level in a way that minimises issues for users. * 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. * There is at one potential way that will give wider interoperability than just flipping defaults. * This has been like this for 9 years, and there's been 1 bug report AFAIK. I can think of lots of technical discussions on this, e.g. whether or not we can wait for the H-bit. What should the UI be for the "transit" and "no-transit" cases, etc. How about we have those instead? They'd be a lot more interesting. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Any excuse will serve a tyrant. -- Aesop ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15100] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
Paul, On 4/20/2016 11:06 AM, Paul Jakma wrote: > On Wed, 20 Apr 2016, Lou Berger wrote: > >> implementation. I think it's fine for quagga to do something >> non-standard, but it should default to standard/interoperable modes of >> operation. > The aim of the patch I offered is to move toward standards-conformant > behaviour, with the fewest interoperability problems, and the least > amount of behavioural churn. 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. > The whole point of it is to get to the place where we can change that > default while being sure it can _not_ impact any users running a network > with: > > - RFC2328 or old Quagga users, for the 'transit allowed' case > > - H-bit capable speakers or old Quagga users, for the 'no transit' case > > With config options to take care of the remaining cases. > > Objecting to this with "RFC Compliance!", without offering something > better than just flipping the default with no config option, is not very > useful. My objection is that by default quagga, causes interop problems (routing loops!) when talking to non-quagga (standards conformant) implementations -- i.e., all other vendors. I think this will be of greatest surprise to users. (loops are evil!) This is particularly true in this specific case as the there are no normal/stable cases where an operator would be using max cost on a link -- it's purely there as a maintenance feature. > Provide a better option than the 2 existing offerings, that'd help. Given the points above, I think there is strong reason to have the default be the interoperable/standard setting and have a config parameter to enable the non-standard maintenance mode. Lou > regards, ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15099] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, 20 Apr 2016, David Lamparter wrote: (If no, a realistic application scenario maybe?) The application I developed it for. Being able to take down routers in a staged way that allowed me to have confidence that if anything was going to break it would break while the router was still reachable. (VPN routers in branch offices). The "no-transit" way ensures that. It never occurred to me that some might still want transit (why bother with a 'special' metric value, if it wasn't actually meant to be special? just add any large value to all the links for that). The OSPF WG is actually standardising behaviour for that. It's useful enough they've re-allocated a previously allocated and very precious OSPF option bit for it. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: There's nothing to writing. All you do is sit at a typewriter and open a vein. -- Red Smith ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15098] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, 20 Apr 2016, Lou Berger wrote: implementation. I think it's fine for quagga to do something non-standard, but it should default to standard/interoperable modes of operation. The aim of the patch I offered is to move toward standards-conformant behaviour, with the fewest interoperability problems, and the least amount of behavioural churn. The whole point of it is to get to the place where we can change that default while being sure it can _not_ impact any users running a network with: - RFC2328 or old Quagga users, for the 'transit allowed' case - H-bit capable speakers or old Quagga users, for the 'no transit' case With config options to take care of the remaining cases. Objecting to this with "RFC Compliance!", without offering something better than just flipping the default with no config option, is not very useful. Provide a better option than the 2 existing offerings, that'd help. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a garage makes a person a car. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15097] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On 4/20/2016 8:36 AM, Lennart Sorensen wrote: >> So are you arguing this point theoretically, or do you believe there's a >> > real issue with *this* change. Said another way, do you really think >> > there are operators using an max link cost in normal/stable day to day >> > operations (and not just as a maintenance tool)? > I don't recall what this change is, so no idea. I am just saying in > general changing defaults in a program that doesn't keep default values > in the config file is hazardous. I don't think this is a case of changing defaults. In this *specific* case, it's a question of interoperable vs non-interoperable implementation. I think it's fine for quagga to do something non-standard, but it should default to standard/interoperable modes of operation. Lou ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15096] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, 20 Apr 2016, Daniel Walton wrote: the RFC on the intent of the RFC, etc. If you are not willing to say "ok I disagree with the quagga community but I am going to accept this patch anyway" then the reality is that it is your word no matter what. Balls, sorry. A patch was offered that just flipped long-standing behaviour over, and *COMPLETELY DISABLED* the existing behaviour. Behaviour which is useful enough that the OSPF WG is standardising this behaviour (with almost similar interoperability risks). I and Cumulus people, and OSPF WG people have worked together to try understand the impact of the problem, and the options. And note the issues are subtle enough that the stub-router RFC is actually wrong on whether routing-loops are possible. It turns out there is a path to standards conforming behaviour, which will work with old Quagga, which can minimise interoperability issues somewhat if we follow that path, minimise disruption to users (e.g. avoid needless churn in churning behaviour around), with configuration options so admins can cover the remaining cases. That path should also allow the default to be switched in time. I implemented that and sent it to the list, to supercede the earlier one. So yeah, I object to the earlier patch. But I think I've tried to do so productively, and in line with precedent on previous behaviour-flipping patches. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Every solution breeds new problems. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15095] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, 20 Apr 2016, David Lamparter wrote: If you disagree what the consensus is / how it is formed -- maybe you could elaborate on how that works exactly? Well, I know you and I have a different view of the meaning of 'consensus'. The meaning in Quagga is unanimity. I have respected your view when you disagree with me. I expect mine to be respected in turn. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Never keep up with the Joneses. Drag them down to your level. -- Quentin Crisp ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15094] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, 20 Apr 2016, Daniel Walton wrote: If you are not willing to say "ok I disagree with the quagga community but I am going to accept this patch anyway" then the reality is that it is your word no matter what. As far as I know, the community also wants significant behaviour changes to be handled in a staged way. The community has a split-brain on that. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: "It is hard to overstate the debt that we owe to men and women of genius." -- Robert G. Ingersoll ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15093] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, Apr 20, 2016 at 09:23:50AM -0400, Daniel Walton wrote: > On Wed, Apr 20, 2016 at 4:15 AM, Paul Jakma wrote: > > On Tue, 19 Apr 2016, Daniel Walton wrote: > > > > How does this work then...is it your word no matter how the rest of the > >> quagga community feels? That is certainly how it is coming across. > >> > > > > Someone disagreed with my patch, it isn't going in. How is that my word no > > matter what? > > > > I'm allowed to argue why that patch should go in, surely? > > > > I'm not saying that you or anyone else should not argue for something they > feel strongly about. My point was that the majority of the quagga > community feels that the current behavior is a bug and that we should just > fix it while you are in the opposite camp and havent' been willing to budge > on this despite a month of discussion, clarification from the authors of > the RFC on the intent of the RFC, etc. If you are not willing to say "ok I > disagree with the quagga community but I am going to accept this patch > anyway" then the reality is that it is your word no matter what. Indeed -- I think we've already had a discussion whose size is massively disproportional to the impact of the topic. Paul, is there a point where you accept the consensus? If you disagree what the consensus is / how it is formed -- maybe you could elaborate on how that works exactly? I'm in particular anxious to see a response & clarification on your previous statement of "The call doesn't decide the consensus." > We've been going back and forth on this since mid March. In that time we > (cumulus) have added 98 patches to our backlog of patches that we need to > upstream...we aren't making progress we are getting further and further > behind. +1, this backlog is a huge problem, where "huge" is defined as "endangering the future of the entire Quagga project." -David ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15092] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, Apr 20, 2016 at 08:36:04AM -0400, Lennart Sorensen wrote: > On Wed, Apr 20, 2016 at 07:37:12AM -0400, Lou Berger wrote: > > ahh - not necessarily -- particularly if it fixes a major interop issue > > (which is the point of standards after all). > > Well if you could fix the interop by changing a setting away from its > current default, at least you have a workaround. And I would think the > other value for the setting exists for a reason too. > > > So are you arguing this point theoretically, or do you believe there's a > > real issue with *this* change. Said another way, do you really think > > there are operators using an max link cost in normal/stable day to day > > operations (and not just as a maintenance tool)? > > I don't recall what this change is, so no idea. I am just saying in > general changing defaults in a program that doesn't keep default values > in the config file is hazardous. > > link-detect is still not on by default (and while I certainly always > want it on, I would not suggest changing the existing default behaviour.) The link-detect comparison keeps coming up, yet there's a major difference: When I argued for the "slow" link-detect migration, I was personally aware of 2 installations that would've been broken by the change, one of them /my own network/. Paul (or anyone else), is there an actual user installation you're aware of that would be broken by this change? If yes, could you please describe it? (If no, a realistic application scenario maybe?) -David ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15091] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, Apr 20, 2016 at 4:15 AM, Paul Jakma wrote: > On Tue, 19 Apr 2016, Daniel Walton wrote: > > How does this work then...is it your word no matter how the rest of the >> quagga community feels? That is certainly how it is coming across. >> > > Someone disagreed with my patch, it isn't going in. How is that my word no > matter what? > > I'm allowed to argue why that patch should go in, surely? > I'm not saying that you or anyone else should not argue for something they feel strongly about. My point was that the majority of the quagga community feels that the current behavior is a bug and that we should just fix it while you are in the opposite camp and havent' been willing to budge on this despite a month of discussion, clarification from the authors of the RFC on the intent of the RFC, etc. If you are not willing to say "ok I disagree with the quagga community but I am going to accept this patch anyway" then the reality is that it is your word no matter what. We've been going back and forth on this since mid March. In that time we (cumulus) have added 98 patches to our backlog of patches that we need to upstream...we aren't making progress we are getting further and further behind. Daniel ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15090] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Wed, Apr 20, 2016 at 07:37:12AM -0400, Lou Berger wrote: > ahh - not necessarily -- particularly if it fixes a major interop issue > (which is the point of standards after all). Well if you could fix the interop by changing a setting away from its current default, at least you have a workaround. And I would think the other value for the setting exists for a reason too. > So are you arguing this point theoretically, or do you believe there's a > real issue with *this* change. Said another way, do you really think > there are operators using an max link cost in normal/stable day to day > operations (and not just as a maintenance tool)? I don't recall what this change is, so no idea. I am just saying in general changing defaults in a program that doesn't keep default values in the config file is hazardous. link-detect is still not on by default (and while I certainly always want it on, I would not suggest changing the existing default behaviour.) -- Len Sorensen ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15089] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
Lennart On 4/19/2016 10:17 PM, Lennart Sorensen wrote: > On Tue, Apr 19, 2016 at 07:39:48PM -0400, Lou Berger wrote: >> Paul, >> >> You have a valid point on absolutes. One never should say never :-) >> >> That said, we're not talking some obscure feature here . Does any non-quagga >> based vendor, major or otherwise, support the non standard behavior as the >> default? If so , there may be some basis for this discussion. If not , and >> in my experience , then the current behavior should be viewed as a bug. >> >> Just one persons (my) opinion... > If upgrading from one version to another without changing anything in > the config causes a major change in behaviour, then that is a bug. ahh - not necessarily -- particularly if it fixes a major interop issue (which is the point of standards after all). > Especially since the config tends to NOT save default values so you can't > even rely on having set something explicitly to make it keep doing that. > If you want what was the default but no longer is, you are screwed. > That is NOT good for the user. So are you arguing this point theoretically, or do you believe there's a real issue with *this* change. Said another way, do you really think there are operators using an max link cost in normal/stable day to day operations (and not just as a maintenance tool)? Thanks, Lou ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15088] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Tue, 19 Apr 2016, Jafar A-Gharaibeh wrote: Everyone seems to agree that RFC compliance is very important. The importance of RFC compliance depends entirely on whether it suits oneself or not. ;) (Applying introspection, I know I've argued both sides of that in different situations anyway!) regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Happiness is a positive cash flow. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15087] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Tue, 19 Apr 2016, Daniel Walton wrote: How does this work then...is it your word no matter how the rest of the quagga community feels? That is certainly how it is coming across. Someone disagreed with my patch, it isn't going in. How is that my word no matter what? I'm allowed to argue why that patch should go in, surely? regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: "It's a summons." "What's a summons?" "It means summon's in trouble." -- Rocky and Bullwinkle ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15086] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support
On Tue, 19 Apr 2016, Lou Berger wrote: Paul, You have a valid point on absolutes. One never should say never :-) Agreed. And I agree with you we should get to standards compliance.. That said, we're not talking some obscure feature here . Does any non-quagga based vendor, major or otherwise, support the non standard behavior as the default? If so , there may be some basis for this discussion. If not , and in my experience , then the current behavior should be viewed as a bug. Just one persons (my) opinion... Right. The specifics of this are: - At some point in the future, hopefully not too far off (IANA have re-allocated the relevant OSPF option bit to the H-bit) there will be a standards compliant way to signal "no-transit". So Quagga will be able to signal "no-transit" and "transit discouraged, but still OK". The "no-transit" signalling (H-bit) will be recognised by: - old Quagga - all H-bit recognising routers (inc new Quagga) Non-H-bit, RFC2328 routers will not recognise this, so it'd be the same issue as with Quagga and other routers today (but, at least configurable on both the originating Quagga side, and on the SPF side on any updated Quagga) The "transit discouraged, but OK" signalling of 0xfffe (or lower) will be recognised universally as such: - old Quagga - new Quagga - RFC1247, 1583, 2328, OSPF - For doing the right thing by other routers, we need to change the SPF behaviour. The implications are: - We need a UI for admins to indicate between whether they want "no-transit" or "transit still OK". This would be the case regardless of the past, if we wanted to support the H-bit. - As we will be able to get to a point where the current behaviour will work in a standards compatible way, and as "old Quagga" will interpret the H-bit signalling as "no-transit" anyway (cause it requires 0x link metrics) it makes little sense to break that behaviour. Otherwise we will just piss off another group of unsuspecting operators, to fix an issue that affects another (who, if they know they're affected by this, may already be pissed off). Both sets may be small, and which set would be larger we can not know. - The first step to changing the SPF default is to add the option to control it, and print out the state of that config option explicitly, and document things so admins can be aware and make a choice. Why object to that?? So, yes, RFC compliance - great. That _is_ what this patch set is _aiming for_ while trying to avoid upsetting any _further_ operators. Read the patch, get stuck into the details, come up with constructive suggestions on how to improve the transition. That kind of thing would help. :) regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: The best defense against logic is ignorance. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
