The IEEE and the ITU-T use their own nomenclature when describing administrative contexts and functions. This introduces a level of complexity to configuration, discussion and different vendors naming conventions. The SR OS CLI has chosen to standardize on the IEEE 802.1ag naming where overlap exists. ITU-T naming is used when no equivalent is available in the IEEE standard. In the following definitions, both the IEEE name and ITU-T names are provided for completeness, using the format IEEE Name/ITU-T Name.
Maintenance Domain (MD)/Maintenance Entity (ME) is the administrative container that defines the scope, reach and boundary for testing and faults. It is typically the area of ownership and management responsibility. The IEEE allows for various formats to name the domain, allowing up to 45 characters, depending on the format selected. ITU-T supports only a format of ‟none” and does not accept the IEEE naming conventions.
0 is undefined and reserved by the IEEE.
1 indicates no domain name.
2,3, and 4 provide the ability to input various different textual formats, up to 45 characters. The string format (2) is the default and therefore the keyword is not shown when looking at the configuration.
Maintenance Association (MA)/Maintenance Entity Group (MEG) is the construct where the different management entities are contained. Each MA is uniquely identified by its MA-ID. The MA-ID comprises the MD level and MA name and associated format. This is another administrative context where the linkage is made between the domain and the service using the bridging-identifier configuration option. The IEEE and the ITU-T use their own specific formats. The MA short name formats (0 to 255) have been divided between the IEEE (0 to 31, 64 to 255) and the ITU-T (32 to 63), with five currently defined (1 to 4, 32). Even though the different standards bodies do not have specific support for the others formats a Y.1731 context can be configured using the IEEE format options.
The following formats are supported:
- 1 (Primary VID)
- values 0 to 4094
- 2 (String)
- raw ASCII, excluding 0-31 decimal/0-1F hex (which are control characters) form the ASCII table
- 3 (2-octet integer)
- values 0 to 65535
- 4 (VPN ID)
- Hex value as described in RFC 2685, Virtual Private Networks Identifier
- 32 (icc-format)
- exactly 13 characters from the ITU-T recommendation T.50
Maintenance Domain Level (MD Level)/Maintenance Entity Group Level (MEG Level) is the numerical value (0-7) representing the width of the domain. The wider the domain (higher the numerical value) the farther the ETH-CFM packets can travel. It is important to understand that the level establishes the processing boundary for the packets. Strict rules control the flow of ETH-CFM packets and are used to ensure correct handling, forwarding, processing and dropping of these packets. ETH-CFM packets with higher numerical level values flows through MEPs on MIPs on endpoints configured with lower level values. This allows the operator to implement different areas of responsibility and nest domains within each other. Maintenance association (MA) includes a set of MEPs, each configured with the same MA-ID and MD level used to verify the integrity of a single service instance.
Maintenance Endpoints/MEG Endpoints (MEP) are the workhorses of ETH-CFM. A MEP is the unique identification within the association (1-8191). Each MEP is uniquely identified by the MA-ID, MEP-ID tuple. This management entity is responsible for initiating, processing and terminating ETH-CFM functions, following the nesting rules. MEPs form the boundaries which prevent the ETH-CFM packets from flowing beyond the specific scope of responsibility. A MEP has direction, up or down. Each indicates the directions packets are generated; up toward the switch fabric, down toward the SAP away from the fabric. Each MEP has an active and passive side. Packets that enter the active point of the MEP are compared to the existing level and processed accordingly. Packets that enter the passive side of the MEP are passed transparently through the MEP. Each MEP contained within the same maintenance association and with the same level (MA-ID) represents points within a single service. MEP creation on a SAP is allowed only for Ethernet ports with NULL, q-tags, q-in-q encapsulations. MEPs may also be created on SDP bindings. A vMEP is a service level MEP configuration that installs ingress (down MEP-like) extraction on the supported ETH-CFM termination points within a VPLS configuration.
Maintenance Intermediate Points/MEG Intermediate Points (MIPs) are management entities between the terminating MEPs along the service path. MIPs provide insight into the service path connecting the MEPs. MIPs only respond to Loopback Messages (LBM) and Linktrace Messages (LTM). All other CFM functions are transparent to these entities.
MIP creation is the result of the mhf-creation mode and interaction with related MEPs, and with the direction of the MEP. Two different authorities can be used to determine the MIPs that should be considered and instantiated. The domain and association or the default-domain hierarchies match the configured bridge identifier and VLAN to the service ID and any configured primary VLAN. When a primary VLAN MIP is not configured, the VLAN is either ignored or configured as none.
The domain and association MIP creation function triggers a search for all ETH-CFM domain association bridge identifier matches to the service it is linked to. A MIP candidate is then be evaluated using the mhf-creation mode and the rules that govern the algorithm. The domain association mhf-creation modes and their uses are listed below:
none
A MIP is not a candidate for creation using this domain association bridge identifier. This is the default mhf-creation mode for every bridge identifier under this hierarchy.
explicit
A MIP is a candidate for creation using this domain association bridge identifier only if a lower-level MEP exists.
default
A MIP is a candidate for creation using this domain association bridge identifier regardless of the existence of a lower-level MEP. If a lower-level MEP is present, this creation mode behaves in the same manner as explicit creation mode.
static
A MIP is a candidate for creation using the domain association bridge identifier at the level of the domain. This creation mode is specific to MIPs with the primary-vlan-enabled parameter configured. Different VLANs maintain their own level hierarchies. Primary VLAN creation under this context requires static mode.
For all modes except static mode, only a single MIP can be created. All candidates are collected and the lowest-level valid MIP is created. In static mode, all valid MIPs are created for the bridge identifier VLAN pair. A MIP is considered invalid if the level of the MIP is equal to or below a downward-facing MEP, or below the level of an upward-facing MEP and the MIP shares the same service component as the Up MEP.
Not all creation modes require the mip creation statement within the service. The explicit and default mhf-creation modes may instantiate a MIP without the mip creation statement under the service if a lower-level MEP exists for the domain association bridge identifier. If a lower-level MEP does not exist, the default and static mhf-creation modes require the mip creation statement on the service connection.
MEPs require the domain and association configurations to ensure that all ETH-CFM PDUs can be supported. MIPs have restricted ETH-CFM PDU support: ETH-LB and ETH-LT. These two protocols do not require the configuration of a domain and association. MIPs may be created outside of the association context using the default-domain table.
The default-domain table is an object table populated with values that are used for MIP creation. The table is indexed by the bridge identifier and VLAN. An index entry is automatically added when the mip creation statement is added under a SAP or SDP binding. When an index entry is added, the bridge identifier is set to the service ID and the VLAN is set to the primary-vlan-enable vlan-id. If the MIP does not use primary VLAN functionality, the VLAN is configured as none. When the entry has been added to the default-domain table, the default values can be configured. The default-domain table defers to the system-wide, read-only values.
Because there are two different locations able to process the MIP creation logic, a per-bridge identifier VLAN authority must be determined. The authority is a component, table, or configuration that is responsible for executing the MIP creation algorithm. In general, any domain association bridge identifier that could be used to create a specific MIP is authoritative. Other configurations influence the authority, such as the type of MIP (primary VLAN or non-primary VLAN), the different mhf-creation modes, the interaction of those modes with MEPs, and the direction of the MEP.
The following rules provide some high-level guidelines to determine the authority:
rule 1
The original model predating the default-domain is always applied first. If a MIP is created using the original model, the new model is not applied. The original model includes complex Up MEP MIP creation rules. If an Up MEP exists on a service connection, any service connection other than the one with the active Up MEP attempts to create the lowest higher-level MIP using the domain association bridge identifier table. If a higher-level MIP cannot be created, and no higher-level association exists, the default-domain table is consulted.
rule 2
A mip creation statement is required under the service connection to use the default-domain table. This is different from the domain association table. The domain association table does not require the mip creation statement when the mhf-creation mode is configured as either explicit or default and a lower-level MEP is present.
rule 3
If no domain association bridge identifier matches the service ID, the default-domain table is consulted.
rule 4
If a domain association bridge identifier matches a service ID for the sole purpose of MEP creation, and no higher or lower domain association with the same bridge identifier exists, the default-domain table is consulted.
rule 4a
Any domain association bridge identifier matching a service ID with a configured VLAN and a static mhf-creation mode is authoritative for all matching service IDs and MIPs with primary-vlan-enable configured with the same VLAN.
rule 4b
Any domain association bridge identifier attempting to create a MIP with primary-vlan-enable configured is considered non-authoritative if the mhf-creation mode is anything other than static.
When the authority for MIP creation is determined, the MIP attributes are derived from that creation table. The default domain table defers to the read-only, system-wide MIP values and inherits those defaults. Some of the objects under the default-domain hierarchy must be configured using the same statement to avoid transient and unexpected MIP creation while the configuration is being completed. To this end, the mhf-creation mode and level have been combined in the same configuration statement.
The standard mhf-creation modes (none, default, explicit) are configurable as part of the default-domain table. Static mode can only be configured under the domain association bridge identifier. This is because default domain table indexing precludes multiple MIPs at different levels.
MIP creation requires configuration. The default values in both the domain association and the default domain table prevent MIP instantiation.
The show eth-cfm mip-instantiation command can be used to check the authority for each MIP.
There are two locations in the configuration where ETH-CFM is defined. The first location, where the domains, associations (including links to the service), MIP creation method, common ETH-CFM functions, and remote MEPs are defined under the top-level eth-cfm command. The second location is within the service or facility.
Table: ETH-CFM support matrix is a general table that indicates ETH-CFM support for the different services and SAP or SDP binding. It is not meant to indicate the services that are supported or the requirements for those services on the individual platforms.
| Service | Ethernet connection | Down MEP | Up MEP | MIP | Virtual MEP |
|---|---|---|---|---|---|
Epipe |
— |
— |
— |
— |
No |
SAP |
Yes |
Yes |
Yes |
— |
|
Spoke-SDP |
Yes |
Yes |
Yes |
— |
|
PW-SAP |
No |
No |
Yes |
— |
|
VPLS |
— |
— |
— |
— |
Yes |
SAP |
Yes |
Yes |
Yes |
— |
|
Spoke-SDP |
Yes |
Yes |
Yes |
— |
|
Mesh-SDP |
Yes |
Yes |
Yes |
— |
|
B-VPLS |
— |
— |
— |
— |
Yes |
SAP |
Yes |
Yes |
Yes |
— |
|
Spoke-SDP |
Yes |
Yes |
Yes |
— |
|
Mesh-SDP |
Yes |
Yes |
Yes |
— |
|
I-VPLS |
— |
— |
— |
— |
No |
SAP |
Yes |
Yes |
Yes |
— |
|
Spoke-SDP |
Yes |
Yes |
Yes |
— |
|
M-VPLS |
— |
— |
— |
— |
No |
SAP |
Yes |
Yes |
Yes |
— |
|
Spoke-SDP |
Yes |
Yes |
Yes |
— |
|
Mesh-SDP |
Yes |
Yes |
Yes |
— |
|
PBB Epipe |
— |
— |
— |
— |
No |
SAP |
Yes |
Yes |
Yes |
— |
|
Spoke-SDP |
Yes |
Yes |
Yes |
— |
|
Ipipe |
— |
— |
— |
— |
No |
SAP |
Yes |
No |
No |
— |
|
Ethernet-Tunnel SAP |
Yes |
No |
No |
— |
|
IES |
— |
— |
— |
— |
No |
SAP |
Yes |
No |
No |
— |
|
Spoke-SDP (Interface) |
Yes |
No |
No |
— |
|
Subscriber Group-int SAP |
Yes |
No |
No |
— |
|
VPRN |
— |
— |
— |
— |
No |
SAP |
Yes |
No |
No |
— |
|
Spoke-SDP (Interface) |
Yes |
No |
No |
— |
|
Subscriber Group-int SAP |
Yes |
No |
No |
— |
Figure: MEP creation illustrates the usage of an Epipe on two different nodes that are connected using ether SAP 1/1/2:100.31. The SAP 1/1/10:100.31 is an access port that is not used to connect the two nodes.
NODE1
config>eth-cfm# info
----------------------------------------------
domain 3 format none level 3
association 1 format icc-based name "03-0000000101"
bridge-identifier 100
exit
exit
exit
domain 4 format none level 4
association 1 format icc-based name "04-0000000102"
bridge-identifier 100
exit
exit
exit
config>service>epipe# info
----------------------------------------------
sap 1/1/2:100.31 create
eth-cfm
mep 111 domain 3 association 1 direction down
mac-address d0:0d:1e:00:01:11
no shutdown
exit
exit
exit
sap 1/1/10:100.31 create
eth-cfm
mep 101 domain 4 association 1 direction up
mac-address d0:0d:1e:00:01:01
no shutdown
exit
exit
exit
no shutdown
----------------------------------------------
NODE 2
eth-cfm# info
----------------------------------------------
domain 3 format none level 3
association 1 format icc-based name "03-0000000101"
bridge-identifier 100
exit
exit
exit
domain 4 format none level 4
association 1 format icc-based name "04-0000000102"
bridge-identifier 100
exit
exit
exit
----------------------------------------------
config>service>epipe# info
----------------------------------------------
sap 1/1/2:100.31 create
eth-cfm
mep 112 domain 3 association 1 direction down
mac-address d0:0d:1e:00:01:12
no shutdown
exit
exit
exit
sap 1/1/10:100.31 create
eth-cfm
mep 102 domain 4 association 1 direction up
mac-address d0:0d:1e:00:01:02
no shutdown
exit
exit
exit
no shutdown
----------------------------------------------
Examining the configuration from NODE1, MEP 101 is configured with a direction of UP causing all ETH-CFM traffic originating from this MEP to generate into the switch fabric and out the mate SAP 1/1/2:100.31. MEP 111 uses the default direction of DOWN causing all ETH-CFM traffic that is generated from this MEP to send away from the fabric and only egress the SAP on which it is configured, SAP 1/1/2:100.31.
Further examination of the domain constructs reveal that the configuration properly uses domain nesting rules. In this case, the Level 3 domain is completely contained in a Level 4 domain.
Figure: MIP creation example (NODE1) illustrates the creation of an explicit MIP using the association MIP construct.
NODE1
config>eth-cfm# info
----------------------------------------------
domain 3 format none level 3
association 1 format icc-based name "03-0000000101"
bridge-identifier 100
exit
exit
exit
domain 4 format none level 4
association 1 format icc-based name "04-0000000102"
bridge-identifier 100
exit
exit
association 2 format icc-based name "04-MIP0000102"
bridge-identifier 100
mhf-creation explicit
exit
exit
exit
config>service>epipe# info
----------------------------------------------
sap 1/1/2:100.31 create
eth-cfm
mep 111 domain 3 association 1 direction down
mac-address d0:0d:1e:00:01:11
no shutdown
exit
exit
exit
sap 1/1/10:100.31 create
eth-cfm
mep 101 domain 4 association 1 direction up
mac-address d0:0d:1e:00:01:01
no shutdown
exit
exit
exit
no shutdown
----------------------------------------------
NODE 2
eth-cfm# info
----------------------------------------------
domain 3 format none level 3
association 1 format icc-based name "03-0000000101"
bridge-identifier 100
exit
exit
exit
domain 4 format none level 4
association 1 format icc-based name "04-0000000102"
bridge-identifier 100
exit
exit
association 2 format icc-based name "04-MIP0000102"
bridge-identifier 100
mhf-creation explicit
exit
exit
exit
----------------------------------------------
config>service>epipe# info
----------------------------------------------
sap 1/1/2:100.31 create
eth-cfm
mep 112 domain 3 association 1 direction down
mac-address d0:0d:1e:00:01:12
no shutdown
exit
exit
exit
sap 1/1/10:100.31 create
eth-cfm
mep 102 domain 4 association 1 direction up
mac-address d0:0d:1e:00:01:02
no shutdown
exit
exit
exit
no shutdown
----------------------------------------------
An addition of association 2 under domain 4 includes the mhf-creation explicit statement. This means that when the level 3 MEP is assigned to the SAP 1/1/2:100.31 using the definition in domain 3 association 1, creating the higher level MIP on the same SAP. Because a MIP does not have directionality ‟Both” sides are active. The service configuration and MEP configuration within the service did not change.
Figure: MIP creation default illustrates a simpler method that does not require the creation of the lower level MEP. The operator simply defines the association parameters and uses the mhf-creation default setting, then places the MIP on the SAP of their choice.
NODE1:
config>eth-cfm# info
----------------------------------------------
domain 4 format none level 4
association 1 format icc-based name "04-0000000102"
bridge-identifier 100
exit
exit
association 2 format icc-based name "04-MIP0000102"
bridge-identifier 100
mhf-creation default
exit
exit
exit
----------------------------------------------
config>service>epipe# info
----------------------------------------------
sap 1/1/2:100.31 create
eth-cfm
mip mac d0:0d:1e:01:01:01
exit
exit
sap 1/1/10:100.31 create
eth-cfm
mep 101 domain 4 association 1 direction up
mac-address d0:0d:1e:00:01:01
no shutdown
exit
exit
exit
no shutdown
----------------------------------------------
NODE2:
config>eth-cfm# info
----------------------------------------------
domain 4 format none level 4
association 1 format icc-based name "04-0000000102"
bridge-identifier 100
exit
exit
association 2 format icc-based name "04-MIP0000102"
bridge-identifier 100
mhf-creation default
exit
exit
exit
----------------------------------------------
config>service>epipe# info
----------------------------------------------
sap 1/1/2:100.31 create
eth-cfm
mip mac d0:0d:1e:01:01:02
exit
exit
sap 1/1/10:100.31 create
eth-cfm
mep 102 domain 4 association 1 direction up
mac-address d0:0d:1e:00:01:02
no shutdown
exit
exit
exit
no shutdown
----------------------------------------------
Figure: MEP, MIP and MD levels shows the detailed IEEE representation of MEPs, MIPs, levels and associations, using the standards defined icons.
SAPs support a comprehensive set of rules including wild cards to map packets to services. For example, a SAP mapping packets to a service with a port encapsulation of QinQ may choose to only look at the outer VLAN and wildcard the inner VLAN. SAP 1/1/1:100.* would map all packets arriving on port 1/1/1 with an outer VLAN 100 and any inner VLAN to the service the SAP belongs to. These powerful abstractions extract inbound ETH-CFM PDUs only when there is an exact match to the SAP construct. In the case of the example when then an ETH-CFM PDU arrives on port 1/1/1 with a single VLAN with a value of 100 followed immediately with e-type (0x8902 ETH-CFM). Furthermore, the generation of the ETH-CFM PDUs that egress this specific SAP are sent with only a single tag of 100. The primary VLAN is required if the operator needs to extract ETH-CFM PDUs or generate ETH-CFM PDUs on wildcard SAPs and the offset includes an additional VLAN that was not part of the SAP configuration.
Table: Extraction comparison with primary VLAN shows how packets that would normally bypass the ETH-CFM extraction would be extracted when the primary VLAN is configured. This assumes that the processing rules for MEPs and MIPs is met, E-type 0x8902, Levels and OpCodes.
| Port encapsulation | E-type | Ingress tags | Ingress SAP | No primary VLAN ETH-CFM extraction |
With primary VLAN (10) ETH-CFM extraction |
||
|---|---|---|---|---|---|---|---|
— |
— |
— |
— |
MEP |
MIP |
MEP |
MIP |
Dot1q |
0x8902 |
10 |
x/y/z:* |
No |
No |
Yes |
Yes |
Dot1q |
0x8902 |
10.10 |
x/y/z:10 |
No |
No |
Yes |
Yes |
QinQ |
0x8902 |
10.10 |
x/y/z:10.* |
No |
No |
Yes |
Yes |
QinQ (Default Behavior) |
0x8902 |
10.10 |
x/y/z:10.0 |
No |
No |
Yes |
Yes |
Null |
0x8902 |
10 |
x/y/z |
No |
No |
Yes |
Yes |
The mapping of the service data remains unchanged. The primary VLAN function allows for one additional VLAN offset beyond the SAP configuration, up to a maximum of two VLANs in the frame. If a fully qualified SAP specifies two VLANs (SAP 1/1/1:10.10) and a primary VLAN of 12 is configured for the MEP there is no extraction of ETH-CFM for packets arriving tagged 10.10.12. That exceeds the maximum of two tags.
The mapping or service data based on SAPs has not changed. ETH-CFM MPs functionality remains SAP specific. In instances where as service includes a specific SAP with a specified VLAN (1/1/1:50) and a wildcard SAP on the same port (1/1/1:*) it is important to understand how the ETH-CFM packets are handled. Any ETH-CFM packet with etype 0x8902 arriving with a single tag or 50 would be mapped to a classic MEP configured under SAP 1/1/1:50. Any packet arriving with an outer VLAN of 50 and second VLAN of 10 would be extracted by the 1/1/1:50 SAP and would require a primary VLAN enabled MEP with a value of 10, assuming the operator would like to extract the ETH-CFM PDU of course. An inbound packet on 1/1/1 with an outer VLAN tag of 10 would be mapped to the SAP 1/1/1:*. If ETH-CFM extraction is required under SAP 1/1/1:* a primary VLAN enabled MEP with a value of 10 would be required.
The packet that is generated from a MEP or MIP with the primary VLAN enabled is include that VLAN. The SAP encapsulates the primary VLAN using the SAP encapsulation.
Primary VLAN support includes UP MEPs, DOWN MEPs and MIPs on Ethernet SAPs, including LAG, as well as SDP bindings for Epipe and VPLS services. Classic MEPs, those without a primary VLAN enabled, and a primary VLAN enabled MEPs can coexist under the same SAP or SDP binding. Classic MIPs and primary VLAN-enabled MIPs may also coexist. The enforcement of a single classic MIP per SAP or SDP binding continues to be enforced. However, the operator may configure multiple primary VLAN-enabled MIPs on the same SAP or SDP binding. MIPs in the primary VLAN space must include the mhf-creation static configuration under the association and must also include the specific VLAN on the MIP creation statement under the SAP. The no version of the mip command must include the entire statement including the VLAN information.
The eight MD Levels (0 to 7) are specific to context in which the Management Point (MP) is configured. This means the classic MPs have a discrete set of the levels from the primary VLAN enabled space. Each primary VLAN space has its own eight Level MD space for the specified primary VLAN. Consideration must be exteneded before allowing overlapping levels between customers and operators should the operator be provision a customer facing MP, like a MIP on a UNI. CPU Protection extensions for ETH-CFM are VLAN unaware and based on MD Level and the OpCode. Any configured rates are applied to the Level and OpCode as a group.
There are two configuration steps to enable the primary VLAN. Under the bridging instance, contained within the association context (config>eth-cfm>domain>assoc>bridge), the VLAN information must be configured. Until this is enabled using the primary-vlan-enable option as part of the MEP creation step or the MIP statement (config>service>…>{sap | mesh-sdp | spoke-sdp}>eth-cfm) the VLAN specified under the bridging instance remains inactive. This is to ensure backward interoperability.
Primary VLAN functions require an FP2-based card or better. Primary VLAN is not supported for vpls-sap-templates, sub-second CCM intervals, or vMEPs.
An operator may see the following INFO message (during configuration reload), or MINOR (error) message (during configuration creation) when upgrading to 11.0r4 or later if two MEPs are in a previously undetected conflicting configuration. The messaging is an indication that a MEP, the one stated in the message using format (domain md-index/association ma-index/mep mep-id), is already configured and has allocated that context. During a reload (INFO) a MEP that encounters this condition is created but its state machine is disabled. If the MINOR error occurs during a configuration creation this MEP fails the creation step. The indicated MEP must be correctly re-configured.
INFO: ETH_CFM #1341 Unsupported MA ccm-interval for this MEP - MEP 1/112/
21 conflicts with sub-second config on this MA
MINOR: ETH_CFM #1341 Unsupported MA ccm-interval for this MEP - MEP 1/112/
21 conflicts with sub-second config on this MA
Service data arriving at an ingress SAP performs several parsing operations to map the packet to the service as well as to VLAN functions. VLAN functions include determinating the service-delineated VLANs based on the ingress configuration. Locally-generated CFM packets are unaware of the ingress VLAN functions. This may lead to service data and CFM data tagging alignment issues when the egress connection is a binding. For example, if the SDP is configured with vc-type vlan and the binding referencing the SDP does not specify the VLAN tag with the optional vlan-vc-tag vlan-id configuration, the service data crossing the service and the locally-generated CFM packets can use different VLAN tags. A problem can occur if this VLAN is significant to the peer. Similarly, an EVPN service cannot specify the vlan-vc-tag vlan-id to be used on the binding.
The optional cfm-vlan-tag <qtag1[.<qtag2>]> command used for MEP and MIP configurations supports the alignment of service data and the locally generated CFM packet VLAN tags for bindings that require matching VLAN tags. The qtag configuration should typically match the ingress SAP configuration. For example, a SAP that is configured with an enacp-type qinq and the associated SAP of 100.* should consider using the cfm vlan- tag 100 configuration option under the MEP or MIP, when a situation describing misalignment of VLAN tags is encountered.
The cfm-vlan-tag <qtag1[.<qtag2>]> command option is supported for VPLS and Epipe services only.
The cfm-vlan-tag <qtag1[.<qtag2>]> command option is not supported for the following cases:
when the configuration requires the CFM to include more than two VLAN tags, which may cause a configuration error; invalid configurations include a MEP or MIP configured with a primary-vlan-enable vlan-id and both tags specified of the cfm-vlan-tag <qtag1[.<qtag2>]>
when the MIP creation does not include the MIP configuration statement under the service, specifically, the default behavior MIP that is created solely based on the associated MHF creation
when the context is config>service>template vpls-sap-template
for G.8031 (ETH-tunnel) and G.8032 (ETH-ring)
for a MIP on a PW-SAP