Requested revision
Standard: | IEEE 802.1Q-2018 | Clause: | 17.7.4 |
Clause title: | Definitions for the IEEE8021-Q-BRIDGE-MIB module |
Rationale for revision
There are two objects in the MIB, ieee8021QBridgeStaticUnicastReceivePort and ieee8021QBridgeStaticMulticastReceivePort, that should be removed from the MIB. According to the descriptions of these objects, they provide the capability of inserting into the Filtering Data Base (FDB), for a particular VLAN and Destination MAC address, a separate FDB entry for each different input port. (And one for default, for ports on which no specific entry is present.) This capability (according to my understanding of what Glenn Parsons said), was inserted into the MIB by the IETF back in IEEE 802.1D days, as being something that that they felt a bridge ought to be able to do. This capability has no support in either clause 8 or clause 12 of IEEE Std 802.1Q; the FDB does not care on which port a frame was received.
Unfortunately, these variables are both used as indices, into the ieee8021QBridgeStaticUnicastTable and ieee8021QBridgeStaticMulticastTable, respectively, so I don't think we can simply deprecate them. I suggest requiring them to be 0, so that existing implementations (which presumably use 0) aren't inconvenienced.
Proposed text
Option 1: Change the DESCRIPTIONs of both of these objects to, "MUST be equal to 0."
Option 2: Add to the DESCRIPTIONs the following paragraph: "There is no behavior defined in IEEE 802.1Q that supports a non-0 value for this object."
Option 3: Change the DESCRIPTIONs to: "There is no behavior defined in IEEE 802.1Q that supports a non-0 value for this object."
I prefer option 3.
Impact on existing networks
Unknown to this submitter.
Originator
Name: | Norman Finn | Email: | nfinn@nfinnconsulting.com |
Affiliation: | Huawei | ||
Submitted: | 2020-11-05 |