Please see the full paper for a more detailed problem description.
IEEE Std. 802.1ah-2008 Topic: L2 Gateway Protocol description There appear to have been a number of editorial and technical mishaps in the development of 802.1ah's description of the L2GP extension to MSTP. It appears that some changes were made to the wrong machines. Unless isL2gp is cleared (False) these errors will lead to indeterminate behavior as currently two machines are attempting to use and then clear the same variable (rcvdBPDU). A consequence of the errors is that the 802.1ah state machines disagree with statements as to how L2GP is meant to operate. This note contains suggestions for corrections to the state machines and other normative descriptive elements in Clause 13 of P802.1ah, as it would amend IEEE Std 802.1Q. These are based on my review of the 802.1ah final text and P802.1ah ballot comments and related submissions (by others). I would request that 802.1 determine whether these suggested changes are consistent with the way that 802.1ah should be interpreted. A more difficult problem is a fundamental flaw in the 802.1ah logic, captured in checkBPDUConsistency(), for detecting a potential data loop due to some ports attached to the backbone being configured as L2GP ports while others are not. This procedure currently attempts to block a loop if superior information is received from the backbone. However it is the receipt of inferior information that would denote a loop from the L2 Gateway Port through a site (MSTP/RSTP being used within the site), out onto the backbone, and then back to the same L2GP port. Further, the way in which the L2GP port is meant to be blocked is through setting of the disputed variable, but the information is being received at a Root Port and the Port Role Transitions machine currently takes noaction on disputed when selectedRole is RootPort. Note that the receipt of the backbone BPDU is not required to block the port if the L2GP priority were to be set too low resulting in the port becoming Designated, as that is already dealt with by the repeated generation of'fake BPDUs' which would cause the Port Information Machine (PIM) to set disputed. This interpretation request is not a complete set of changes to improve the 802.1ah L2GP description and related aspects of 802.1Q, but just highlights issues that could lead implementers to produce non-working implementations. I believe that the task of a thorough overhaul is best left to Q-REV or to an existing project that needs to make changes for its own consistency requirements. However I do suggest some name changes for future formal consideration, these would help point out the necessary changes. The state machine corrections in this note do not contain any other functionality additions I have suggested in other notes, but are purely focused on repairing 802.1ah quickly. I make no claim that the corrected functionality is all that everyone might desire, merely that thereare current inconsistencies in the P802.1ah that require interpretation, and indeed that the current L2GP description will result in indeterminate outcomes if isL2gp is True. I have not yet added L2GP functionality to my RSTP simulator, and it is unlikely that I will be able to do so for the forseeable future.
The P802.1ah amendment changes and additions to IEEE Std 802.1Q subclauses 13.1 through 13.37 are not consistent with the other provisions of Clause 13. Specifying the necessary corrections is beyond the scope of a response to an interpretation request. The corrections suggested in the interpretation request will be considered as part of an amendment under development (P802.1aq).
Pages copyright © Institute of Electrical and Electronics Engineers, Inc. Please read the rules on Confidentiality Statements and Copyright Notices on Communications. Information on Privacy and opting out of cookies is available. If you have any comments on these pages, please send them to me.
