[Home] . [What's New?] . [Active Ballots] . [Minutes] . [Meetings] . [Maintenance] . [Interpretations] . [Public Docs] . [Committee Docs]
[Local Address Study Group] . [802 Architecture Group] . [Data Center Bridging Task Group] [Time-Sensitive Networking Task Group]
[Email] . [Ancient Email] . [802.1 MIBs] . [802.1 OIDs] . [IEEE 802] . [IEEE 802 PARs]
TSN: [802] . [802a] . [802b] . [802.1D] . [802.1D-2004] . [802.1G] . [802.1H-REV] . [802.1Q] . [802.1Q-2014] . [802.1s] . [802.1v] . [802.1w] . [802.1AB-2005] . [802.1AB-2009] . [802.1AC-2012] . [802.1AC-2016] . [802.1ad] . [802.1ag] . [802.1ah] . [802.1aj] . [802.1ak] . [802.1ap] . [802.1aq] . [802.1Qaw] . [802.1AX-2008] . [802.1Qay] . [802.1Qbc] . [802.1Qbe] . [802.1Qbf] . [802.1AXbk] . [802.1Qbp] . [802.1AX-2014] . [802.1AX-Rev] . [802.1Qbz] . [802.1Qca]
[802.1AS] . [802.1AS-Rev] . [802.1Qat] . [802.1Qav] . [802.1BA] . [802.1Qbu] . [802.1Qbv] . [802.1CB] . [802.1Qcc] . [802.1Qch] . [802.1CM] . [802.1Qcn] . [802.1Qcp] . [802.1Qcr]
Security: [802.1X-2001] . [802.1X-2004] . [802.1X-2010] . [802.1AE] . [802.1af] . [802.1AR] . [802.1AEbn] . [802.1AEbw] . [802.1Xbx] . [802.1ARce] . [802.1AEcg] . [802.1Xck] . [802E]
DCB: [802.1Qau] . [802.1Qaz] . [802.1Qbb] . [802.1Qbg] . [802.1Qbh] . [802.3bd] . [802.1BR] . [802.1Qcd] . [802.1Qcj] . [802c] . OmniRAN: [802.1CF]

Interpretation #10

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.

Valid XHTML 1.0 Transitional Valid CSS!

Last modified by jlm, at 9:50am on Thu, 10 Sep 2009