Paul,
see in-line
On 4/21/2016 4:51 AM, Paul Jakma wrote:
> On Wed, 20 Apr 2016, Lou Berger wrote:
>
>> 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.
> We were doing that. Rounds of integration.
>
> Kicking off the latest round seems to have stalled. Not sure why.
in this week coordination call donald said he'd kick off a bug fix
branch and david said he'd start a release branch as soon as he has
commit approval (which I believe vincent said he'd approve.) Not sure
where they stand on this other than not seeing any new branch on savana.
>> 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.
> See my reply to Martin.
>
> 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 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.
> 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.
> 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.
> 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.
> (And Cumulus were extremely slow in engaging on comments on that patch -
> I'm sure it's been over a year since I first tried to have a dialogue
> about that patch with them).
>
>> 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.
> I agree with you. I don't think it's a major issue at all generally.
> Others raised concerns that it could be though. So, even on mixed networks
> that have topologies where this loop is *possible*, I suspect it's rare
> it's ever an issue. However, /if/ it's an issue, I could agree it'd be an
> annoying one ("Hmm, why are my switches melting?").
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...
>
>> 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.
> That's great. But if it's not an issue, there's no issue in disregarding a
> patch that lacks the config option, and then waiting for one that does
> have it (which now exists).
>
> It's potentially also not an issue - given how long Quagga has had this
> behaviour - to wait for H-bit.
>
>> As long as the H bit usage follows the latest WG draft -- no need to
>> introduce something quagga specific here...
> H-bit support would be fully conformant, in the sense it would be acted on
> regardless of the 0xffff SPF compatibility setting. In the patch I sent.
>
>> 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.
> Well, I've had people telling me how bad routing loops are, and won't
> someone think of the routing loops! (humour), so forgive me if I went and
> took those concerns seriously.
>
> It's frustrating to have to deal with ever shifting concerns. At a purely
> logical level, if routing loops are an issue then the first Cumulus patch
> was insufficient and more work was needed; if not such a huge issue, then
> what is the issue in setting it aside and taking the time to see if both
> current Quagga and "transit OK" behaviour could be accommodated together
> (and the Quagga behaviour is actually useful - a standard is proposed to
> allow that behaviour to be signalled)?
>
> The responses I've had do not make logical sense to me. Particularly
> viewed in the context of how we've treated other interoperability/default
> issues (interoperability with system configuration like link-default; or
> with RFCs, like the RIP auth bug of ages ago, or this).
>
> Apparently the issue is serious enough that WE MUST APPLY A PATCH! So
> urgent, we must apply one that /extends/ the issue that is so concerning
> to further networks in the interim, but we don't have to look at patches
> that try minimise that and make it configurable cause the issue isn't
> serious.
>
> Baffling really.
>
>> 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.
> Max cost would be used for limited windows of time. The concern seemed to
> be those windows can be long enough for routing loops to be nasty.
>
>> 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...
> Agreed.
>
> ****There is only 1 patch that adds config options***!!!!!
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
2) how do we get moving on the next release (and the clearing out
http://patchwork.quagga.net/project/quagga/list/)?
Lou
> regards,
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
