The current specification is inconsistent in how the VID for Loopback Reply (LBR) frames is determined. Subclause 19.2.2 says that MEPs use the Primary VID as the vlan_identifier parameter for LBRs. Subclause 19.3.2 says that MHFs use the Primary VID as the vlan_identifier parameter for LBRs. Subclause 20.2.2 says vlan_identifier parameter in the LBM indication service primitive is copied to the vlan_identifier parameter in the LBR request service primitive. There are cases (some examples are described below) where it is important that different MPs in a single MA use different values for the Primary VID. In these cases, simply copying the vlan_identifier from the LBM to LBR will sometimes compromise the ability of the Loopback mechanism to localize a configuration error, and sometimes prevent a LBR from being delivered to the MEP that initiated the LBM. All of the subclauses referenced above use non-normative language. The normative text should be in 20.28.2 which specifies the xmitLBR() procedure for the Loopback Responder state machine, but here the determination of the vlan_identifier parameter is only specified for PBB-TE Maintenance Associations (802.1ag did not specify the determination of the vlan_identifier at all, and 802.1Qay added it for PBB-TE only). Note that the normative text in 20.28.2 also neglects to specify the determination of the priority and drop_elibible parameters for the LBR. Subclause 20.2.2 says these should be copied from the LBM which makes sense for priority, but drop_eligible should always be set to False. The managed objects for CFM provide a way to (in item d) of 12.14.7.1.3) to set the Primary VID of a individual MEP. An analogous capability needs to be added for a MIP. The following examples demonstrate why the vlan_identifier in LBRs should be the Primary VID, not the value copied from the LBM: Typically the Primary VID is the same for all MPs in an MA, however there are important exceptions. For example, any use of asymmetric VLANs as described in Annex F, including SPBV which will be added in 802.1aq, will require MPs in the same MA to have different Primary VIDs. Consider a simple network with two stations connected by two bridges: +------------+ +----------+ +----------+ +-----------+ | | | | | | | | | Station A-----------B Bridge +---------+ Bridge C----------D Station | | | | | | | | | +------------+ +----------+ +----------+ +-----------+ Traffic between the stations and the bridges is untagged, but is forwarded between the bridge ports B and C using asymmetric VLANs. (802.1aq will add support for tagged traffic between the station and the bridges, but it will be vulnerable to the same problems described here.) Ports A and D have Down MEPs at MD level N. Ports B and C have MIPs at MD level N, and MEPs at MD level N-1. Both the MIPs and MEPs at ports B and C have a VID set including all VIDs used by the asymmetric VLANs. First consider a Rooted-Multipoint application (as described in F.1.3.2) where port B is a Leaf port and port C is a Root port. Rooted-multipoint uses one VID (typically called the "Branch" VID) to carry traffic from Root ports to Leaf ports and other Root ports, and another VID (typically called the "Trunk" VID) to carry traffic from Leaf ports to Root ports but not to other Leaf ports. Traffic from A gets mapped to the Branch VID at Leaf port B; traffic from D gets mapped to the Trunk VID at Root port C. In order that CFM frames use the same VIDs as data frames, the Primary VID at Leaf port B should be the Branch VID, and the Primary VID at Root port C should be the Trunk VID. This way CCMs, LBMs, LTMs, and LTRs all have the same VID that normal data frames traveling in the same direction would have. This should also be true of LBRs, but would not be the case if the vlan_identifer is simply copied from the LBM to the LBR. A LBM initiated by the MEP at Leaf port B would have the Branch VID. If the MEP at Root port C copied the Branch VID to the LBR, the LBR is not using the same FDB entries as normal data traffic and CCMs. A misconfiguration could result in the LBR being delivered to port C even though normal data is blocked, or vice versa. If the Root port C uses its Primary VID (the Trunk VID) in the LBR, the forwarding of the LBR is identical to normal data. A LBM initiated by the Station port A would be mapped to the Branch VID at Leaf port B. If the LBR generated by the MIP at Root port C copied the Branch VID from the LBM, the LBR would be filtered at Leaf port B and would never be delivered to port A. A LBR generated by the MEP at Station port D, however, would be mapped to Trunk VID at Root port C and would be delivered to port A. This problem is resolved if the Root port C uses its Primary VID (the Trunk VID) in the LBR. Next consider a Multinetted-Server application (as described in F.1.3.1), where the station with port A is a client and the station with port D is a server. LBRs generated at port C in response to LBMs intiatiated by the MEPs at port A and B are subject to the same problems as in the Rooted-Multipoint application. Finally consider a SPBV application (as described in F.1.4 in 802.1aq) where ports B and C are boundary ports of the SPBV region. As with the above two examples, LBRs generated at port C in response to a LBM initiated at port B would not have the same VID as normal data frames traveling in the same direction. Unlike the above two examples, LBRs generated at port C in response to a LBM initiated at port A would be delivered to port C, however they would not have the same VID as normal data frames when traversing the path from port C to port B. These issues would be corrected by setting the Primary VID of the MPs in each bridge to the SPVID allocated to that bridge, and then using the Primary VID in the LBRs.