Paul,

On 4/20/2016 1:24 PM, Paul Jakma wrote:
> On Wed, 20 Apr 2016, Lou Berger wrote:
>
>> 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.
> Adding a config option is *exactly* what that patch-set is doing.

I know. That's why I said:
> 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.


> To quote from the commit message again:
>
> " 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".  "
>
> Step 1 is getting the config option in, and documenting the issue, and 
> writing out the config explicitly, and getting it in a release.
>
> Step 2 is to wait for N time and/or M releases.
>
> Step 3 is to change the default.
>
> We've had to do this before. The time is easily negotiable.
>
> How to handle defaults and significant changes in behaviour is also 
> negotiable. However I'm going to get a bit grumpy if I start to get 
> personal comments,
I can't speak to others, but I certainly hope hope tone hasn't come off
as personal - and please let me know if it has and I'll certainly
apologize publicly.

>  just because I've followed precedent on how such 
> behaviour changes are done in this patch.

> If the concern is routing loops, then just flipping the default on the 
> SPF behaviour *also* causes loops with older Quagga versions.
>
> Let's calm tfd, stop personalising this, and just manage the problem at 
> a technical level in a way that minimises issues for users.
>
> * Flipping the SPF default behaviour will *not* get rid of routing
>    loops, cause now you get the interoperability problems with new Quagga
>    and the *old* Quagga.
I don't see this. in the case the new routers will need their config
flipped to the non-standard mode before setting max met.

> * There is at one potential way that will give wider interoperability
>    than just flipping defaults.

can you elaborate on this?

> * This has been like this for 9 years, and there's been 1 bug report
>    AFAIK.
>
> I can think of lots of technical discussions on this, e.g. whether or 
> not we can wait for the H-bit. What should the UI be for the "transit" 
> and "no-transit" cases, etc.
>
> How about we have those instead? They'd be a lot more interesting.
I'm not sure what you're proposing here.

Lou

> regards,



_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to