<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [

]>

<rfc  category="std"
      docName="draft-chen-bess-evpn-wtr-on-fast-df-recovery-00"
      ipr="trust200902"
	  tocDepth="4"
      symRefs="true"
      sortRefs="true"
	  version="3">

	<!-- Generated by id2xml 1.5.0 on 2019-10-25T06:40:21Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="*o+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
	
	<front>
	<title abbrev="WTR on Fast DF Recovery"> WTR signaling on Fast DF Recovery of Single-Active ESIs </title>

    
 	<author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No. 50 Software Ave, Yuhuatai Distinct</street>   
          <city>Nanjing</city>
          <region></region>
          <code></code>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
      </address>
    </author>
   
	<author fullname="Yubao Wang" initials="Y." surname="Wang">
	<organization>ZTE Corporation</organization>
	<address><postal><street>No. 68 of Zijinghua Road, Yuhuatai Distinct</street>
	<street>Nanjing</street>
	<street>China</street>
	</postal>
	<email>wang.yubao2@zte.com.cn</email>
	</address>
	</author>

	<date year="2023"/>
	<workgroup>BESS WG</workgroup>
	<abstract><t>The non-DF of a Single-Active Ethernet Segment (SA-ES) can filter both unicast traffic and BUM traffic.
   In such case, when a specific Single-Active ES performs fast DF recovery, the corresponding revertive FRR switching should be performed on the ingress PEs that are not adjacent to this ES.
   This revertive FRR switching needs to be performed immediately after the A-D per EVI route with the "P=1" is received from the new DF node.
   In other words, the revertive FRR switching cannot perform the WTR procedures, otherwise unicast traffic will be dropped on the new NDF node during the WTR.
   </t>	
   
   <t>In this draft, the SCT-EC is extended to the A-D per EVI routes, so that the ingress PEs can perform the revertive FRR switching based on the time specified by the SCT-EC for the non-adjacent ESes that support the fast DF recovery.
   </t>	 

	</abstract>
	</front>

	<middle>
	<section title="Introduction" anchor="sect-Introduce">
	
  
   <t>The non-DF of a Single-Active Ethernet Segment (SA-ES) can filter both unicast traffic and BUM traffic.
   In such case, when a specific Single-Active ES performs fast DF recovery, the corresponding revertive FRR switching should be performed on the ingress PEs that are not adjacent to this ES.
   This revertive FRR switching needs to be performed immediately after the A-D per EVI route with the "P=1" is received from the new DF node.
   In other words, the revertive FRR switching cannot perform the WTR procedures, otherwise unicast traffic will be dropped on the old DF (new NDF) node during the WTR.
   </t>
   <t>
       However, on the other hand, lack of the WTR procedures also causes the unicast flows to be discarded on the newly activated path of the FRR until all corresponding forwarding entries on the newly activated path are completely installed. As a PE node that is not adjacent to a specified group of ESes, the ingress PE cannot know which ESes in that group are enabled with SCT-based fast DF recovery. If the ingress PEs stop executing the WTR procedures of the FRR of all non-adjacent ESes due to this reason, the traffic loss will be even worse.That is, the ESes that do not enable the SCT-based fast DF recovery at all will bear traffic loss due to the lack of WTR procedures.
   </t>
   <t>In this draft, the DF Election Capabilities EC is extended to the A-D per ES routes, so that the ingress PEs can distinguish the non-adjacent ESes that support the fast DF recovery from the non-adjacent ESes that do not support the fast DF recovery. In this draft, the SCT-EC is extended to the A-D per EVI routes, so that the ingress PEs can perform the revertive FRR switching based on the time specified by the SCT-EC for the non-adjacent ESes that support the fast DF recovery.
   </t>	

   <section title="NDF-behavior of SA-ES" anchor="sect-MHN-NDF">
   
	<t>
    The behavior of a non-DF AC is called NDF-behavior in this draft.
	The NDF-behavior of a SA-ES is different from the NDF-behavior of a All-Active ES.
	</t>
	   
    <t>The SA-ES topology is illustrated in the following figure.
    In that figure, the topology of Ethernet Segment ES21 is a MHN.
	</t>
	   
   <figure title="MHN (CE1+CE2) multihomed to PE1 and PE2" anchor="Figure-SA-ES-Topology"><artwork><![CDATA[
                            +---------+
         +-------------+    |         |
         |             |    |         |
CE1------+ (AC1)  PE1  |----|         |   +-------------+
 +    ^  |             |    |  MPLS/  |   |             |---CE3
 |    |  +-------------+    |  VxLAN/ |   |     PE3     |
 |   ES21                   |  Cloud  |   |             |
 |    |  +-------------+    |         |---|             |
 +    v  |             |    |         |   +-------------+
CE2------+ (AC2)  PE2  |----|         |
         |             |    |         |
         +-------------+    |         |
                            +---------+
]]></artwork>
   </figure>
   
   <t>
       The DF filtering rules for SA-ES is different than the rules for AA-ES.
       The details are described in the following:
   </t>
   

