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

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

]>

<rfc  category="std"
      docName="draft-wang-bess-center-rt5-for-common-prefix-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="Centerlized ECMP RT-5">Centerlized EVPN Prefix Advertisement for Common Prefixes behind Different CEs</title>

	<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="2022"/>
	<workgroup>BESS WG</workgroup>
	<abstract><t>
   
   In <relref section="5.8" target="I-D.wang-bess-evpn-arp-nd-synch-without-irb"/>, 
   centerlized RT-5 advertisement are used for common prefixes behind different CEs, 
   This draft describes the requirements for such scenarios. 
   Then this draft reuse the procedures defined in <relref section="6.2.2" target="I-D.wz-bess-evpn-vpws-as-vrf-ac"/> to support this scenario.
   </t>	

	</abstract>
	</front>

	<middle>
	<section title="Introduction" anchor="sect-1">
	<t>
   In <xref target="Figure-Scenario-RT5G-Common"/>,
   Both R1 and R2 advertise their prefixes to DGW1 according to <relref section="5" target="I-D.wang-bess-evpn-arp-nd-synch-without-irb"/>.		
   Subnet SN1 can only be reached through R1, so we say SN1 is R1's exlusive prefix.
   Then subnet SN2 is R2's exlusive prefix, because SN2 can only be reached throug R2.
   But subnet SN21 can be reached either through R1, or through R2, 
   thus we say SN21	is a common prefix of R1 and R2.

   </t>
   <t>When there are both exlusive prefixes and common prefixes behind some CEs,
	  some special requirements should be considered, 
	   especially when some of these CEs will not aware which prefixes are the common prefixes.
	  This draft describes the requirements and solutions related to these scenarios .
   </t>

   <section title="ECMP for Centerlized RT-5 Advertisement" anchor="sect-IRC">
   
	<t>
	R1 and R2 both establish a single CE-BGP session with DGW1.
    These CE-BGP session can be called the centerlized CE-BGP session.
	</t>
	   
    <t>SN21 is a common prefix of R1 and R2, 
	when R4 send traffic to a host inside subnet SN21, 
	DGW1' should load-balance that traffic between PE1, PE2 and PE3.
	</t>
	   
   <figure title="Centerlized RT-5 for common CE-Prefixes" anchor="Figure-Scenario-RT5G-Common"><artwork><![CDATA[
         +--------------------->----------------------+                    
         |                   CE-BGP                   |                    
         |              PE3                           |                    
         |             +----------+                   |                    
         |             | +------+ | ------>           | CE-BGP                     
      R2 |             | |      | | RT-2R             | SN21,SN2                    
     +-------+         | | VPNx | | 20.2(MAC34)       | NH=20.2                    
     |       |  P3.1   | |      | | MAC34             |                    
     | ...................(20.9)| |                   |                    
     | .     |         | +------+ |                   |  DGW1'             
SN2--| .     |         +----------+               +---|---------+          
     | .     |            ^           <---------- |   V         |          
     | .     |            | RT-2       RT-5       | +---------+ |          
     |(20.2) |            | 20.2       SN21       | |  VPNx   | |          
     | .     |            | ESI34      GW-IP=20.2 | |         |....R4      
 +---| .     |            |                       | |(z.z.z.z)| |          
 |   | .     |         +----------+ ------>       | |         | |          
 |   | .     |         | +------+ | RT-2R         | +---------+ |          
 |   | ...................(20.9)| | 20.2          |             |          
 |   |       |  P4.1   | |      | | MAC34         +-------------+          
 |   +-------+         | |      | |                              
SN21               PE1 | | VPNx | | ------>                                
 |    R1               | |      | | RT-2R                                  
 |   +-------+         | |      | | 10.2                                   
 |   |       |  P1.1   | |      | | MAC21                                  
 |   | ...................(10.9)| |                      DGW1                  
 |   | .     |         | +------+ |               +-------------+          
 |   | .     |         +----------+               |             |          
 +---| .     |            ^           <---------- | +---------+ |          
     | .     |            | RT-2       RT-5       | |         | |          
     |(10.2) |            | 10.2       SN21       | |  VPNx   | |          
     | .     |            | ESI21      GW-IP=10.2 | |         |....R3      
     | .     |            |                       | |(z.z.z.z)| |          
SN1--| .     |         +----------+ ------>       | +---------+ |          
     | .     |         | +------+ | RT-2R         |   ^         |          
     | ...................(10.9)| | 10.2          |   |         |          
     |       |  P2.1   | |      | | MAC21         +---|---------+          
     +-------+         | | VPNx | |                   |                    
         |             | |      | |                   | CE-BGP             
         |             | +------+ |                   | SN21,SN1            
         |             +----------+                   | NH=10.2            
         |              PE2                           |                    
         |                   CE-BGP                   |                    
         +--------------------->----------------------+                                                                                   
]]></artwork>
   </figure>
	   
	<t>
	Note that we just use centerlized CE-BGP session to discover CE-prefixes, 
	but we still expect a distributed Layer 3 forwarding framework.
	</t>
   
   </section>	   

	<section title="Terminology" anchor="sect-1.3"><t>
   Most of the terminology used in this documents comes from <xref target="RFC7432"/>
   and <xref target="RFC9136"/> except for the following:</t>

