On Fri, 20 May 2016, David Lamparter wrote:
I still believe the set size of Quagga monoculture users impacted by
moving to RFC behaviour is sufficiently close to zero, while at the
other hand the to-be-fixed current impact on mixed-implementation
installations is at least existent;
That could be, or maybe it isn't. Maybe most users only have a few
Quagga here and there. Maybe other sets of users find Quagga works for
them and use it almost exclusively - why risk cross-vendor
interoperability bugs after all? ;) (That's definitely not an uncommon
attitude in other parts of IT wrt equipment choices).
So, it seems impossible to decide on that basis.
What may be possible though is to reason about the classes of
possibilities, and avoid adding classes that would have interoperability
issues.
E.g., we can't do anything about distinguishing between "old Quagga" and
plain-RFC2328 speakers. However, we /could/ ensure that "new Quagga" can
be distinguished and render this default question irrelevant for at
least "new Quagga" networks, via RIs. Not my idea - that's exactly the
strategy the OSPF WG is taking for the H-bit, which will implement the
"old Quagga" behaviour. If H-bit isn't ready in time, we can also apply
for a vendor code-point and have a Quagga RI (maybe not a bad idea).
In another dimension, it's also worth considering what UI we will need
for something like H-bit, and ensure whatever we do now is consistent
with UI changes over time.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Your mode of life will be changed for the better because of good news soon.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