<dl newline="false" spacing="normal" indent = "2">

   <dt>Directionality—</dt><dd>
   <t>
	DF filtering for MHN is applied for traffic both ingress and egress on the access-facing Ethernet interfaces; whereas, DF filtering for AA-ES is applied only to traffic that egress the access-facing interfaces.
	</t></dd>

   <dt>Traffic Type—</dt><dd>
   <t>
    DF filtering for MHN impacts both unicast as well as flooded multi-destination traffic; whereas, DF filtering for AA-ES only applies to flooded multi-destination traffic..
	</t>
   </dd>


</dl>   
   
    
   </section>	   

	<section title="Terminology" anchor="sect-1.3"><t>
   Most of the terminology used in this documents comes from <xref target="I-D.ietf-bess-rfc7432bis"/>
   and <xref target="I-D.ietf-bess-evpn-fast-df-recovery"/> except for the following:</t>

<dl newline="false" spacing="normal" indent = "2">

   <dt>* MHN:  </dt><dd>
   Multi-Homed Network. The "multi-homed network" concept is defined in <xref target="RFC7275"/>.</dd>

  
   	<dt>* SA-ES:  </dt><dd>
   A Single-Active Ethernet Segment (ES). 
   </dd>

   	<dt>* AA-ES:  </dt><dd>
   An All-Active Ethernet Segment (ES). 
   </dd>

   
   <dt>* NDF:  </dt><dd>
   non-DF.
   </dd>

   <dt>* SCT:  </dt><dd>
   Service Carving Timestamp.
   </dd>

   <dt>* SCT-EC:  </dt><dd>
   Service Carving Timestamp Extended Community.
   </dd>
   
   <dt>* SCT-Time:  </dt><dd>
   The absolute time indicated by the timestamp in a SCT-EC.
   </dd>   

   <dt>* P flag:  </dt><dd>
   The P flag in L2 Attr Extended Community of <xref target="RFC8214"/>.
   </dd>

   <dt>* B flag:  </dt><dd>
   The B flag in L2 Attr Extended Community of <xref target="RFC8214"/>.
   </dd>

   <dt>* T bit:  </dt><dd>
   The T bit in DF Election Capabilities Extended Community.
   </dd>

   <dt>* RT-1:  </dt><dd>
   The Ethernet Auto-Discovery Route.
   </dd>
 
   <dt>* RT-4:  </dt><dd>
   The Ethernet Segment Route.
   </dd>

   <dt>* RT-1 per ES:  </dt><dd>
   The Ethernet Auto-Discovery per ES Route, or A-D per ES route.
   </dd>

   <dt>* RT-1 per EVI:  </dt><dd>
   The Ethernet Auto-Discovery per EVI Route, or A-D per EVI route.
   </dd>
   
   