<dl newline="false" spacing="normal" indent = "2">
	<dt>* L3 EVI:  </dt><dd>
   An EVPN instance spanning the Provider Edge (PE) devices
   participating in that EVPN which contains VRF ACs and maybe
   contains IRB interfaces or IRC interfaces.</dd>

   <dt>* CE-BGP:  </dt><dd>
   The BGP session between PE and CE. Note that CE-BGP route doesn't have a RD or Route-Target.
   </dd>
   
   	<dt>* RMAC:  </dt><dd>
   Router's MAC, which is signaled in the Router's MAC extended community. </dd>
   
   <dt>* RT-2R:  </dt><dd>
   When a MAC/IP Advertisement Route is used in the context of an IP-VRF, it is called as a RT-2R in this draft.
   </dd>

   <dt>* RT-5E:  </dt><dd>
   An EVPN Prefix Advertisement Route with a non-reserved ESI.
   </dd>

   <dt>* RT-5G:  </dt><dd>
   An EVPN Prefix Advertisement Route with a zero ESI and a non-zero GW-IP.
   </dd>
   
   <dt>* RT-5L:  </dt><dd>
   An EVPN Prefix Advertisement Route with both zero ESI and zero GW-IP, but a valid MPLS label.
   </dd>

   <dt>* Internal Remote PE:  </dt><dd>
   When PEx is called as an EVPN route ERy's internal remote PE,
   that is saying that, PEx is on the ES which is identified by ERy's ESI field.
   When ERy's SOI is not zero, that is aslo saying that PEx has been attached to 
   the ethernet tag which is identified by the &lt;ESI, SOI&gt;.
   </dd>

   <dt>* External Remote PE:  </dt><dd>
   When PEx is called as an EVPN route ERy's external remote PE,
   that is saying that, PEx is not on the ES which is identified by ERy's ESI field.
   When ERy's SOI is not zero, PEx may aslo be a PE which has not been attached to 
   the ethernet tag which is identified by the &lt;ESI, SOI&gt;.
   </dd>

   <dt>* CE-Prefix:  </dt><dd>
   When an IP prefix can be reached through CEx from PEy, 
   that IP prefix is called as PEy's CE-prefix behind CEx in this draft.
   PEy's CE-prefix behind CEx is also called as PEy's CE-prefix for short in this draft.
   </dd>

   <dt>* Common CE-Prefix:  </dt><dd>
   When an CE-Prefix can be reached through either CEy or CEz from PEy,
   in this draft, it is called as a common CE-Prefix of CEy and CEz,from the viewpoint of PEy.
   </dd>

   <dt>* Exclusive CE-Prefix:  </dt><dd>
   When an CE-Prefix of PEy can be reached through CEy, 
   and it can't be reached through other CEs of PEy,
   it is called as an exlusive CE-Prefix of CEy, from the viewpoint of PEy.
   </dd>

   <dt>* SNGW:  </dt><dd>
   Sub-Net-specific Gate Way IP address, 
   the SNGW of a subnet is an IP address which is used 
   by the hosts of that subnet to be the nexthop 
   of the default route of these host.
   </dd>

   <dt>* Overlay nexthop :  </dt><dd>
   The CE-Prefix's nexthop IP address which is in the address-space of the L3 EVI.
   </dd>

   <dt>* Original Overlay nexthop :  </dt><dd>
   The overlay nexthop which is advertised by the CE through a PE-CE route protocol.
   </dd>

