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 [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