</dl>
   
	</section>

	</section>	

	<section title="Requirements" anchor="sect-Requirements">

	<t> When a A-D per EVI route R1 is advertised to PE3 by PE1/PE2, PE3 will receive it after X ms.
    Now we can assume that X will be a random number from 1 ms to N ms in the network of <xref target="Figure-SA-ES-Topology"/>. 
    In this example, we can assume that N will be as much as 60000 (ms) and the Ethernet Segment ES21 is a SA-ES.
	</t>
    
    <t>In this example, the requirement is that, the packet-loss should be controlled at a less-than-10-ms level.
    </t>
		
	</section>	
		
	<section title="Solution" anchor="sect-TS-per-EVI">


	<section title="SCT-Approach for A-D per EVI Routes" anchor="sect-WTR-SIGNAL">
    
        <t>Based on the Service Carving Time (SCT) approach for Ethernet A-D per EVI Routes:
        </t>
        
<ol>
   <li><t>   Initial state: The ES interface where AC2 is located is in steady state, and the ES interface where AC1 is located is is recovering. PE3 sends unicast flows to PE2 where AC2 is located.
   </t></li>
   <li><t>   The ES interface where the AC1 is located recovers at absolute time t=99.
   </t></li>
   <li><t>   PE1 advertises the RT-4 route (sent at the time t=100) for the ES interface where AC1 is located, carrying the target SCT value t=199.
             PE1 advertises the A-D per EVI route (sent at the time t=100) for AC1, carrying the target SCT value t=199 and "B=1" to the peer PE3 and PE2.    
   </t></li>
   <li><t>   PE3 receives the A-D per EVI route on absolute time t=155.
   </t></li>
   <li><t>   PE3 executes FRR-revertion at absolute time t=199, while PE1 and PE2 execute service carving at absolute time t=199.
   </t></li>
</ol>
   
       <t>   Using SCT approach, the negative effect of the lack of WTR procedures is
   mitigated.  Furthermore, the BGP Ethernet Auto-discovery route (RT-1)
   transmission delay (from PE1 to PE3) becomes a non-issue.  The use of
   SCT approach also remedies the problem associated with inconsistent pace between fast DF recovery (on PE1 and PE2) and FRR-revertion (on PE3):
   Revertive FRR switching on PE3 is now performed at the same absolute time as fast DF recovery on PE1 and PE2.
       </t>
