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.