James Carlson wrote:
> Create-bridge is supposed to be limited to a compatible set of
> bridging protocols, so a "type" shouldn't be needed.
>
> My current plan for the future RBridges/TRILL support (if that's what
> you're actually asking about here) is to add parameters that allow
> per-bridge disabling of RBridge behavior along with explicit
> administrative action (via SMF) to enable a TRILL instance of isisd.
> I could also be argued into a "bridge-created == isisd-enabled"
> position for ease-of-use, but that's not this case.
Well, rbridges we certainly on my mind.
And the internet-draft doesn't require an rbridge to embed full 802.1D/Q
functionality - even though it probably makes sense for many
implementations to do that.
Anyhow, you've convinced me we don't need a type.
> The summary includes "[-l <link>]...", which means that (like the
> create-aggr command on which it's modeled) you can add multiple links
> at the time the bridge is created.
Ah - I didn't understand that detail of the syntax.
> You can also add and remove one or many links after the bridge has
> been created, using the add-bridge and remove-bridge subcommands,
> again just like the corresponding *-aggr subcommands.
Yes, I saw that.
> The set of acceptable links is the same set that the *-aggr feature
> supports, plus aggregations themselves.
>
> Maybe I'm missing something important here, but I don't see a
> particular reason to distinguish between 802.11 and other kinds of
> interfaces.
Bridges require two things: being able to promisciously receive frames,
and being able to send frames with any source MAC address.
While 802.11 standards might not prevent those, it isn't uncommon for
802.11 NICs (or drivers) to prevent using anything bit the assigned MAC
address.
Hmm - perhaps there should be link property (send-why-any-source?) that
can be read by the bridge code.
>> I wonder if it would be better, since we might have rstp or mstp in the
>> future, to use Cisco type terminology for this (which I think is
>> "portfast" or something like that.)
>
> I'm very wary of and I don't want to step in any of their IPR. :-/
OK, but we should at least make the description more clear to people
that know and understand portfast.
But I realize they are not the same. portfast is described as
By enabling portfast you are forcing the switchport into forwarding mode
immediately. The port still participates in STP in the event that if
the port is to be a part of the loop, it will eventually transition into
STP blocking mode.
Thus disabling 802.1D completely things are a lot less safe than just
avoiding the 802.1D delay before being transitioning to forwarding.
See below for a name suggestion.
>>> "stp-priority"
>>> "stp-cost"
>> Could we/should we avoid "stp" in those names?
>
> The values are defined in terms that STP itself uses, and the IS-IS
> notion of cost and priority are rather different, so having some sort
> of reference to the domain in which the values are used makes sense to
> me.
>
> If we removed that term from those names, what would the units be?
My concern is that "stp" seems to refer to a very old version of a
protocol, that has since been replaced by rstp and mstp.
Given that we have rstp, we don't want to look as if we have old stp.
FWIW "bridge-priority" and "bridge-cost" works for me.
>> This is a design issue and not an architectural issue. (Thus I should
>> really have sent it as a separate email to the project team.):
>> For safety reasons, does the daemon watch for Bridge PDUs on the ports
>> that have STP disabled? (There shouldn't be any, thus there existence is
>> a red flag that the link probably isn't a point-to-point connection to a
>> host system.)
>
> That sounds like a reasonable thing to do. I'll add it to the list.
I guess the interface question is whether we call it "disable stp" even
though 802.1D is still active on the link, or whether we instead
introduce a name like "bridge-immediate-forwarding" for this configuration.
Erik