</section>        
        
	<section title="Control Plane Procedures" anchor="sect-CP-for-PE3">

	<section title="Service Carving Timestamp in A-D per EVI Routes" anchor="sect-SCT-per-EVI">
	<t>
    In case of fast DF recovery of a SA-ES, the Service Carving Timestamp Extended Community of <xref target="I-D.ietf-bess-evpn-fast-df-recovery"/> may be carried along with a A-D per EVI route.
	</t>

   <figure title="Service Carving Timestamp Extended Community" anchor="Figure-SCT-EC"><artwork><![CDATA[
                        1                   2                   3
    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(0x0F)|      Timestamp Seconds        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~  Timestamp Seconds            | Timestamp Fractional Seconds  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
   </figure>


	</section>


	<section title="SCT-based WTR Capability Advertisement" anchor="sect-RT1-on-DF-Revert">

	<t>
    The Time Synchronization bit (T bit) of <xref target="I-D.ietf-bess-evpn-fast-df-recovery"/> may also be carried along with the A-D per ES route before that SCT-EC is advertised .
	That T bit is carried in the DF Election Capabilities Extended Community per <xref target="RFC8584"/>.
   </t>

   
   <figure title="Time Synchronization (T bit)" anchor="Figure-T-Flag"><artwork><![CDATA[
                        1                   2                   3
    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(0x06)| RSV |  DF Alg | |A| |T|       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~     Bitmap    |            Reserved = 0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
   </figure>
   
   <t>In the case where one or more PEs
   attached to the Ethernet Segment do not signal T=1 in RT-4, all PEs in the
   Ethernet Segment SHALL revert back to the RT-1 per ES routes without the DF Election Capabilities Extended Community.
   </t>

   <t>In the case where one of the non-adjacent PEs
   of the ES has signaled T=1 in its RT-1 per EVI, all PEs in that
   ES MAY advertise SCT-EC in their RT-1 per EVI routes. Although other PEs which are non-adjacent to that ES can't recognize the T bit in RT-1 per EVI route,
   their traffic loss will not be worse than current.
   </t>

   
	</section>
	 

	<section title="WTR Advertisement on PE1/PE2" anchor="sect-Proc-WTR-Advertise">
    <t>
    When AC1 recovers and PE1 decides to takeover the DF-role, and PE2 decides to takeover the NDF-role,
    PE1 will update its A-D per EVI Advertisement, and carry the SCT-EC and "B=1" along with that A-D per EVI route.
    PE2 will not update its previous A-D per EVI route (which carry the "P=1") until the time indicated by the SCT-EC.
	</t>
    

	</section>
    
    
    
	<section title="SCT-based WTR Procedures on PE3" anchor="sect-Proc-RT1-with-SCT">

        
    <t>When the SCT-EC of a A-D per EVI route still indicate a time in the future, the SCT-EC will not be used to select the best path for the corresponding ESI and ET-ID until the time indicated by the SCT-EC.
    </t>
        
        <t>
        After the time indicated by the SCT-EC, PE3 will select the A-D per EVI route with that SCT-EC as the best path for the corresponding ESI and Ethernet Tag ID,
        no matter wthether the "B=1" or "P=1" is signaled along with that A-D per EVI.
	</t>
    
    <t>In the example of <xref target="Figure-SA-ES-Topology"/>: </t>
        
        
<ul>
   <li><t>   When PE3 has two A-D per EVI routes for the same ESI and ET-ID, one of which carries the "P=1" and the other carries a SCT-EC whose timestamp indicates a time in the future, the route with the SCT-EC will not be selected as the best route until the time indicated by the SCT-EC. After the time indicated by the SCT-EC, the route with the SCT-EC will be selected as the best route.
   </t></li>
   <li><t>   When PE3 has two A-D per EVI routes for the same ESI and ET-ID, both of which carry the "B=1" along with themselves but one of which carries a SCT-EC whose timestamp indicates a time in the future, the route with the SCT-EC will not be selected as the best route until the time indicated by the SCT-EC.
   </t></li>
   <li><t>       
   </t></li>
</ul>
            

	</section>
    
    
	<section title="A-D per EVI Route Advertisement after SCT-Time" anchor="sect-RT1-after-SCT">
	<t>
    Y ms after AC1 actually works as DF-role, PE1 should update the A-D per EVI route for AC1.
    In the updated A-D per EVI route, no SCT-EC should be included, and the P flag should be set.
    
	</t>

	</section>
    
	</section>

    
		</section>

	<section title="Backwards Compatibility" anchor="sect-Compatibility">
        
        <t>It is possible that some non-adjacent PEs of a given ES continue 
            to use the existing RT-1 per EVI route procedures 
            and do not rely on the new SCT BGP extended community.  PEs
   running a baseline RT-1 per EVI route procedures will simply discard the 
   SCT BGP extended community as unrecognized.
        </t>

        <t>A PE on a given ES can indicate its willingness to support clock-synched WTR by
   signaling the SCT-EC along with the RT-1 per EVI route. A PE which is not adjacent to that ES may discard the 
   SCT BGP extended community as unrecognized, thus when the SCT-time comes that PE will do nothing because its "B=1" will not be updated before SCT-time. 
   But a little bit later than the SCT-time, that PE will receive a RT-1 per EVI route with "P=1",
   and that RT-1 per EVI route will trigger the revertive FRR switching immediately. At least, this will not be worse than when the SCT-EC is not advertised.
        </t>
        
        
	</section>        
	
	<section title="Security Considerations" anchor="sect-9"><t>
    TBD.</t>

	</section>

	<section title="IANA Considerations" anchor="sect-10"><t>
    There is no IANA consideration needed.</t>

	</section>

	</middle>

	<back>
	<references title="Normative References">

    <?rfc include="reference.RFC.8214.xml"?>
    <?rfc include="reference.RFC.8584.xml"?>
    <?rfc include="reference.I-D.ietf-bess-rfc7432bis.xml"?>
    <?rfc include="reference.I-D.ietf-bess-evpn-fast-df-recovery.xml"?>
	
	</references>

	<references title="Informative References">

    <?rfc include="reference.RFC.7275.xml"?>
	
	</references>

	
	</back>

	</rfc>
	