</dl>
   
	</section>

	</section>	

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

	<t> Before advertise SN1/SN2/SN21 to DGWs, R1 and R2 don't have to know which prefix is their common prefix, and which
   prefix is their exclusive prefix. 
	</t>
		
	</section>	
		
	<section title="Solution" anchor="sect-ARP-Synching">


	<section title="Basic Control Plane Procedures" anchor="sect-C-RT5G-Basic-CP">


	<section title="Centerlized CE-BGP" anchor="sect-6.2.1">
	<t>
    The CE-BGP session between R1 and DGW1 is established between 10.2 and z.z.z.z.
    The IP address 10.2 is called the uplink interface address of R1 in this document.
    The IP address z.z.z.z is called the centerlized loopback address of VPNx in this document.	
	The IP address 10.9 is called the downlink VRF-interface address of PE1/PE2 in this document.
	</t>
	
	<t>
	R1 advertises a BGP route for a prefix (say "SN21") behind it to DGW1 via that CE-BGP session.
	The nexthop for SN21 is R1's uplink interface address (say 10.2).
	</t>

			
	<t>
	R2 advertises a BGP route for a prefix (say "SN21") behind it to DGW1' via that CE-BGP session.
	The nexthop for SN21 is R2's uplink interface address (say 20.2).
	</t>
		
    <t>
	Note that the data packets from R1(R2) to the centerlized loopback address may be routed following the default route on R1(R2).
	Thus DGW1 doesn't need to use the CE-BGP session to advertise prefixes of VPNx to R1(R2).
	</t>
	
	</section>

	<section title="RT-2E Advertisement from PE1/PE2 to DGW1" anchor="sect-6.2.2">
	<t>
    When PE1 and PE2 learns the ARP entry of 10.2, it advertises a RT-2R route to DGW1 (and DGW1').
	</t>

	<t>
    When PE1 and PE3 learns the ARP entry of 20.2, it advertises a RT-2R route to DGW1 (and DGW1').
	</t>
		
		
	</section>

	
	<section title="RT-5G Advertisement from DGW1 to PE1/PE2/PE3/DGW1'" anchor="sect-RT5G-on-DGW">
	<t>
    When DGW1 receives the SN21 from the CE-BGP session. 
	The nexthop for SN21 is 10.2.
	So DGW1 advertises a RT-5G route to PE1/PE2/PE3 for SN21.
	The GW-IP value of the RT-5G route for SN21 is 10.2.
	</t>

	<t>
    When DGW1' receives the SN21 from the CE-BGP session. 
	The nexthop for SN21 is 20.2.
	So DGW1 advertises a RT-5G route to PE1/PE2/PE3 for SN21.
	The GW-IP value of the RT-5G route for SN21 is 20.2.
	</t>
		
	<t>DGW1 and DGW1' may be the same device, in such case DGW1 should use the ADD-PATH of <xref target="RFC7911"/> to advertise two GW-IPs for the same prefixe SN21.
	</t>
		
    <t>Note that when other PEs receive these RT-5 route for SN21, the ECMP behavior is already defined in <relref section="4.1" target="RFC9136"/> as the following:
	</t>	
	
		
   <figure title="ECMP for GW-IP based RT-5" anchor="Figure-ECMP-RT5G"><artwork><![CDATA[
        *  Based on the BD-10 Route Target in DGW1 and DGW2, the IP
           Prefix route is also imported, and SN1/24 is added to the IP-
           VRF with Overlay Index IP2 pointing at the local BD-10.  In
           this example, it is assumed that the RT-5 from NVE2 is
           preferred over the RT-5 from NVE3.  If both routes were
           equally preferable and ECMP enabled, SN1/24 would also be
           added to the routing table with Overlay Index IP3.                                                                           
]]></artwork>
   </figure>		
			
	
	</section>
	

	<section title="RT-2E Advertisement between PE1 and PE2" anchor="sect-6.2.4">

	<t>
	The RT-2R routes advertisement between PE1 and PE2 is used to sync subnet 10.0's ARP entries to each other in order to avoid ARP missing.
	The ESI Value of these two RT-2R routes is ESI21.
	</t>

	<t>
	The RT-2R routes advertisement between PE1 and PE3 is used to sync subnet 20.0's ARP entries to each other in order to avoid ARP missing.
	The ESI Value of these two RT-2R routes is ESI34.
	</t>
		
		
	</section>

	</section>

		</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.9136.xml"?>
    <?rfc include="reference.RFC.9135.xml"?>
    <?rfc include="reference.RFC.7432.xml"?>
    <?rfc include="reference.RFC.8214.xml"?>
    <?rfc include="reference.RFC.8365.xml"?>
    <?rfc include="reference.RFC.7911.xml"?>
	<?rfc include="reference.I-D.wang-bess-evpn-arp-nd-synch-without-irb.xml"?>
    <?rfc include="reference.I-D.wz-bess-evpn-vpws-as-vrf-ac.xml"?>

	
	</references>

	<references title="Informative References">

    <?rfc include="reference.I-D.sajassi-bess-evpn-ip-aliasing.xml"?>
	
	</references>

	
	</back>

	</rfc>
	
