<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-bess-evpn-vpws-fxc-12" number="9744" consensus="true" submissionType="IETF" ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" xml:lang="en" updates="" obsoletes="" prepTime="2025-03-15T22:45:00" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9744" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="EVPN-VPWS FXC Service">EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) Service</title>
    <seriesInfo name="RFC" value="9744" stream="IETF"/>
    <author fullname="Ali Sajassi" initials="A." surname="Sajassi" role="editor">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <email>sajassi@cisco.com</email>
      </address>
    </author>
    <author fullname="Patrice Brissette" initials="P." surname="Brissette">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <email>pbrisset@cisco.com</email>
      </address>
    </author>
    <author fullname="James Uttaro" initials="J." surname="Uttaro">
      <organization showOnFrontPage="true">Individual</organization>
      <address>
        <email>juttaro@ieee.org</email>
      </address>
    </author>
    <author fullname="John Drake" initials="J." surname="Drake">
      <organization showOnFrontPage="true">Independent</organization>
      <address>
        <email>je_drake@yahoo.com</email>
      </address>
    </author>
    <author fullname="Sami Boutros" initials="S." surname="Boutros">
      <organization showOnFrontPage="true">Ciena</organization>
      <address>
        <email>sboutros@ciena.com</email>
      </address>
    </author>
    <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
      <organization showOnFrontPage="true">Nokia</organization>
      <address>
        <email>jorge.rabadan@nokia.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>bess</workgroup>
    <keyword>EVPN</keyword>
    <keyword>VPWS</keyword>
    <keyword>Flexible Cross-Connect</keyword>
    <keyword>FXC</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes a new EVPN Virtual Private Wire Service (VPWS) service type specifically for
      multiplexing multiple attachment circuits across different Ethernet
      Segments (ESs) and physical interfaces into a single EVPN-VPWS service tunnel
      and still providing Single-Active and All-Active multi-homing.  This new
      service is referred to as the EVPN-VPWS Flexible Cross-Connect (FXC) service.
      This document specifies a solution based on extensions to EVPN-VPWS (RFC
      8214), which in turn is based on extensions to EVPN (RFC
      7432). Therefore, a thorough understanding of RFCs 7432 and 8214 are
      prerequisites for this document.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9744" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements">Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-solution">Solution</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vpws-service-identifiers">VPWS Service Identifiers</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-default-flexible-cross-conn">Default Flexible Cross-Connect</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-homing">Multi-homing</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vlan-signaled-fxc">VLAN-Signaled FXC</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-local-switching">Local Switching</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-service-instantiation">Service Instantiation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bgp-extensions">BGP Extensions</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-failure-scenarios">Failure Scenarios</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-evpn-vpws-service-failure">EVPN-VPWS Service Failure</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-attachment-circuit-failure">Attachment Circuit Failure</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pe-port-failure">PE Port Failure</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pe-node-failure">PE Node Failure</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1"><xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> describes a solution to deliver
      point-to-point (P2P) services using BGP constructs defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>. It delivers this P2P service between a pair of
      Attachment Circuits (ACs), where an AC on a PE can represent a port, a
      VLAN on a port, or a group of VLANs on a port. It also leverages
      multi-homing and fast convergence capabilities of <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> in delivering these VPWS services. Multi-homing
      capabilities include the support of Single-Active and All-Active
      redundancy mode, and fast convergence is provided using a "mass
      withdrawal" message in control plane and fast protection switching using
      prefix-independent convergence in a data plane upon node or link failure
      <xref target="I-D.ietf-rtgwg-bgp-pic" format="default" sectionFormat="of" derivedContent="BGP-PIC"/>.  Furthermore, the use of EVPN
      BGP constructs eliminates the need for multi-segment pseudowire
      auto-discovery and signaling if the VPWS service need to span across
      multiple Autonomous Systems (ASes) <xref target="RFC5659" format="default" sectionFormat="of" derivedContent="RFC5659"/>.</t>
      <t indent="0" pn="section-1-2">Service providers have a very large number of ACs (in millions) that
      need to be backhauled across their MPLS/IP network. These ACs may or may
      not require tag manipulation (e.g., VLAN translation).  These service
      providers want to multiplex a large number of ACs across several
      physical interfaces spread across one or more PEs (e.g., several
      ESs) onto a single VPWS service tunnel in order to a)
      reduce the number of EVPN service labels associated with EVPN-VPWS service
      tunnels and thus the associated Operations, Administration, and Maintenance (OAM) monitoring and b) reduce EVPN BGP
      signaling (e.g., not to signal each AC as it is the case in <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>).</t>
      <t indent="0" pn="section-1-3">Service providers want the above functionality without sacrificing
      any of the capabilities of <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> including
      Single-Active and All-Active multi-homing and fast convergence.</t>
      <t indent="0" pn="section-1-4">This document specifies a solution based on extensions to EVPN-VPWS
      <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> to meet the above requirements. Furthermore,
      <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> is itself based on extensions to EVPN <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>.  Therefore, a thorough understanding of <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> are prerequisites for
      this document. </t>
      <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl newline="false" spacing="normal" indent="3" pn="section-1.1-1">
          <dt pn="section-1.1-1.1">AC:</dt>
          <dd pn="section-1.1-1.2">Attachment Circuit</dd>
          <dt pn="section-1.1-1.3">ES:</dt>
          <dd pn="section-1.1-1.4">Ethernet Segment</dd>
          <dt pn="section-1.1-1.5">ESI:</dt>
          <dd pn="section-1.1-1.6">Ethernet Segment Identifier</dd>
          <dt pn="section-1.1-1.7">EVI:</dt>
          <dd pn="section-1.1-1.8">EVPN Instance Identifier</dd>
          <dt pn="section-1.1-1.9">EVPN:</dt>
          <dd pn="section-1.1-1.10">Ethernet Virtual Private Network</dd>
          <dt pn="section-1.1-1.11">Ethernet A-D:</dt>
          <dd pn="section-1.1-1.12">Ethernet Auto-Discovery (per EVI or per Ethernet A-D per ESI
          routes, as defined in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/> and <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>)</dd>
          <dt pn="section-1.1-1.13">FXC:</dt>
          <dd pn="section-1.1-1.14">Flexible Cross-Connect</dd>
          <dt pn="section-1.1-1.15">MAC:</dt>
          <dd pn="section-1.1-1.16">Media Access Control</dd>
          <dt pn="section-1.1-1.17">MPLS:</dt>
          <dd pn="section-1.1-1.18">Multiprotocol Label Switching</dd>
          <dt pn="section-1.1-1.19">OAM:</dt>
          <dd pn="section-1.1-1.20">Operations, Administration, and Maintenance</dd>
          <dt pn="section-1.1-1.21">PE:</dt>
          <dd pn="section-1.1-1.22">Provider Edge</dd>
          <dt pn="section-1.1-1.23">VCCV:</dt>
          <dd pn="section-1.1-1.24">Virtual Circuit Connectivity Verification</dd>
          <dt pn="section-1.1-1.25">VID:</dt>
          <dd pn="section-1.1-1.26">VLAN ID</dd>
          <dt pn="section-1.1-1.27">VPWS:</dt>
          <dd pn="section-1.1-1.28">Virtual Private Wire Service</dd>
          <dt pn="section-1.1-1.29">VRF:</dt>
          <dd pn="section-1.1-1.30">VPN Routing and Forwarding</dd>
          <dt pn="section-1.1-1.31">IP-VRF:</dt>
          <dd pn="section-1.1-1.32">VPN Routing and Forwarding for IP lookup</dd>
          <dt pn="section-1.1-1.33">MAC-VRF:</dt>
          <dd pn="section-1.1-1.34">VPN Routing and Forwarding for MAC lookup</dd>
          <dt pn="section-1.1-1.35">VID-VRF:</dt>
          <dd pn="section-1.1-1.36">VPN Routing and Forwarding for normalized VID lookup</dd>
          <dt pn="section-1.1-1.37">VPWS Service Tunnel:</dt>
          <dd pn="section-1.1-1.38">It is represented by a pair of EVPN service labels associated
          with a pair of endpoints. Each label is downstream assigned and
          advertised by the disposition PE through an Ethernet A-D per EVI
          route. The downstream label identifies the endpoint on the
          disposition PE. A VPWS service tunnel can be associated with many
          VPWS service identifiers where each identifier is a normalized
          VID.</dd>
          <dt pn="section-1.1-1.39">Single-Active Redundancy Mode:</dt>
          <dd pn="section-1.1-1.40">When a device or a network is multi-homed to two or more PEs and
          when only a single PE in such redundancy group can forward traffic
          to/from the multi-homed device or network for a given VLAN, then
          such multi-homing or redundancy is referred to as
          "Single-Active".</dd>
          <dt pn="section-1.1-1.41">All-Active Redundancy Mode:</dt>
          <dd pn="section-1.1-1.42">When a device or a network is multi-homed to two or more PEs and
          when all PEs in such redundancy group can forward traffic to/from
          the multi-homed device or network for a given VLAN, then such
          multi-homing or redundancy is referred to as "All-Active".</dd>
        </dl>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
      to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
      shown here.
        </t>
      </section>
    </section>
    <section anchor="requirements" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-requirements">Requirements</name>
      <t indent="0" pn="section-2-1">Two of the main motivations for service providers seeking a new
      solution are: 1) to reduce the number of VPWS service tunnels by
      multiplexing a large number of ACs across different physical interfaces
      instead of having one VPWS service tunnel per AC and 2) to reduce the
      signaling of ACs as much as possible. Besides these two requirements,
      they also want the multi-homing and fast convergence capabilities of
      <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>.</t>
      <t indent="0" pn="section-2-2">In <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>, a PE signals an AC indirectly by first
      associating that AC to a VPWS service tunnel (e.g., a VPWS service
      instance) and then signaling the VPWS service tunnel via an Ethernet A-D
      per EVI route with the Ethernet Tag field set to a 24-bit VPWS service
      instance identifier (which is unique within the EVI) and the ESI field
      set to a 10-octet identifier of the ES corresponding to
      that AC.</t>
      <t indent="0" pn="section-2-3">Therefore, a PE device that receives such EVPN routes can associate
      the VPWS service tunnel to the remote ES using the ESI field.
      Additionally, when the remote ES fails and the PE receives the "mass
      withdrawal" message associated with the failed ES per <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, a PE device can quickly update its
      next-hop adjacency list (adjacency list) for all VPWS service tunnels
      sharing the ESI field and achieve fast convergence for multi-homing
      scenarios.  Even if fast convergence were not needed, there would still
      be a need for signaling each AC failure (via its corresponding VPWS
      service tunnel) associated with the failed ES so that the adjacency list
      gets updated and the packets are sent to a backup PE (in case of
      Single-Active multi-homing) or to other PEs in the redundancy group (in
      case of All-Active multi-homing). In the absence of updating the
      adjacency list properly, the traffic for that VPWS service tunnel will
      be dropped by the egress PE with a failed ES/AC.</t>
      <t indent="0" pn="section-2-4">When a single VPWS service tunnel carries multiple ACs across various
      ESs (physical interfaces) without signaling the ACs via
      EVPN BGP to remote PE devices, those remote PE devices lack the
      information to associate the received ES with these ACs or
      with their local ACs. They also lack the association between the VPWS
      service tunnel (e.g., EVPN service label) and the far-end ACs. This
      means that, while the remote PEs can associate their local ACs with the
      VPWS service tunnel, they cannot make similar associations for the
      far-end ACs.</t>
      <t indent="0" pn="section-2-5">Consequently, in case of a connectivity failure to the ES, the remote
      PEs are unable to redirect traffic via another multi-homing PE to that
      ES. In other words, even if an ES failure is signaled via EVPN to the
      remote PE devices, they cannot effectively respond because they do not
      know the relationship between the remote ES, the remote ACs, and the
      VPWS service tunnel.</t>
      <t indent="0" pn="section-2-6">To address this issue when multiplexing a large number of ACs onto a
      single VPWS service tunnel, two mechanisms have been developed: one to
      support VPWS services between two single-homed endpoints and another one to
      support VPWS services where one of the endpoints is multi-homed.</t>
      <t indent="0" pn="section-2-7">For single-homed endpoints, it is acceptable not to signal each AC in
      BGP because, in the event of a connection failure to the ES, there is no
      alternative path to that endpoint. However, the implication of not
      signaling an AC failure is that the traffic destined for the failed AC
      is sent over the MPLS/IP core and then discarded at the destination PE,
      thereby potentially wasting network resources.</t>
      <t indent="0" pn="section-2-8">This waste of network resources during a connection failure may be
      transient, as it can be detected and prevented at the application layer
      in certain cases. <xref target="fxc" format="default" sectionFormat="of" derivedContent="Section 3.2"/> outlines a solution for such
      single-homing VPWS services.</t>
      <t indent="0" pn="section-2-9">For VPWS services where one of the endpoints is multi-homed, there
      are two options: </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-10">
	<li pn="section-2-10.1" derivedCounter="1.">Signal each AC via BGP, allowing the adjacency list to be updated
	upon a failure affecting those ACs. This solution is described in
	<xref target="vlan_sig_fxc" format="default" sectionFormat="of" derivedContent="Section 3.3"/> and is referred to as the "VLAN-signaled
	FXC service".</li>
        <li pn="section-2-10.2" derivedCounter="2.">Bundle several ACs on an ES together per destination endpoint
	(e.g., ES, MAC-VRF, etc.) and associate such a bundle with a single
	VPWS service tunnel. This approach is similar to the VLAN bundle
	service interface described in <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>. This solution
	is described in <xref target="fxc_mh" format="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</li>
      </ol>
    </section>
    <section anchor="solution" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-solution">Solution</name>
      <t indent="0" pn="section-3-1">This section specifies how to provide a new VPWS service between two
      PE devices where a large number of ACs (such as VLANs) that span across
      multiple ESs (physical interfaces) on each PE are
      multiplexed onto a single P2P EVPN service tunnel. Since the
      multiplexing involves several physical interfaces, there can be
      overlapping VLAN IDs (VIDs) across these interfaces. In such cases, the
      VIDs must be translated into unique VIDs to prevent collisions.
      Furthermore, if the number of VLANs being multiplexed onto a single VPWS
      service tunnel exceeds 4095, then a single tag to double tag translation
      must be performed. This translation of VIDs into unique VIDs (either
      single or double) results in a "normalized VID".</t>
      <t indent="0" pn="section-3-2">When a single normalized VID is used, the lower 12 bits of the
      Ethernet Tag ID field in EVPN routes <bcp14>MUST</bcp14> be set to that
      VID. When a double normalized VID is used, the lower 12 bits of the
      Ethernet Tag ID field <bcp14>MUST</bcp14> be set to the inner VID, while
      the higher 12 bits are set to the outer VID.  24-bit VPWS service
      instance identifiers <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> as well as 12-bit VPWS
      service instance identifiers representing normalized VIDs
      <bcp14>MUST</bcp14> be right-aligned. </t>
      <t indent="0" pn="section-3-3">Since there is only a single EVPN-VPWS service tunnel associated with
      many normalized VIDs (either single or double) across multiple physical
      interfaces, an MPLS lookup at the disposition PE is no longer sufficient
      to forward the packet to the correct egress endpoint or
      interface. Therefore, in addition to an EVPN label lookup corresponding
      to the VPWS service tunnel, a VID lookup (either single or double) is
      also required. At the disposition PE, the EVPN label lookup identifies a
      VID-VRF, and the lookup of the normalized VIDs within that table
      identifies the appropriate egress endpoint or interface. The tag
      manipulation (translation from normalized VIDs to the local VID)
      <bcp14>SHOULD</bcp14> be performed either as part of the VID table
      lookup or at the egress interface itself.</t>
      <t indent="0" pn="section-3-4">Since the VID lookup (single or double) needs to be performed at the
      disposition PE, VID normalization <bcp14>MUST</bcp14> be completed prior
      to MPLS encapsulation on the ingress PE. This requires that both the
      imposition and disposition PE devices be capable of VLAN tag
      manipulation, such as rewriting (single or double), adding, or deleting
      (single or double) at their endpoints (e.g., their ESs, MAC-VRFs,
      IP-VRFs, etc.).  Operators should be informed of potential trade-offs
      from a performance standpoint, compared to typical pseudowire
      processing.</t>
      <section anchor="svc_ids" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-vpws-service-identifiers">VPWS Service Identifiers</name>
        <t indent="0" pn="section-3.1-1">In <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>, a unique value identifying the service
        is signaled in the context of each PE's EVI. The 32-bit Ethernet Tag
        ID field <bcp14>MUST</bcp14> be set to this VPWS service instance
        identifier value. Translation at an Autonomous System Border Router
        (ASBR) is needed if re-advertising to another AS affects
        uniqueness.</t>
        <t indent="0" pn="section-3.1-2">For FXC, this same Ethernet Tag ID field value is an identifier that may represent:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-3">
          <li pn="section-3.1-3.1">VLAN Bundle Service Interface: a unique value for a group of
          VLANs</li>
          <li pn="section-3.1-3.2">VLAN-Aware Bundle Service Interface: a unique value for
          individual VLANs and is considered the same as the normalized VID</li>
        </ul>
        <t indent="0" pn="section-3.1-4">Both the VPWS service instance identifier and normalized VID are
        carried in the Ethernet Tag ID field of the Ethernet A-D per EVI
        route.  For FXC, in the case of a 12-bit ID, the VPWS service instance
        identifier is the same as the single-tag normalized VID and will be
        the same on both VPWS service endpoints. Similarly in the case of a
        24-bit ID, the VPWS service instance identifier is the same as the
        double-tag normalized VID.</t>
      </section>
      <section anchor="fxc" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-default-flexible-cross-conn">Default Flexible Cross-Connect</name>
        <t indent="0" pn="section-3.2-1">In this mode of operation, many ACs across several ESs are
        multiplexed into a single EVPN-VPWS service tunnel represented by a
        single VPWS service ID. This is the default mode of operation for FXC,
        and the participating PEs do not need to signal the VLANs (normalized
        VIDs) in EVPN BGP.</t>
        <t indent="0" pn="section-3.2-2">Regarding the data plane aspects of this solution, the imposition
        PE performs VID normalization, and the disposition PE carries out VID
        lookup and translation. Both imposition and disposition PE devices
        <bcp14>MUST</bcp14> be aware of the VLANs through configuration.
        There should ideally be a single point-to-point (P2P) EVPN-VPWS
        service tunnel between a pair of PEs for a specific set of ACs.</t>
        <t indent="0" pn="section-3.2-3">As previously mentioned, because the EVPN-VPWS service tunnel is
        employed to multiplex ACs across various ESs or
        physical interfaces, the EVPN label alone is not sufficient for
        accurate forwarding of the received packets over the MPLS/IP network
        to egress interfaces.  Therefore, normalized VID lookup is
        <bcp14>REQUIRED</bcp14> in the disposition direction to forward
        packets to their proper egress endpoints; the EVPN label lookup
        identifies a VID-VRF, and a subsequent normalized VID lookup in that
        table identifies the egress interface.</t>
        <t indent="0" pn="section-3.2-4">In this solution, for each PE, the single-homing ACs represented by
        their normalized VIDs are associated with a single VPWS service
        instance within a specific EVI.  The generated EVPN route is an
        Ethernet A-D per-EVI route with an ESI of 0, the Ethernet Tag field is
        set to a VPWS service instance ID, and the MPLS label field is set to
        a dynamically generated EVPN service label representing the EVPN-VPWS
        service tunnel. This route is sent with a Route Target (RT) that
        represents the EVI, which can be auto-generated from the EVI according
        to <xref target="RFC8365" section="5.1.2.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8365#section-5.1.2.1" derivedContent="RFC8365"/>.  Additionally, this
        route is sent with the EVPN Layer 2 Attributes Extended Community
        defined in <xref target="RFC8214" section="3.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8214#section-3.1" derivedContent="RFC8214"/>
        with two new flags (outlined in <xref target="bgp_extensions" format="default" sectionFormat="of" derivedContent="Section 4"/>) that
        indicate: 1) the VPW service tunnel (set to default Flexible
        Cross-Connect) and 2) the normalized VID type (set to normalized
        single VID or double VID). The receiving PE uses these new flags for a
        consistency check and <bcp14>MAY</bcp14> generate an alarm if it
        detects inconsistencies, but it will not disrupt the VPWS service.</t>
        <t indent="0" pn="section-3.2-5">It should be noted that in this mode of operation, a single
        Ethernet A-D per-EVI route is transmitted upon the configuration of
        the first AC with the normalized VID.  As additional ACs are
        configured and associated with this EVPN-VPWS service tunnel, the PE
        does not advertise any additional EVPN BGP routes and only locally
        associates these ACs with the pre-established VPWS service tunnel.</t>
        <section anchor="fxc_mh" numbered="true" removeInRFC="false" toc="include" pn="section-3.2.1">
          <name slugifiedName="name-multi-homing">Multi-homing</name>
          <t indent="0" pn="section-3.2.1-1">The default FXC mode can also be used for multi-homing. In this
        mode, a group of normalized VIDs representing ACs on a single ES, all
        destined to a single endpoint, are multiplexed into a single EVPN-VPWS
        service tunnel, which is identified by a unique VPWS service ID.  When
        employing the default FXC mode for multi-homing, rather than using a
        single EVPN-VPWS service tunnel, there may be multiple service tunnels
        per pair of PEs. Specifically, there is one tunnel for each group of
        VIDs per pair of PEs, and there can be many such groups between a pair
        of PEs, resulting in numerous EVPN service tunnels.</t>
        </section>
      </section>
      <section anchor="vlan_sig_fxc" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-vlan-signaled-fxc">VLAN-Signaled FXC</name>
        <t indent="0" pn="section-3.3-1">In this mode of operation, similar to the default FXC mode
        described in <xref target="fxc" format="default" sectionFormat="of" derivedContent="Section 3.2"/>, many normalized VIDs representing
        ACs across several ESs and interfaces are multiplexed into a
        single EVPN-VPWS service tunnel. However, this single tunnel is
        represented by multiple VPWS service IDs (one per normalized VID), and
        these normalized VIDs are signaled using EVPN BGP.</t>
        <t indent="0" pn="section-3.3-2">In this solution, on each PE, the multi-homing ACs represented by
        their normalized VIDs are configured with a single EVI. There is no
        need to configure a separate VPWS service instance ID in here, as it
        corresponds to the normalized VID. For each normalized VID on each
        ES, the PE generates an Ethernet A-D per-EVI route where
        the ESI field represents the ES ID, the Ethernet Tag field is set to
        the normalized VID, and the MPLS label field is set to a dynamically
        generated EVPN label representing the P2P EVPN service tunnel. This
        label is the same for all ACs multiplexed into a single EVPN-VPWS
        service tunnel. This route is sent with an RT representing the EVI. As
        before, this RT can be auto-generated from the EVI per <xref target="RFC8365" section="5.1.2.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8365#section-5.1.2.1" derivedContent="RFC8365"/>. Additionally, this route
        includes the EVPN Layer 2 Attributes Extended Community defined in <xref target="RFC8214" section="3.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8214#section-3.1" derivedContent="RFC8214"/> with two new flags (outlined in <xref target="bgp_extensions" format="default" sectionFormat="of" derivedContent="Section 4"/>) that indicate: 1) this VPWS service tunnel
        for VLAN-signaled FXC and 2) the normalized VID
        type (single versus double). The receiving PE uses these new flags for
        a consistency check and may generate an alarm if it detects
        inconsistency, but it will not disrupt the VPWS service.</t>
        <t indent="0" pn="section-3.3-3">It should be noted that in this mode of operation, the PE sends a
        single Ethernet A-D per-EVI route for each AC that is configured. Each
        normalized VID that is configured per ES results in generation of an
        Ethernet A-D per EVI.</t>
        <t indent="0" pn="section-3.3-4">This mode of operation enabled automatic cross-checking of
        normalized VIDs used for Ethernet Virtual Private Line (EVPL) services
        because these VIDs are signaled in EVPN BGP. For instance, if the same
        normalized VID is configured on three PE devices (instead of two) for
        the same EVI, then when a PE receives the second remote Ethernet A-D
        per EVI route, it generates an error message unless the two Ethernet
        A-D per EVI routes include the same ESI. Such cross-checking is not
        feasible in the default FXC mode because the normalized VIDs are not
        signaled.</t>
        <section anchor="local_switch" numbered="true" removeInRFC="false" toc="include" pn="section-3.3.1">
          <name slugifiedName="name-local-switching">Local Switching</name>
          <t indent="0" pn="section-3.3.1-1">When cross-connection occurs between two ACs belonging to two
          multi-homed ESs on the same set of multi-homing PEs,
          the forwarding between the two ACs must be performed locally during
          normal operation (e.g., in absence of a local link failure). This
          means that traffic between the two ACs <bcp14>MUST</bcp14> be
          locally switched within the PE.</t>
          <t indent="0" pn="section-3.3.1-2">In terms of control plane processing, this means that when the
          receiving PE processes an Ethernet A-D per-EVI route whose ESI is a
          local ESI, the PE does not modify its forwarding state based on the
          received route. This approach ensures that local switching takes
          precedence over forwarding via the MPLS/IP network.  This method of
          prioritizing locally switched traffic aligns with the baseline EVPN
          principles described in <xref target="RFC7432" format="default" sectionFormat="of" derivedContent="RFC7432"/>, where locally
          switched preference is specified for MAC/IP routes.</t>
          <t indent="0" pn="section-3.3.1-3">In such scenarios, the Ethernet A-D per-EVI route should be
          advertised with the MPLS label either associated with the
          destination AC or with the destination ES in order to
          avoid any ambiguity in forwarding. In other words, the MPLS label
          cannot represent the same VID-VRF outlined in <xref target="vlan_sig_fxc" format="default" sectionFormat="of" derivedContent="Section 3.3"/>, as the same normalized VID can be reachable
          via two ESs.  In the case of using an MPLS label per
          destination AC, this approach can also be applied to VLAN-based VPWS
          or VLAN bundle VPWS services as per <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>.</t>
        </section>
      </section>
      <section anchor="instantiation" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-service-instantiation">Service Instantiation</name>
        <t indent="0" pn="section-3.4-1">The V field defined in <xref target="bgp_extensions" format="default" sectionFormat="of" derivedContent="Section 4"/> is
        <bcp14>OPTIONAL</bcp14>.  However, if transmitted, its value may
        indicate an error condition that could lead to operational issues.  In
        such cases, merely notifying the operator of an error is insufficient;
        the VPWS service tunnel must not be established.</t>
        <t indent="0" pn="section-3.4-2">If both endpoints of a VPWS tunnel are signaling a matching
        normalized VID in the control plane, but one is operating in
        single-tag mode and the other in double-tag mode, then the signaling
        of the V-bit facilitates the detection and prevention of this tunnel's
        instantiation.</t>
        <t indent="0" pn="section-3.4-3">If single VID normalization is signaled in the Ethernet Tag ID
        field (12 bits), yet the data plane is operating based on double tags,
        the VID normalization applies only to the outer tag.  Conversely,
        if double VID normalization is signaled in the Ethernet Tag ID field
        (24 bits), VID normalization applies to both the inner and outer
        tags.</t>
      </section>
    </section>
    <section anchor="bgp_extensions" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-bgp-extensions">BGP Extensions</name>
      <t indent="0" pn="section-4-1">This document uses the EVPN Layer 2 Attributes Extended Community as
      defined in <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/> with two additional flags
      incorporated into this Extended Community (EC) as detailed below. This
      EC is sent with Ethernet A-D per-EVI route per <xref target="solution" format="default" sectionFormat="of" derivedContent="Section 3"/> and <bcp14>SHOULD</bcp14> be sent for both
      Single-Active and All-Active redundancy modes.</t>
      <artwork align="left" pn="section-4-2">
    +-------------------------------------------+
    | Type (0x06) / Sub-type (0x04) (2 octets)  |
    +-------------------------------------------+
    | Control Flags (2 octets)                  |
    +-------------------------------------------+
    | L2 MTU (2 octets)                         |
    +-------------------------------------------+
    | Reserved (2 octets)                       |
    +-------------------------------------------+

                         1 1 1 1 1 1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | MBZ           | V | M | |C|P|B|    (MBZ = MUST Be Zero)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      <t indent="0" pn="section-4-3">The following bits in the Control Flags are defined; the remaining
      bits <bcp14>MUST</bcp14> be set to zero when sending and
      <bcp14>MUST</bcp14> be ignored when receiving this community.</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Meaning</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">B,P,C</td>
            <td align="left" colspan="1" rowspan="1">per definition in <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/></td>
          </tr>
          <tr>
            <td rowspan="3" align="left" colspan="1">M</td>
            <td align="left" colspan="1" rowspan="1">00 mode of operation as defined in <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">01 VLAN-Signaled FXC </td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">10 Default FXC</td>
          </tr>
          <tr>
            <td rowspan="3" align="left" colspan="1">V</td>
            <td align="left" colspan="1" rowspan="1">00 operating per <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">01 single-VID normalization</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">10 double-VID normalization</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-4-5">The M and V fields are <bcp14>OPTIONAL</bcp14>. The M field is
      ignored at reception for forwarding purposes and is used for error
      notifications. </t>
    </section>
    <section anchor="failure_scenarios" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-failure-scenarios">Failure Scenarios</name>
      <t indent="0" pn="section-5-1">The two following examples analyze the failure
      scenarios.</t>
      <t indent="0" pn="section-5-2">The first scenario is a default Flexible Cross-Connect with a multi-homing
      solution, and it is depicted in <xref target="dflt_fig" format="default" sectionFormat="of" derivedContent="Figure 1"/>. In this case,
      VID normalization is performed, and a single Ethernet A-D per-EVI route
      is sent for the bundle of ACs on an ES. That is, PE1 will advertise two
      Ethernet A-D per-EVI routes: The first one will identify the ACs on port
      p1's ES, and the second one will identify the AC2 in port p2's
      ES. Similarly, PE2 will advertise two Ethernet A-D per-EVI routes.</t>
      <figure anchor="dflt_fig" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-default-flexible-cross-conne">Default Flexible Cross-Connect</name>
        <artwork align="left" pn="section-5-3.1">
                 N.VID 1,2,3 +---------------------+
                         PE1 |                     |
                     +---------+     IP/MPLS       |
   +-----+ VID1   p1 | +-----+ | sv.T1             +
   | CE1 |-------------| FXC |======+            PE3         +-----+
   |     |        /\ | |     | |    \     +----------+    +--| CE3 |
   +-----+\      +||---|     | sv.T2 \    |          |  1/   |     |
       VID3\    / ||---|     |=====+  \   | +-----+  |  /    +-----+
            \  // \/ | +-----+ |    \  +====| FXC |----+
             \ /  p2 +---------+     +======|     |  |   2   +-----+
             /\                           | |     |----------| CE4 |
            / /\    +---------+       +=====|     |  |       |     |
           / /  \p3 | +-----+ sv.T3  / +====|     |  |       +-----+
    VIDs1,2 /    +----| FXC |=======+ /   | |     |---+
   +-----+ /   /\   | |     | |      /    | +-----+  |\3    +-----+
   | CE2 |-----||---| |     | sv.T4 /     |          | \    | CE5 |
   |     |-----||---| |     |======+      +----------+  +---|     |
   +--VIDs3,4  \/   | +-----+ |                  |          +-----+
               p4   +---------+                  |
                         PE2 |                   |
                 N.VID 1,2,3 +-------------------+
