Erik Nordmark writes: > James Carlson wrote: > > 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.
I doubt implementations can really get away without it, but it does make sense that the draft doesn't _require_ it. > Anyhow, you've convinced me we don't need a type. OK. > > 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. The very same issue occurs with aggregations, doesn't it? You need to be able to treat the aggregation as a single sender for the network layer clients, which means sending from the "wrong" MAC address on at least some of the links. I don't think it's a new or bridging-specific issue. If we have this problem, then we've also got it with aggregations, which is part of why I defined the usable links in those terms. Our constraints on link types are effectively the same as what aggregations can use, plus aggregations themselves. I think it gets outside the bounds of this case, but I agree that if we have those sorts of drivers, we'll need the same logic to prevent misconfiguration in both cases. I'll follow up on the supported drivers. > >> 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. It may ... after having blindly forwarded for long enough to melt the network. Or you can get into root-guard and BPDU-guard; more about that below. The more I think about Cisco-like 'portfast', the less I'm sure we want to support it in the first release. > 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. OK. > >>> "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. Ah, I see. I was just using it as a generic term: RSTP and MSTP are both instances of STP. Just newer ones. > FWIW "bridge-priority" and "bridge-cost" works for me. OK; that seems fine. > > 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. I'm wary of this. There's a bit more to it than just switching into forwarding mode immediately, because that still allows a node to attach via that port, send BPDUs with a lower (better) priority, and become the root bridge in your network. Given how some people are forced to dance around the root bridge determination fire with severed chicken heads, that's hazardous ... just in a different way. If simply allowing an STP per-port disable seems too hazardous, then I'd suggest we go with something like BPDU-guard. We can still disable STP, but if a BPDU is seen arriving on such a port, then we disable the port as apparently broken (changing state to 'disabled') and log a message. The administrator must explicitly reenable the link by removing it from the bridge and adding it back or otherwise making the link signal go down and back up. Seeing a BPDU on such a port is good evidence that the topology is just plain wrong, and saving the network at the expense of a port sounds like the right result to me. With, of course, warnings about the implications of doing this included in the man pages and administrator's guide updates. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
