James Carlson wrote: > Sebastien Roy writes: >> Referring to datalink interfaces in configuration data that >> administrators don't directly interact with should be done using linkid's >> to prevent exactly this kind of thing. What we want to avoid is >> administrators having to deal with linkid's. Under the covers, linkid's >> should be used, and they should be converted to link names where >> administrators are involved. > > I'm still thinking about this. The trade-offs aren't all obvious, and > using a bridge ID in the link configuration (rather than the other way > around) may end up being a simpler way to deal with the practical > restrictions.
Yes, I also had this same thought over the weekend. If you can store such state in the link's configuration properties, then that state goes along for the ride with any higher-level administrative operations on the link itself, such as the destruction of the link, or a link rename. How you would build the bridging universe at boot time (or whenever the bridge is brought up) would be less obvious, as it would involved iterating through all links looking for bridging state. -Seb