</artwork>
      </figure>
      <t indent="0" pn="section-5-4">The second scenario, depicted in <xref target="vlan_sig_fig" format="default" sectionFormat="of" derivedContent="Figure 2"/>,
      illustrates the VLAN-signaled FXC mode with multi-homing. In this
      example:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-5">
        <li pn="section-5-5.1">CE1 is connected to PE1 and PE2 via (port,VID)=(p1,1) and (p3,3),
        respectively. CE1's VIDs are normalized to value 1 on both PEs, and
        CE1 is cross-connected to CE3's VID 1 at the remote end.</li>
        <li pn="section-5-5.2">
          <t indent="0" pn="section-5-5.2.1">CE2 is connected to PE1 and PE2 via ports p2 and p4, respectively:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-5.2.2">
            <li pn="section-5-5.2.2.1">The combinations (p2,1) and (p4,3) identify the ACs used to
            cross-connect CE2 to CE4's VID 2 and are normalized to value
            2.</li>
            <li pn="section-5-5.2.2.2">The combinations (p2,2) and (p4,4) identify the ACs used to
            cross-connect CE2 to CE5's VID 3 and are normalized to value
            3.</li>
          </ul>
        </li>
      </ul>
      <t indent="0" pn="section-5-6"> In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI
      route for each normalized VID (values 1, 2, and 3). However, only two
      VPWS Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1)
      between PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2)
      between PE2's FXC and PE3's FXC.</t>
      <figure anchor="vlan_sig_fig" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-vlan-signaled-fxc-2">VLAN-Signaled FXC</name>
        <artwork align="left" pn="section-5-7.1">
                 N.VID 1,2,3 +---------------------+
                         PE1 |                     |
                     +---------+     IP/MPLS       |
    +-----+ VID1  p1 | +-----+ |                   +
    | CE1 |------------| FXC | |     sv.T1       PE3          +-----+
    |     |       /\ | |     |=======+     +----------+    +--| CE3 |
    +-----+\     +||---|     | |     \     |          |  1/   |     |
        VID3\   / ||---|     | |      \    | +-----+  |  /    +-----+
             \ / /\/ | +-----+ |       +=====| FXC |----+
              \ / p2 +---------+           | |     |  |   2   +-----+
              /\                           | |     |----------| CE4 |
             / /\    +---------+      +======|     |  |       |     |
            / /  \p3 | +-----+ |     /     | |     |  |       +-----+
     VIDs1,2 /    +----| FXC |      /      | |     |---+
    +-----+ /   /\   | |     |======+      | +-----+  |\3    +-----+
    | CE2 |-----||-----|     | |     sv.T2 |          | \    | CE5 |
    |     |-----||-----|     | |           +----------+  +---|     |
    +-----+     \/   | +-----+ |                 |           +-----+
       VIDs3,4  p4   +---------+                 |
                          PE2 |                  |
                  N.VID 1,2,3 +------------------+
