Re: CVS commit: src/sys/net

[Roy Marples <roy%marples.name@localhost>]

On 27/09/2020 22:08, Robert Elz wrote:
>      Date:        Sun, 27 Sep 2020 19:16:28 +0000
>      From:        "Roy Marples" <roy%netbsd.org@localhost>
>      Message-ID:  <20200927191628.837A6FB28%cvs.NetBSD.org@localhost>
>
>    | This ensures that Duplicate Address Detection for the joining interface
>    | are performed across all members of the bridge.
>
> This sounds like a good idea, but I believe it is breaking (or ignoring)
> the oft stated design aim of the bridge interface, which is to emulate an
> external bridge - not to emulate being one.

I have no idea what this "oft stated design aim of the bridge interface" is.
Where is this documented?
Our bridge(4) has zero hits for the word external.
Also, what is this difference between an external bridge vs being one?

A bridge is a bridge, virtual or otherwise.

> That's the justification for not allowing the local address for the
> (combined) network to be configured on the bridge interface itself,
> but to require that it be on one of the connected interfaces (or on a
> tap or vether interface instead, so it remains if the selected real
> interface goes down).
>
> With an external bridge, unless the connection to the bridge is making
> the link come up (ie: there was no carrier before), the interface will
> not redo DAD just because its link has become attached to a bridge,
> however appealing it might be if that were to happen.   (If the interface
> had no carrier, was down, before being attached to the bridge, then when
> it comes up it will do DAD in the normal way).
>
> If we're giving up on the "external bridge" model (even partially) then
> we should give up on the "no addresses on the bridge interface" as well,
> and so remove the need for a tap/vether interface to be connected to the
> bridge fpr the sole purpose of holding a stable address.
>
> kre

You're reading far too much into this.
Let's break it down to brass tacks.

The bridge is a glory hole.
Should it try to protect it's members identities (local addresses) or not?

Now that you mention it though, the whole link should be taken down on bridge 
join (and then link state restored). It's the only way to be sure.
Some might view as too agressive.

Roy