Re: [PATCH net-next 0/3] net: introduce IFF_PROTO_DOWN flag.

[Anuradha Karuppiah <anuradhak@cumulusnetworks.com>]

On Fri, Mar 20, 2015 at 9:13 AM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Fri, Mar 20, 2015 at 8:11 AM,  <anuradhak@cumulusnetworks.com> wrote:
>> From: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
>>
>> Applications can detect errors in the network that would require
>> disabling the device independent of the admin state. In the presence of
>> these errors traffic could be black holed or looped resulting in a
>> network meltdown. Clearing the IFF_UP flag for error disabling the
>> device can be problematic because -
>>
>> 1. The administrator cannot distinguish between a user space daemon’s
>> error-disable and a regular device disable.
>> 2. Applications can monitor the error state and enable the device once
>> the error is removed. If IFF_UP is used for this purpose the application
>> may end up enabling a device that the administrator has intentionally
>> disabled for other reasons. This could result in network changes not
>> expected by the admin.
>>
>
> Both reasons look like workaround for user space issues.
> Just keep this fake-down state in userspace.
> What's the point pushing it to kernel?

Applications can deal with IFF_UP being cleared and they can certainly
clear IFF_UP as well on detecting errors. However an application
cannot know the reason for the !IFF_UP notification. So if an
application detected a device error being cleared it would have to
unconditionally enable the device as a part of recovery handling
thereby ignoring the administrator’s request to keep the device
disabled. Separating error-disable (IFF_PROTO_DOWN) from admin-disable
(!IFF_UP) lets the administrator have a say in keeping a device
disabled.

> looking at 3rd patch:
> + * @IF_LINK_PROTO_DOWN_MLAG: proto_down by a multi-chassis LAG application.
> + * @IF_LINK_PROTO_DOWN_STP: proto_down by an STP application.
>
> so there will be new flag for every application that cannot deal with
> normal down?

These applications can clear the error state independent of each
other. Say for e.g.  both STP-BPDU guard and MLAG error-disabled a
device. When the MLAG split-brain error is resolved the MLAG
application could clear IFF_PROTO_DOWN but the BPDU guard error would
still exist. This will create problem windows that could aggressively
affect the network.

New bits only need to be added if there are new errors that need to be
cleared independent of other applications that can error-disable a
device.