Results Summary and Analysis

Functional Service Attributes and Parameters

This category validates service functionalities and attributes defined for service types, including E-Line, E-LAN, E-Tree, and Access E-Line. It ensures these services meet the necessary operational characteristics and behaviors, such as Ethernet Virtual Connections (EVCs), VLAN handling, and service multiplexing.

Table 1 summarizes functional testing included in the JVD. For additional test information, see the Test Report Brief or contact your Juniper representative.

In each case, the number of endpoints is adjusted based on the service type. For example, E-LAN and E-Tree include a minimum of 3 sites, and E-Line is always two sites. As a result, test cases have additional multipliers (not shown below) to validate all possible combinations.

The Access E-Line test cases share similar functional goals as E-Line, E-LAN, and E-Tree but with a focus on validating OVC endpoints related to ENNI operations with single and double-tagged frames.

Functional Test Cases: PASS

L2CP and SOAM Frame Behavior

This category tests the handling of Layer 2 Control Protocols (L2CP) and Service OAM (SOAM) frames, ensuring they are properly processed and managed by the system. It involves testing the correct tunneling and forwarding of control and management frames (for example, CCM, LBM, LTM, LTR). The validation ensures frames are properly identified and handled according to MEF network operation and maintenance standards. Where applicable, Class of Service attributes are included.

L2CP test cases are validated based on MEF frame handling expectations (MEF 45.1). The treatment of L2CP frames is dependent on whether the service is C-TAG Aware (CTA) or C-TAG Blind (CTB). In this context, CTA is referenced as VLAN-based, and CTB is referenced as a port-based service type.

JUNOS-Evolved ACX devices leverage the [mef-forwarding-profile] persona to allow customers flexible default behaviors for handling L2CP frame filtering. Without the MEF forwarding profile, the majority of L2CP MAC types are forwarded by design. Once the MEF forwarding profile is enabled, key L2CP MACs are filtered or forwarded based on MEF expectations for VLAN-based (CTA) or port-based (CTB) services. For strict alignment, firewall filtering allows selective MAC filtering treatment. Both approaches are used in the JVD with all configurations provided.

Table 2 explains MEF test cases comparing JUNOS-EVO behavior with and without enabling the MEF forwarding profile. By default, MX Series Routers implement the MEF Profile behavior without additional configuration.

For VLAN-based services, the expectation is to filter all L2CP MACs. This is the behavior when configuring the MEF forwarding profile. For additional test information, see the Test Report Brief or contact your Juniper representative.

L2CP Test Cases: PASS

For Port-based services, the behavior is slightly different with more transparent processing of L2CP frames. In this case, with the MEF Profile configured, most L2CP MACs specified in MEF 45.1 have matching behavior, but the default actions allow extensibility to support CTB Option-2. A firewall filter can be used to filter the additional L2CP MACs selectively. For additional test information, see the Test Report Brief or contact your Juniper representative.

L2CP Test Cases: PASS

The L2CP validation includes the MEF forwarding profile configuration on ACX7000 platforms with an additional filter-set to match MEF CTB behavior expectations. The UNI configuration is applicable to any device with [ mef-forwarding-profile ] configuration. This configuration may be excluded for more selective L2CP processing behavior using only a firewall filter.

In this portion of the validation, two configuration variants are used. For VLAN-based services (CTA), only the MEF forwarding profile is used. MX Series Routers implement this behavior by default for VLAN-based services.

The second portion of the configuration (shown below) is for supporting port-based (CTB) services, which includes the MEF forwarding profile and an additional firewall filter for selectively discarding the specified L2CP MACs.

              VLAN-based and Port-based Services
