<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wang-bess-evpn-frr-label-01"
     ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">EVPN ELAN FRR Loop Prevent label</title>

    <author fullname="Haibo Wang" initials="H" surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <code>100095</code>

          <region/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>

    <author fullname="Donald E. Eastlake" initials="D" surname="Eastlake">
      <organization>Futurewei Technologies</organization>

      <address>
        <postal>
          <street>2386 Panoramic Circle</street>

          <city>Apopka</city>

          <region/>

          <code>FL 32703</code>

          <country>USA</country>
        </postal>

        <phone>+1-508-333-2270</phone>

        <facsimile/>

        <email>d3e3e3@gmail.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Tong Zhu" initials="T" surname="Zhu">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>101 software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region/>

          <code>210012</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhu.tong@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="12" month="July" year="2021"/>

    <area>Routing Area</area>

    <workgroup>BESS Working Group</workgroup>

    <keyword>FRR</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>This document describes how to use Fast Re-Route (FRR) labels avoid
      traffic loop in CE failures when deploying FRR protection in EVPN
      scenarios.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>In the EVPN active-active scenario, to solve the failure of a CE
      access channel to one PE, we can deploy Fast Re-Route (FRR) protection
      mode to achieve fast convergence. All active PEs can be deployed with
      FRR. When a link failure occurs on the CE connection to the PE, traffic
      can be rapidly FRR to another PE to improve the switching performance.
      However, if the CE device fails, both the two PEs sense that their CE
      link is faulty at the same time. They will each perform fast switching
      according to the FRR. Then the traffic will loop between the dual PEs.
      </t>

      <t>If one PE detects a failure and withdraw the ES-AD route, the other
      PE, after receiving the withdrawal of the ES-AD route, deletes the FRR
      path to the PE, and the loop is eliminated. The time until the loop is
      eliminated may be short, but during this time, the loop will cause
      traffic congestion between the dual-homing PEs. </t>

      <figure>
        <artwork align="center"><![CDATA[          +-----+
          | CE2 |
          +-----+
             |
          +-----+
          | EVI1|
          | PE3 |
          +-----+
          /      \
         /        \
        /          \
       /            \
      /              \
 +-----+             +-----+
 | PE1 |             | PE2 |
 | EVI1|-------------| EVI1|
 +-----+             +-----+
       \             /
        \           /
        ESI1      ESI1
          \ Trunk /
          +\-----/+
          | \   / |
          +---+---+
              |
           +-----+
           | CE1 |
           +-----+
Figure 1: Basic networking of the EVPN all-active scenario
]]></artwork>
      </figure>
    </section>

    <section anchor="IANA" title="FRR Label Extended Community">
      <t> The FRR Label Extended Community is a new transitive Extended
      Community having a Type field value of 0x06 and the Sub-Type TBD. It may
      be advertised along with MAC/IP Advertisement routes and Ethernet A-D
      per EVI routes.</t>

      <t> The FRR Label Extended Community is encoded as an 8-octet value, as
      follows:</t>

      <t><figure>
          <artwork><![CDATA[        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type=0x06     | Sub-Type=TBD  | Flags(1 octet)|  Reserved=0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Reserved=0   |          FRR Label                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>
    </section>

    <section anchor="Security" title="The Control Plane Process">
      <t> If we enable the FRR LABEL function for an instance, then when the
      PE advertises the MAC-IP route or Ethernet A-D per EVI route of the
      instance, it also carries an FRR Label Extended Community attribute.</t>

      <t> When another PE on the dual-homed side receives the MAC-IP route or
      the EVI-AD route, and uses the Label in the FRR Label Extended Community
      attribute as the label for the Edge FRR path. The single- homing-side PE
      receives the MAC-IP route or Ethernet A-D per EVI route advertised by
      the PE will ignores the FRR Label Extended Community attribute.</t>

      <t> Because the FRR Label Extended Community attribute is an optional
      transitve attribute, if there are RR devices or ASBR devices in the
      network, the attributes can be transparently transmitted and processed
      by the final PE device.</t>

      <t> Taking Figure 1 as an example, the EVI1 of PE2 enables the FRR LABEL
      function, and PE2 applies for a new label. PE2 advertises the MAC-IP
      route and the Ethernet A-D per EVI route carries the label through the
      FRR Label Extended Community attribute. Because CE1 is dual- homed to
      PE1 and PE2, PE1 learns the MAC address of CE1 from the data plane.
      Therefore, when PE1 receives the MAC-IP route or Ethernet A-D per EVI
      route from PE2, it can generate the MAC address learned from CE1 to form
      an edge FRR entry and the label filled in the FRR entry is the FRR
      label.</t>

      <t> For PE3, even if CE1 is dual-homed to PE1 and PE2 in single-active
      mode, PE3 form FRR does not use the FRR label.</t>

      <t> The feature is available for EVPN ELAN service , EVPN VPWS and EVPN
      L3VPN service.</t>
    </section>

    <section title="The Data Plane Process">
      <t> The PE receives the traffic from the network side and finds the
      corresponding bridge-domain according to the Label. If the Label is a
      normal EVI label, the MAC address is normally queried. If the local
      outbound interface of the MAC fails, the FRR of the MAC is further
      protected. If the Label is an FRR label, the MAC address continues to be
      queried normally. If the local outbound interface of the MAC fails, the
      FRR of the MAC is no longer protected.</t>

      <t>Taking Figure 1 as an example. CE2 send traffic to CE1, traffic
      arrived PE3 will encapsulate PE2 's EVI label and send to PE1. Traffic
      arrived at PE1 and use the EVI label to lookup MAC table, but find the
      out-interface is failed. PE1 will do MAC FRR for that and encapsulate
      the FRR label, which is advertised by PE2. Traffic arrived at PE2 and
      use the FRR label to lookup MAC table. The traffic will send to CE1
      according to the MAC infomation. When the MAC's out-interface is failed,
      the traffic will dropped to avoid traffic loop.</t>
    </section>

    <section title="Other considerations">
      <t> The solution of this document is not only applicable to the EVPN
      scenario. The traditional L3VPN can also use this solution to achieve
      rapid loop breaking.</t>
    </section>

    <section title="IANA Considerations">
      <t> IANA is requested to assign a new type of FRR label extended
      community with value TBD.</t>
    </section>

    <section title=" Security Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>
  </back>
</rfc>