</artwork>
      </figure>
      <section anchor="evpws_svc_failure" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-evpn-vpws-service-failure">EVPN-VPWS Service Failure</name>
        <t indent="0" pn="section-5.1-1">The failure detection of an EVPN-VPWS service can be performed via
   OAM mechanisms such as Bidirectional Forwarding Detection (BFD)
   for the pseudowire Virtual Circuit Connectivity Verification (VCCV)
   <xref target="RFC5885" format="default" sectionFormat="of" derivedContent="RFC5885"/>, and upon such failure detection, the switch over procedure
   to the backup PE is the same as the one described above.</t>
      </section>
      <section anchor="ac_failure" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-attachment-circuit-failure">Attachment Circuit Failure</name>
        <t indent="0" pn="section-5.2-1">In the event of an AC failure, the VLAN-Signaled and default FXC
        modes exhibit distinct behaviors:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.2-2">
          <li pn="section-5.2-2.1">Default FXC (<xref target="dflt_fig" format="default" sectionFormat="of" derivedContent="Figure 1"/>): In the default mode, a
          VLAN or AC failure is not signaled.  Consequently, in case of an AC
          failure, such as VID1 on CE2, there is nothing to prevent PE3 from
          directing traffic from CE4 to PE1, leading to a potential packet
          loss at the egress PE with a failed AC. Application layer OAM may be
          utilized if per-VLAN fault propagation is necessary in this
          scenario.</li>
          <li pn="section-5.2-2.2">VLAN-Signaled FXC (<xref target="vlan_sig_fig" format="default" sectionFormat="of" derivedContent="Figure 2"/>): In the case
          of a VLAN or AC failure, such as VID1 on CE2, this triggers the withdrawal
          of the Ethernet A-D per-EVI route for the corresponding Normalized
          VID, specifically Ethernet-Tag 2. Upon receiving the route
          withdrawal, PE3 will remove PE1 from its outgoing adjacency list for
          traffic originating from CE4.</li>
        </ul>
      </section>
      <section anchor="pe_port_failure" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-pe-port-failure">PE Port Failure</name>
        <t indent="0" pn="section-5.3-1">In the event of a PE port failure, the failure will be signaled,
        and the other PE will assume forwarding in both scenarios:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3-2">
          <li pn="section-5.3-2.1">Default FXC (<xref target="dflt_fig" format="default" sectionFormat="of" derivedContent="Figure 1"/>): In the case of a port
          failure, such as p2, the route for Service Tunnel 2 (sv.T2) will be
          withdrawn. Upon receiving the fault notification, PE3 will remove
          PE1 from its adjacency list for traffic originating from CE4 and
          CE5.</li>
          <li pn="section-5.3-2.2">VLAN-Signaled FXC (<xref target="vlan_sig_fig" format="default" sectionFormat="of" derivedContent="Figure 2"/>): A port
          failure, such as p2, triggers the withdrawal of the Ethernet A-D per
          EVI routes for normalized VIDs 2 and 3, along with the withdrawal of
          the Ethernet A-D per-ES route for p2's ES. Upon receiving the fault
          notification, PE3 will remove PE1 from its adjacency list for the traffic
          originating from CE4 and CE5.</li>
        </ul>
      </section>
      <section anchor="pe_node_failure" numbered="true" removeInRFC="false" toc="include" pn="section-5.4">
        <name slugifiedName="name-pe-node-failure">PE Node Failure</name>
        <t indent="0" pn="section-5.4-1">In the case of PE node failure, the operation is similar to the steps
   described above, albeit that EVPN route withdrawals are performed by
   the route reflector instead of the PE.</t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">Since this document describes a muxing capability that leverages
      EVPN-VPWS signaling, no additional functionality beyond the muxing
      service is added, and thus no additional security considerations are
      needed beyond what is already specified in <xref target="RFC8214" format="default" sectionFormat="of" derivedContent="RFC8214"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has allocated bits 8-11 in the
      "EVPN Layer 2 Attributes Control Flags" registry with names M and V:
      </t>
      <dl spacing="compact" newline="false" indent="3" pn="section-7-2">
        <dt pn="section-7-2.1">M</dt>
        <dd pn="section-7-2.2">Signaling mode of operation (bits 10-11)</dd>
        <dt pn="section-7-2.3">V</dt>
        <dd pn="section-7-2.4">VLAN-ID normalization (bits 8-9)</dd>
      </dl>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-rtgwg-bgp-pic" to="BGP-PIC"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7432" target="https://www.rfc-editor.org/info/rfc7432" quoteTitle="true" derivedAnchor="RFC7432">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t indent="0">This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8214" target="https://www.rfc-editor.org/info/rfc8214" quoteTitle="true" derivedAnchor="RFC8214">
          <front>
            <title>Virtual Private Wire Service Support in Ethernet VPN</title>
            <author fullname="S. Boutros" initials="S." surname="Boutros"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="S. Salam" initials="S." surname="Salam"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
            <date month="August" year="2017"/>
            <abstract>
              <t indent="0">This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8214"/>
          <seriesInfo name="DOI" value="10.17487/RFC8214"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-rtgwg-bgp-pic" target="https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-21" quoteTitle="true" derivedAnchor="BGP-PIC">
          <front>
            <title>BGP Prefix Independent Convergence</title>
            <author fullname="Ahmed Bashandy" initials="A." surname="Bashandy" role="editor">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Prodosh Mohapatra" initials="P." surname="Mohapatra">
              <organization showOnFrontPage="true">Sproute Networks</organization>
            </author>
            <date day="7" month="July" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-bgp-pic-21"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC5659" target="https://www.rfc-editor.org/info/rfc5659" quoteTitle="true" derivedAnchor="RFC5659">
          <front>
            <title>An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge</title>
            <author fullname="M. Bocci" initials="M." surname="Bocci"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <date month="October" year="2009"/>
            <abstract>
              <t indent="0">This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5659"/>
          <seriesInfo name="DOI" value="10.17487/RFC5659"/>
        </reference>
        <reference anchor="RFC5885" target="https://www.rfc-editor.org/info/rfc5885" quoteTitle="true" derivedAnchor="RFC5885">
          <front>
            <title>Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)</title>
            <author fullname="T. Nadeau" initials="T." role="editor" surname="Nadeau"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5885"/>
          <seriesInfo name="DOI" value="10.17487/RFC5885"/>
        </reference>
        <reference anchor="RFC8365" target="https://www.rfc-editor.org/info/rfc8365" quoteTitle="true" derivedAnchor="RFC8365">
          <front>
            <title>A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="J. Drake" initials="J." role="editor" surname="Drake"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="R. Shekhar" initials="R." surname="Shekhar"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8365"/>
          <seriesInfo name="DOI" value="10.17487/RFC8365"/>
        </reference>
      </references>
    </references>
    <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.a-1">In addition to the authors listed on the front page, the following
      coauthors have also contributed substantially to this document:</t>
      <contact fullname="Wen Lin">
        <organization showOnFrontPage="true">Juniper Networks</organization>
        <address>
          <email>wlin@juniper.net</email>
        </address>
      </contact>
      <contact fullname="Luc Andre Burdet">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>lburdet@cisco.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Ali Sajassi" initials="A." surname="Sajassi" role="editor">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <email>sajassi@cisco.com</email>
        </address>
      </author>
      <author fullname="Patrice Brissette" initials="P." surname="Brissette">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <email>pbrisset@cisco.com</email>
        </address>
      </author>
      <author fullname="James Uttaro" initials="J." surname="Uttaro">
        <organization showOnFrontPage="true">Individual</organization>
        <address>
          <email>juttaro@ieee.org</email>
        </address>
      </author>
      <author fullname="John Drake" initials="J." surname="Drake">
        <organization showOnFrontPage="true">Independent</organization>
        <address>
          <email>je_drake@yahoo.com</email>
        </address>
      </author>
      <author fullname="Sami Boutros" initials="S." surname="Boutros">
        <organization showOnFrontPage="true">Ciena</organization>
        <address>
          <email>sboutros@ciena.com</email>
        </address>
      </author>
      <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
        <organization showOnFrontPage="true">Nokia</organization>
        <address>
          <email>jorge.rabadan@nokia.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