system {
    packet-forwarding-options {
        mef-forwarding-profile;
    }
}
firewall {
    family ethernet-switching {
        filter l2cp {
            interface-specific;
            term discard-l2cp {
                from {
                    destination-mac-address {
                        01:80:c2:00:00:07/48;
                        01:80:c2:00:00:0e/48;
                        01:80:c2:00:00:20/48;
                        01:80:c2:00:00:21/48;
                        01:80:c2:00:00:22/48;
                        01:80:c2:00:00:23/48;
                        01:80:c2:00:00:2a/48;
                        01:80:c2:00:00:2d/48;
                        01:80:c2:00:00:2e/48;
                        01:80:c2:00:00:2f/48;
                        01:80:c2:00:00:2b/48;
                        01:80:c2:00:00:24/48;
                        01:80:c2:00:00:25/48;
                        01:80:c2:00:00:26/48;
                        01:80:c2:00:00:27/48;
                        01:80:c2:00:00:28/48;
                        01:80:c2:00:00:29/48;
                        01:80:c2:00:00:2c/48;
                    }
                }
                then {
                    count l2cp_discard;
                    discard;
                }
            }

For more information about the configurations used in this JVD and in Metro Ethernet Business Services JVD, see Juniper GitHub Repository or contact your Juniper representative.

Table 4 summarizes Service OAM testing included in the JVD. Every row represents multiple test cases where service frames are validated with different MEG Levels, each with high, medium, and low CoS attributes. For additional test information, please see the Test Report Brief or contact your Juniper representative.

Service OAM Test Cases: PASS

Bandwidth Profile Attributes and Parameters

This category verifies whether Bandwidth Profiles can meet the expectations for service delivery in Carrier Ethernet networks. It validates performance metrics like traffic policing to ensure proper traffic flow management in different service conditions.

The Bandwidth Profile (BWP) validates attributes such as the performance and enforcement of committed information rates (CIR), committed burst size (CBS), excess information rates (EIR), excess burst size, and traffic shaping to ensure that the service adheres to the agreed-upon bandwidth allocations. In addition, test cases include color-blind and color-aware functionalities, conformance for the delivery of different frame types, and validation of CoS behaviors.

Table 5 summarizes BWP testing included in the JVD. For additional test information, see Test Report Brief or contact your Juniper representative.

Bandwidth Profile Test Cases: PASS

Traffic is metered based on two-rate tricolor marking policers (TrTCM) largely defined by RFC4115. The following sample bandwidth profile is used in the validation and is applicable to ACX and MX Series Routers. Multiple bandwidth profiles are utilized throughout the validation depending on the MEF test case being executed. The following BWP is for the EVPL E-Line color-blind test case.

ACX7100 TrTCM Color-Blind Policer

firewall {
    family ccc {
        filter f_eline-evpn-vpws {
            interface-specific;
            term discard_pcp {
                from {
                    learn-vlan-1p-priority [ 6 7 ];
                }
                then {
                    count discard_pcp6_7;
                    discard;
                }
            }
            term high_class {
                from {
                    learn-vlan-1p-priority [ 5 4 ];
                }
                then {
                    three-color-policer {
                        two-rate high_policer;
                    }
                    count high_class;
                }
            }
            term medium_class {
                from {
                    learn-vlan-1p-priority [ 3 2 ];
                }
                then {
                    three-color-policer {
                        two-rate medium_policer;
                    }
                    count class_medium;
                }
            }
            term low_class {
                from {
                    learn-vlan-1p-priority [ 0 1 ];
                }
                then {
                    three-color-policer {
                        two-rate low_policer;
                    }
                    count class_low;
                }
            }
            term default {
                then {
                    three-color-policer {
                        two-rate low_policer;
                    }
                    count default;
                }
            }
        }
    three-color-policer high_policer {
        action {
            loss-priority high then discard;
        }
        two-rate {
            color-blind;
            committed-information-rate 3500000000;
            committed-burst-size 35k;
            peak-information-rate 3500000000;
            peak-burst-size 35125;
        }
    }
    three-color-policer low_policer {
        action {
            loss-priority high then discard;
        }
        two-rate {
            color-blind;
            committed-information-rate 22k;
            committed-burst-size 125;
            peak-information-rate 3500000000;
            peak-burst-size 35k;
        }
    }
    three-color-policer medium_policer {
        action {
            loss-priority high then discard;
        }
        two-rate {
            color-blind;
            committed-information-rate 3500000000;
            committed-burst-size 35k;
            peak-information-rate 7g;
            peak-burst-size 70k;
        }
    }
}

The learn-vlan-1p-priority attribute matches the IEEE 802.1p VLAN priority in the outer position. In this example, the test case calls for matching traffic marked with 802.1p priority bits [6, 7] and discarding these packets while performing two-rate tricolor marking in color-blind mode, policing traffic individually classified as high, medium, and low. The policer is constructed with three main components:

• Two-Rate defines two bandwidth limits: guaranteed or Committed Information Rate (CIR) and Committed Burst Size (CBS); Peak Information Rate (PIR) and Peak Burst Size (PBS).
• Tricolor marking categorizes traffic as Green, Yellow, or Red. Policers may mark traffic (soft policing) or elect to discard traffic exceeding PIR (hard policing). In the example, traffic marked with an implicit loss priority of high (red) is discarded.
  • Green traffic conforms to the defined guaranteed bandwidth (CIR) and burst (CBS) limits. Green traffic is given an implicit Packet Loss Priority (PLP) of low.
  • Yellow traffic exceeds the committed (CIR) or burst (CBS) rates but remains within the peak (PIR) and burst (PBS) rates. Yellow traffic is given a PLP of medium-high.
  • Red traffic exceeds PIR or PBS and is given a PLP of high.
• Color Mode defines if the policer is color-blind or color-aware. In color-blind mode, the policer ignores any premarked packets. In color-aware mode, the policer becomes cognizant of previously marked or metered packets and inspects the packet’s loss priority to be treated accordingly. The PLP value can be raised but not lowered. In other words, a packet received with a yellow loss priority (medium-high) can be marked as red but cannot be remarked as green.

The following configuration provides an example of a TrTCM color-aware mode policer utilized for an Access E-Line BWP test scenario. In this case, a cascade policer hierarchy is created by marking and metering traffic onto the next term to be aggregated and considered with other matching traffic priorities in the same policer.

The Coupling Flag (CF) attribute determines how yellow-marked traffic is handled, that is, traffic exceeding the CIR token bucket. When CF is enabled (CF=1), yellow frames equate to CIR+PIR and are not discarded when exceeding CIR. When CF is disabled (CF=0), yellow service frames exceeding CIR are discarded (CIR=PIR). MX Series Routers leverage CF=1 by default but can be configured for CF=0 by simply matching on the PLP and discarding (see CF0-yellow).

MX TrTCM Color-Aware Policer

firewall {
    family bridge {
        filter f-epl-option-1 {
            interface-specific;
            term high_class_discard {
                from {
                    learn-vlan-1p-priority [ 6 7 ];
                }
                then {
                    count pcp_6_7;
                    discard;
                }
            }
            term high_class {
                from {
                    learn-vlan-1p-priority 4;
                }
                then {
                    count high_pcp4;
                    loss-priority high;
                    next term;
                }
            }
            term color-envelop {
                from {
                    learn-vlan-1p-priority [ 5 4 ];
                }
                then {
                    three-color-policer {
                        two-rate high_policer;
                    }
                    count color-envelop;
                }
            }
            term medium_class-3 {
                from {
                    learn-vlan-1p-priority 3;
                }
                then {
                    three-color-policer {
                        two-rate medium_policer;
                    }
                    count med-3;
                    accept;
                }
            }
            term medium_class-2 {
                from {
                    learn-vlan-1p-priority 2;
                }
                then {
                    three-color-policer {
                        two-rate medium_policer;
                    }
                    count med-2;
                    next term;
                }
            }
            term CF0-yellow {
                from {
                    loss-priority medium-high;
                    learn-vlan-1p-priority 2;
                }
                then {
                    count CFO-yellow;
                    discard;
                }
            }
            term low_class {
                from {
                    learn-vlan-1p-priority [ 0 1 ];
                }
                then {
                    three-color-policer {
                        two-rate low_policer;
                    }
                    count low_class;
                }
            }
            term deault {
                then count default_traffic;
                }
            }
        }
    }
    three-color-policer high_policer {
        action {
            loss-priority high then discard;
        }
        two-rate {
            color-aware;
            committed-information-rate 3500000000;
            committed-burst-size 35k;
            peak-information-rate 3500000000;
            peak-burst-size 35125;
        }
    }
    three-color-policer low_policer {
        action {
            loss-priority high then discard;
        }
        two-rate {
            color-aware;
            committed-information-rate 22k;
            committed-burst-size 1500;
            peak-information-rate 3500000000;
            peak-burst-size 35k;
        }
    }
    three-color-policer medium_policer {
        action {
            loss-priority high then discard;
        }
        two-rate {
            color-aware;
            committed-information-rate 3500000000;
            committed-burst-size 35k;
            peak-information-rate 7g;
            peak-burst-size 70k;
        }
    }
}

For more information about the configurations used in this JVD and in Metro Ethernet Business Services JVD, see Juniper GitHub Repository or contact your Juniper representative.

Service Performance Attributes and Parameters

This category tests performance characteristics like latency, jitter, Frame Loss Ratio (FLR), and availability in compliance with the specified Service Level Agreements (SLAs). It ensures that the service can meet the agreed-upon performance parameters for various traffic types (for example, unicast, multicast, broadcast) under real-world conditions, validating that service performance aligns with customer requirements.

Multiple test cases are executed for each topic, measuring one-way metrics in all directions based on the service type. The table below summarizes Performance testing included in the JVD. For additional test information, please see the Test Report Brief or contact your Juniper representative.

Performance Test Cases: PASS

E-LINE Test Results Summary

Details of E-Line validation are available in the Metro as a Service: E-LINE section. Table 21 explains the E-Line service attributes and test scenarios applicable to MEF 3.0 certification and JVD validation. The scope of the validation aligns with MEF test requirements for E-Line:

• UNI Service Attributes and Test Requirements
• EVC Service Attributes and Test Requirements
• EVC per-UNI Service Attributes and Test Requirements

The tables provided in this section are based on MEF 91 Carrier Ethernet Test Requirements. The Certification Applicability column does not always equate to a mandatory requirement. Additional context is explained in the table descriptions and reference technical specifications. For example, some parameters may be [Enabled or Disabled] or [MUST be No] based on the defined MEF technical specifications. These may translate to optional or mandatory only under optional conditions. In such cases, the JVD may include or exclude these scenarios.

The JVD Test Coverage column confirms the attributes that are included and validated in the course of execution.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

2 Protocols not on the list are either Passed to EVC or Discarded based on the Destination Address.

3 Service Multiplexing requires the instantiation of at least two services at the UNI, which is outside the scope of the MEF 3.0 CE certification program. This is covered in the JVD.

J1 UNI Resiliency is not mandated by MEF but included in the JVD as a foundational attribute with EVPN all-active ESI and further explained in Metro Ethernet Business Services JVD.

J2 MEF 10.4 updates Egress Equivalence Class Service to an optional attribute and is no longer included in MEF 3.0.

J3 Optional but covered in JVD.

Reference: MEF 91 Carrier Ethernet Test Requirements

4 CE-VLAN ID Preservation testing includes the Service Frame Transparency verification.

J3 Optional but covered in JVD.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

5 Optional attribute. Supported but not covered in JVD.

J2 MEF 10.4 updates Egress Equivalence Class Service to an optional attribute and is no longer included in MEF 3.0.

J3 Optional but covered in JVD.

E-LAN Test Results Summary

E-LAN validation details are available in the Metro as a Service: E-LAN section. Table 10 explains the E-LAN service attributes and test scenarios applicable to MEF 3.0 certification and what is covered by the validation. The scope of the validation aligns with MEF test requirements for E-LAN:

• UNI Service Attributes and Test Requirements
• EVC Service Attributes and Test Requirements
• EVC per-UNI Service Attributes and Test Requirements

The tables provided in this section are based on MEF 91 Test Requirements. The Certification Applicability column does not always equate to a mandatory requirement. Additional context is explained in the table descriptions and reference technical specifications. For example, some parameters may be [Enabled or Disabled] or [MUST be No] based on the defined MEF technical specifications. These parameters may translate to optional or mandatory only under optional conditions. In such cases, the JVD may include or exclude these scenarios.

The JVD Test Coverage column confirms the attributes that are included and validated in the course of execution.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

2 Protocols not on the list are either Passed to EVC or Discarded based on the Destination Address.

3 Service Multiplexing requires the instantiation of at least two services at the UNI, which is outside the scope of the MEF 3.0 CE certification program. This is covered in the JVD.

J1 UNI Resiliency is not mandated by MEF but included in the JVD as a foundational attribute with EVPN all-active ESI and further explained in Metro Ethernet Business Services JVD.

J2 MEF 10.4 updates Egress Equivalence Class Service to an optional attribute and is no longer included in MEF 3.0.

J3 Optional but covered in JVD.

Reference: MEF 91 Carrier Ethernet Test Requirements

4 CE-VLAN ID Preservation testing includes the Service Frame Transparency verification.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

4 Refer to Egress Bandwidth Profile per Egress Equivalence Class.

5 Optional attribute. Supported but not covered in JVD.

J2 MEF 10.4 updates Egress Equivalence Class Service to an optional attribute and is no longer included in MEF 3.0.

J3 Optional but covered in JVD.

E-TREE Test Results Summary

E-Tree validation details are available in the Metro as a Service: E-TREE section. Table 26 explains the E-Tree service attributes and test scenarios applicable to MEF 3.0 certification and what is covered by in the validation. The scope of the validation aligns with MEF test requirements for E-Tree:

• UNI Service Attributes and Test Requirements
• EVC Service Attributes and Test Requirements
• EVC per-UNI Service Attributes and Test Requirements

The tables provided in this section are based on MEF 91 Test Requirements. The Certification Applicability column does not always equate to a mandatory requirement. Additional context is explained in the table descriptions and reference technical specifications. For example, some parameters may be [Enabled or Disabled] or [MUST be No] based on the defined MEF technical specifications. These may translate to optional or mandatory only under optional conditions. In such cases, the JVD may include or exclude these scenarios. Only the EVP-Tree service type is included in the validation, as reflected in the table.

The JVD Test Coverage column confirms the attributes that are included and validated in the course of execution.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

2 Protocols not on the list are either Passed to EVC or Discarded based on the Destination Address.

3 Service Multiplexing requires the instantiation of at least two services at the UNI, which is outside the scope of the MEF 3.0 CE certification program. This is covered in the JVD.

J1 UNI Resiliency is not mandated by MEF but included in the JVD as a foundational attribute with EVPN all-active ESI and further explained in Metro Ethernet Business Services JVD.

J2 MEF 10.4 updates Egress Equivalence Class of Service to an optional attribute and is no longer included in MEF 3.0.

J3 Optional but covered in JVD.

J4 All-to-One Bundling is an EP-Tree service. Supported but not covered in the JVD.

Reference: MEF 91 Carrier Ethernet Test Requirements

4 CE-VLAN ID Preservation testing includes the Service Frame Transparency verification.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

4 Refer to Egress Bandwidth Profile per Egress Equivalence Class.

5 Optional attribute. Supported but not covered in JVD.

J2 MEF 10.4 updates Egress Equivalence Class Service to an optional attribute and is no longer included in MEF 3.0.

J3 Optional but covered in JVD.

Access E-LINE (E-Access) Test Results Summary

Access E-Line validation details are available in the Metro as a Service: Access E-LINE section. Table 16 explains the Access E-Line service attributes and test scenarios applicable to MEF 3.0 certification and what is covered in the validation. The scope of the validation aligns with MEF test requirements for Access E-Line:

• Operator UNI Service Attributes and Test Requirements
• EVC Service Attributes and Test Requirements
• EVC per-UNI Service Attributes and Test Requirements

The tables provided in this section are based on MEF 91 Test Requirements. The Certification Applicability column does not always equate to a mandatory requirement. Additional context is explained in the table descriptions and reference technical specifications. For example, some parameters may be [Enabled or Disabled] or [MUST be No] based on the defined MEF technical specifications. These may translate to optional or mandatory only under optional conditions. In such cases, the JVD may include or exclude these scenarios.

The JVD Test Coverage column confirms the attributes that are included and validated in the course of execution.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

2 Protocols not on the list are either Passed to EVC or Discarded based on the Destination Address.

3 Ingress Bandwidth Profile per Class of Service Identifier is mandatory for Access E-Line and Transit E-Line services. Other ingress or egress bandwidth profiles in combination with Ingress Bandwidth Profile per Class of Service Identifier are to be handled between subscriber/service provider/operator. Ingress Bandwidth Profile is included in the JVD.

Reference: MEF 91 Carrier Ethernet Test Requirements

Reference: MEF 91 Carrier Ethernet Test Requirements

3 Ingress Bandwidth Profile per Class of Service Identifier is mandatory for Access E-Line and Transit E-Line services. Other ingress or egress bandwidth profiles in combination with Ingress Bandwidth Profile per Class of Service Identifier are to be handled between subscriber/service provider/operator. Ingress Bandwidth Profile is included in the JVD.

5 Optional attribute Supported but not covered in JVD.

Reference: MEF 91 Carrier Ethernet Test Requirements

1 As per MEF 91, control and management protocols such as E-LMI, Link OAM, Service OAM UNI-MEG, Service OAM ENNI-MEG, Test MEG, or protection mechanisms that may be operating at the external interfaces are outside the scope of the MEF 3.0 CE certification program. The deployment and verification of these protocols are to be handled between subscriber/service provider/operator.

2 Protocols not on the list are either Passed to EVC or Discarded based on the Destination Address.