Paul, What are your thoughts on:
On 4/21/2016 9:00 AM, Lou Berger wrote: > 2) how do we get moving on the next release (and the clearing out > http://patchwork.quagga.net/project/quagga/list/)? also, more below. On 4/21/2016 10:19 AM, Paul Jakma wrote: > 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. sure, note that this config option is available today without any changes.. > 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. we've covered this ground in previous messages. -- it doesn't seem that we're going to convince each other on what is 'best'. >> 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. cool. > >>> 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. huh, why? all versions (even old) can use 0xfffe to support maintenance in a safe way today. > >>> 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. I don't see how. The only thing that will help is getting quagga to perform a compliant SPF calculation (whether config controlled or not.) > If those concerns are serious, then we should seriously evaluate things > that can reduce that risk. agreed -- but we seem do differ on the risk level for the different scenarios (quagga to non-quagga, and fixed quagga to old quagga). > 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. sure, but there's one already there today -- just use 0xfffe rather than 0xffff for the quagga only case. My issue with the non-quagga case is that reading a cisco or juniper manual won't tell me that using 0xffff will break your network if it includes a quagga router. > 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? :) In the scheme of things, IMO having a patches roll into base quagga is far more serious an issue than this one. I'm engaging on this topic, more out of the general concern than really thinking that this patch is major issue. Frankly, I'm amazed this is such a "big" discussion. Fixing multi-vendor interop should be a no-brainer. Allowing for options for backwards compatibility also should be a no-brainer. -- Ether way, blocking all progress on quagga on one topic is not a good thing. > 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. agreed. > 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. if it's this or nothing -- sounds like the decision has been made ;-) > 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 guess I'm not following you're specific proposal. If this means that there is no way to run quagga in a 'standard SPF compliance mode' then I think this misses the point. Reviewing the patch should make it clear. > 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. same response as above. Thanks, Lou > 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, _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
