On Thu, 21 Apr 2016, Lou Berger wrote:
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/)?
I don't know. Donald?
Was anyone to send minutes for the call to the list?
On 4/21/2016 10:19 AM, Paul Jakma wrote:
On Thu, 21 Apr 2016, Lou Berger wrote:
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..
You can configure Quagga's link-metrics that it will send, yes. For
non-0xffff, not quite as easily as one command.
There is no SPF behaviour config option today though.
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.
If you manually configure 0xfffe costs, instead of using a 'max-metric'
type command, yes. But there may be configs with max-metric...startup and
what not, both on Quagga installs and other implementations.
The "routing loop" is a /risk/ (depending on topology) if SPF is
inconsistent on 0xffff.
Also, the default is most important in the cases where the admin is /not/
aware.
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.)
With H-bit, some networks can be factored out of the "unknown, will be
wrong for some" case. Cause the H-bit SPF decision should be separate and
independent of the "old Quagga" 0xffff-SPF case, and because we will be
able to detect H-bit-only networks.
If everything on a network is H-bit, then the SPF-0xffff-default becomes
completely irrelevant. So the number of types of networks (wrt composition
of implementations) where the default can be wrong is reduced. Which
reduces the risk somewhat.
agreed -- but we seem do differ on the risk level for the different
scenarios (quagga to non-quagga, and fixed quagga to old quagga).
We don't know the numbers.
I think it'd be good to get a config option into admin's hands though.
Plus, if there's an OSPF mechanism that can render this default questoin
moot on some networks, even better, surely?
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.
I don't quite follow.
Yes, an admin can configure stuff to avoid this issue. Tediously on
anything but new Quagga though. However, if an admin is aware, the default
question is not really that important. The issue is where the admin is
*not* aware - that's when the default matters.
New Quagga can of course send 0xfffe or somesuch.
However, nothing we can do on new Quagga can reconcile the SPF-behaviour
of any non-H-bit-2328 and old Quagga routers. New Quagga defaults to
either one or the other.
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.
Yes, agreed. I do not understand why it's such a major issue to add a
config option for the SPF-0xffff behaviour. That really should be a
no-brainer.
What the default should be for it, and whether explicit-write-out and
staged changed is worth it I can agree is somewhat of a subjective balance
of things - that's fair enough too. I made an assumption this would be
required in this case, given strong feelings on this kind of thing in the
past from others, and also strong feelings that SPF-0xffff-interop issues
can cause a bad issue.
Hence also why I was looking for additional functionality to try avoid the
issue further - the patch I sent had the initial support for H-bit to try
go in that direction. That part of patch was incomplete, and I had
intended that to be for discussion rather than immediately ready for
integration, as H-bit isn't an RFC yet. Maybe that wasn't clear. The
incomplete patch circumvents the SPF-0xffff default somewhat; and a fuller
version maybe better again.
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.
Well, the aim of the patch definitely was to try get tuning knobs in to
allow it to be configured for compliance:
" This commit:
- Makes the SPF behaviour configurable with a
"compatible max-metric (infinite|follow)"
command. The state of this setting is explicitly written out, if
the ospfd config is written out.
- Allows the administrator to specify a "transit" flag to the
max-metric command:
"max-metric router-lsa transit"
to explicitly specify the RFC2328/RFC3187 "discourage, but transit
is still fine" behaviour the administator desires"
And maybe it wasn't completely clear, but the idea was to get to a place
where we could flip the SPF default without too much worry:
This should allow a Quagga stub-router, at least, to signal its intent
clearly:
- To RFC2328 routers and older Quagga routers, when it /may/ still
be used for transit.
- To all routers recognising the H-bit and to older Quagga routers,
when it /should not/ be used for transit.
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".
That patch gets at least some use-cases to use standards compliant
signalling and SPF behaviour. With the other cases configurable for
standards/old-Quagga as suits the admin. And with the stated aim of
getting to a point where the defaults also can be standards compliant.
All I wanted to do was to be careful not break any /more/ networks. That's
all.
Anyway, this discussion is too stressful now. Let's leave it alone for a
while.
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
If you look good and dress well, you don't need a purpose in life.
-- Robert Pante, fashion consultant
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
