Interpretations

Interpretation for IEEE Std 802.1ag™-2007 IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management

Copyright © 2011 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

This is an interpretation of IEEE Std 802.1ag-2007.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

October 2011

Interpretation Request #1
Topic: Support of priority tagged CFM frames See attached.

Interpretation Response #1
IEEE Std 802.1ag-2007-Interpretation #1

It seems that once any LBR with the incorrect LTID is received, then every LBR received after that will be considered to have an incorrect LTID, until LBIactive becomes false. This is because in action c)2), the received Loopback Transaction Identifier is copied to expectedLBRtransID, but expectedLBRtransID is not incremented after that.

It is possible that that was the intended behavior, that all subsequent LBRs are considered incorrect after one incorrect LBR is received.

However, it is also possible that it was intended for expectedLBRtransID to track the new LTID, so that the first LBR is considered incorrect but subsequent ones are considered correct.

Clarification of the intention in ProcessLBR() is requested. Is it as written, or was there a typo in the standard?  (e.g., was the intention to say "2) The value from the received Loopback Transaction Identifier field is copied into expecedLBRtransID, then expectedLBRtransID and the number of incorrect LBRs received [item z) in 12.14.7.1.3] is incremented by 1."

Interpretation Response #2
The intention of IEEE Std 802.1ag-2007 was that if LBRs 1 2 3 5 6 7 8 ... are received, only one error would be counted, for the 3-5 sequence.  If LBRs 1 2 3 5 4 6 7 8 ... are received, then three errors would be counted, one for 3-5, one for 5-4, and one for 4-6. This is not the behavior of IEEE Std 802.1g-2007 as currently written; this will be addressed in a future revision of IEEE Std 802.1Q™.

Interpretation Response #3
Subclause: 20.3.2 Linktrace Message reception, forwarding, and replying

Applicable conditions:

If an Up MEP, as shown in Figure 20-13, case 8, transmits a Linktrace, the Linktrace Responder should see it, decrement the TTL field, respond (to the MEP) and forward the LTM out the appropriate port, as shown in that diagram. However, according to point f) of 20.3.2 on page 144, the LTM would not be forwarded; it must have been received by an MHF in order to be forwarded. The case of an LTM generated by an internal Up MEP seems to have not been taken into account when writing point f).

Clearly, an LTM generated by an Up MEP should be forwarded.

Point f) now reads:

f) The LTM was received by an MHF, not a MEP;
This should perhaps be changed to read:

f) The LTM was received via an MHF Linktrace SAP or a MEP LTI SAP, and not a MEP Linktrace SAP;

Interpretation Response #3

The document is in error. It is agreed that that an LTM generated by an Up MEP should be forwarded. The error will be addressed in the next revision of IEEE Std 802.1Q.