<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2545.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4659 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY RFC4684 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4684.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC4798 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4798.xml">
<!ENTITY RFC4925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4925.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC5492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5492.xml">
<!ENTITY RFC5549 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5549.xml">
<!ENTITY RFC5565 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5565.xml">
<!ENTITY RFC6074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6074.xml">
<!ENTITY RFC6513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6514 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8277 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8277.xml">
<!ENTITY RFC8950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8950.xml">
<!ENTITY RFC1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC3036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3036.xml">
<!ENTITY RFC3107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3107.xml">
<!ENTITY RFC3270 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3270.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4029 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4029.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4182 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4182.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC8660 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8660.xml">
<!ENTITY RFC8986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8986.xml">
<!ENTITY RFC8754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8754.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC7432 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC9252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9252.xml">
<!ENTITY RFC9256 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xml">
<!ENTITY RFC7938 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7938.xml">
<!ENTITY RFC9313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9313.xml">
<!ENTITY RFC8200 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8200.xml">
<!ENTITY RFC9012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9012.xml">
<!ENTITY RFC8669 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8669.xml">
<!ENTITY I-D.draft-mapathak-interas-ab SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mapathak-interas-ab.xml">
<!ENTITY I-D.draft-ietf-idr-segment-routing-te-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-segment-routing-te-policy.xml">
<!ENTITY I-D.draft-ietf-idr-bgp-sr-segtypes-ext SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-sr-segtypes-ext.xml">
<!ENTITY DYN-CAP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-dynamic-cap.xml">
<!ENTITY I-D.ietf-spring-srv6-srh-compression SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-srv6-srh-compression.xml">

]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space: 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="info" docName="draft-mishra-spring-inter-domain-routing-arch-00" ipr="trust200902">
  <front>
    <title abbrev="SRv6 Inter Domain Routing Architecture">SRv6 Inter Domain Routing Architecture</title>

    <author fullname="Gyan Mishra" initials="G. " surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

    <author fullname="Bruce McDougall" initials="B." surname="McDougall">
      <organization>Cisco Systems</organization>
      <address>
        <email>brmcdoug@cisco.com</email>
      </address>
    </author>
      
    
    <date year="2024"/>
    <area/>
    <workgroup>SPRING Working Group</workgroup>
    <!-- <keyword/> -->
    <abstract>
      <t>	  
       This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and 
	   seamlessly stitching the overlays across inter domain boundaries.  This draft analyzes the SRv6 Design and Operational considerations regarding
	   SRv6 Inter Domain routing and the SRv6 forwarding plane.  This draft also describes three real world use cases of SRv6 Compression Next CSID
	   and operational considrations with regards to SRv6 inter domain routing.   	 
      </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 anchor="intro" title="Introduction">
		
	<t>	
       This draft describes the SRv6 Inter Domain routing architecture with IP VPN and EVPN overlays and 
	   seamlessly stitching the overlays across inter domain boundaries.  This draft analyzes the SRv6 Design and Operational considerations regarding
	   SRv6 Inter Domain routing and the SRv6 forwarding plane.  This draft also describes three real world use cases of SRv6 Compression Next CSID
	   and operational considrations with regards to SRv6 inter domain routing.     	  	 
   </t>

	<t>	
       <xref target="RFC4364"/> describes BGP/MPLS IPv4 VPN and <xref target="RFC4659"/> describes BGP/MPLS IPv6 VPN.
       <xref target="RFC4364"/> describes BGP/MPLS IPv4 VPN Section 10 (a) describes Inter-AS Options A known as back to back PE-CE style peering, 
       Section (b) Inter-AS Option B BGP-LU with Direct eBGP peering VPN overlay, 
       Section (c) describes Inter-AS Option-C ASBR to ASBR interdomain loopbacks advertised with RR to RR eBGP multihop peering with next-hop unchangd. 
   </t>

	<t>	
       With SRv6 MPLS Inter-AS options described in <xref target="RFC4364"/> and <xref target="RFC4659"/> are not applicable.  However the knobs and 
       concepts used in overaly stitching are still very applicable and are used with SRv6.  SRv6 Service SID refers to the SRv6 specific endpoint behaviors 
       defined in SRv6 Programming <xref target="RFC8986"/>.  In this draft we discuss in detail the end to end service stitching of the L2 VPN EVPN and IP VPN SRv6 Service SID endpoint behaviors which
       includes L2 VPN endpoint behaviors End.DX2, End.DX2V, End.DX2U, End.DX2M and IP VPN endpoint behaviors End.DX4, End.DX6, End.DT4 and End.DT6.          
   </t>

	<t>	
       SRv6 inter domain routting L2 VPN EVPN and IP VPN SRv6 service stitching is applicable to SRv6 Programming <xref target="RFC8986"/> 128 bit full SID and SRv6 Compression 
       <xref target="I-D.ietf-spring-srv6-srh-compression"/> C-SID Next C-SID (uSID) endpoint flavor and Replace SID C-SID (G-SID) endpoint flavor.         
   </t>
      

	<t>	
       <xref target="RFC9252"/>  describes BGP Overlay services over SRv6 forwarding plane.  For SRv6 Best effort (BE) service, the egress PE signals an SRv6 service SID with ingress PE
       for the BGP service overlay route.  The ingress PE encapsulates the payload packet from the CE in an outer IPv6 header where the desitnation address is the SRv6 Service SID provided by the egress PE. In this
       case the underlay intermediate notes only need to support IPv6 data plane. In order to provide SRv6 service with an SLA from ingress PE to egress PE, the ingress PE colors the overlay service route with a 
       color extended community  <xref target="RFC9012"/> so the overlay color extended community maps to SR Policy <xref target="RFC9012"/>, overlay color to underlay intent mapping.  The ingress PE
       encapsulates the payload paacket from the CE in an outer IPv6 header with SR Policy candidate SID list related to the SLA path bound to the forwarding plane with Binding SID (BSID) set with the 
       SRv6 service SID associated with the overlay service route active segment in the SRH for 128 bit Full SID or SRv6 Compression Next SID carrier uN endpoint function to forward along the static SID list or dynamic SID list path end to end steering.   
   </t>

	<t>	
       SRv6 Prefix SID attribute <xref target="RFC8669"/> is extended by  <xref target="RFC9252"/> to carry the SRv6 L2 VPN and IP VPN Service SIDs and their associated information in BGP NLRI AFI / SAFI.
       SRv6 L3 Service TLV encodes the service SID information for the SRv6 based L3 services providing the equivalent functionality of MPLS service label when received with a Layer 3 Service route as defined in
       BGP/MPLS VPN-IPv4 <xref target="RFC4364"/> and BGP/MPLS VPN-IPv6 <xref target="RFC4659"/>.  Essentially the SRv6 L3 Service TLV encodes the L3 Service SID for SRv6 based services as an MPLS label for 
       SRv6 Programming <xref target="RFC8986"/> endpoint behaviors End.DX4, End.DX6, End.DT4 and End.DT6.  
       SRv6 L2 Service TLV encodes the service SID information for the SRv6 based L2 services providing the equivalent functionality of MPLS service label for an Ethernet VPN (EVPN) Route Types for L2 services as defined in
       BGP/MPLS EVPN <xref target="RFC7432"/>.  Essentially the SRv6 L2 Service TLV encodes the L2 VPN Service SID for SRv6 based services as an MPLS label for 
       SRv6 Programming <xref target="RFC8986"/> endpoint behaviors End.DX2, End.DX2V, End.DX2U, End.DX2M.          
   </t>

	<t>	
      <xref target="RFC9252"/> defines the encoding of the SRv6 SID information.  The SRv6 Service SIDs for a BGP service prefix is carried in the SRv6 Service TLVs of the BGP Prefix SID attribute as described above <xref target="RFC8669"/>.
      BGP services such as IP VPN BGP/MPLS VPN-IPv4 <xref target="RFC4364"/> and BGP/MPLS VPN-IPv6 <xref target="RFC4659"/> where Per VRF SID allocation is used End.DT4 and End.DT6 endpoint behaviors 
      the same SID is shared across multiple NLRIs, thus providing efficient packing. However for BGP services such as Ethernet VPN (EVPN) <xref target="RFC7432"/> and VPLS / H-VPLS where where per-PW 
      SID allocation is required such as for End.DX2 endpoint behavior, each NLRI would have its own unique SID, resulting in inefficient update packing. 
      <xref target="RFC9252"/> defines an efficient method for update packing for cases such as EVPN NLRI using a transposition scheme, where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the parts
      of the SRv6 SID and indicates the offsets such that the common part locator is encoded into the BGP Prefix SID attribute
      and the variable part Service label encoded into the func / arg field of the SRv6 Service SID is encoded into the NLRI.
   </t>

	<t>	
       This draft describes how to successfully implement end to end inter domain routing over an SRv6 forwarding plane where the L2 VPN EVPN and IP VPN overlay services SRv6 Service SIDs 
       can be stitched end to end.        
   </t>

	<t>	
       <xref target="RFC9252"/> BGP Service Overlay Section 2 last 2 paragraphs discusses the use of Next hop Unchanged (NHU) operational guideline at all eBGP boundaries to signal End-to-End SID.
       The signaling must be done on both side of the eBGP peering for the SID to be propagated End-to-End in both directions.  
       A BGP speaker receiving a route containing the BGP Prefix-SID attribute with one or more SRv6 service TLVs observes the following rules
       when advertising the received route to other peers:
   </t>

	<t>	
       <xref target="RFC9252"/> Rule-1: BGP Service Overlay Section 2 2nd to last paragraph - Broken state when Next hop is changed.
       If the BGP Next Hop is changed, the TLVs, Sub TLVs, or Sub-Sub-TLVs SHOULD be updated with the locally allocated SRv6 SID information 
       from the SID Manager.  Any received Sub-TLVs and Sub-Sub-TLVs that are unrecognized must be removed. SRv6 summary locators are advertised for all Algo's between domains for reachability inter domain routing.
       When the next hop changes between the inter-as PE for L2 VPN or L3 VPN service route the inter domain loopback propagated however since the next hop changes on the eBGP peering
       the next hop is set to the directly connected eBGP subnet and not the Loopback for the service route and has the locally generated SRv6 Service SID resulting in a broken SRv6 Data Plane.       
   </t>

	<t>	
       <xref target="RFC9252"/> Rule-2: BGP Service Overlay Section 2 last paragraph - Solutoin for propagating L2 VPN and L3 VPN SRv6 Service SID end to end
       If the BGP Next Hop is Unchanged during the advertisement, the SRv6 Service TLVs, including any unrecognized types of of Sub-TLVs and Sub-Sub-TLVs, SHOULD be
       propagated further.  In addition, all Reserved fields in the TLV, Sub-TLV, or Sub-Sub-TLV MUST be propagated Unchanged. 
       When the next hop is unchanged between the inter-as PE for L2 VPN or L3 VPN service route the inter domain Loopback is now propagated and has the SRv6 Service SID 
       propagated resulting in SRv6 Data Plane being intact and working end to end. 
   </t>
   

	</section>
	
   <section anchor="termo" title="Terminology">
	<t>	
	Terminolgoy used in defining the SRv6 Inter Domain Routing specification.  
	</t>
	
	  <t>IDR:  SRv6 Inter Domain Routing End to End</t>
	  
	  <t>NH:  BGP Next Hop</t>

	  <t>NHC:  BGP Next Hop Changed</t>
	  
	  <t>NHU:  BGP Next Hop Unchanged</t>
	  
	  <t>NHS:  BGP Next Hop Self</t>	  
	  	  	  
	  <t>Service SID Preserved:  Service SID is does not change and is propagated</t>

	  <t>Service SID Locally Generated:  Service SID is locally generated by SRv6 SID Manager</t>

	       
 	</section>


    <section anchor="top" title="SRv6 Inter Domain Routing Topology">

      
		<t>
        SRv6 Inter Domain Routing topology is made up of a two domains.   Domain-1 AS1 is made up of PE1 and PE2 which have iBGP peering between them. Domain-2 AS2 is made up of PE3.
        PE2 is the inter-as ASBR eBGP peering to AS2 PE3 ASBR.  ALl nodes PE1, PE2 and PE3 are running <xref target="I-D.ietf-spring-srv6-srh-compression"/> C-SID Next C-SID (uSID) endpoint flavor. 

 	    </t>

  		     <figure anchor="top1a" title="SRv6 Inter Domain Routing Topology">
       <artwork align="center">
		   					   
		             SRv6 Next SID Topology
                                                      
              
  Loc:fc00:0:1::/48             Loc:fc00:0:2::/48       Loc:fc00:0:3::/48		             
  Lo0:fc00:0:1::1               Lo0:fc00:0:2::1         Lo0:fc00:0:3::1
   +-------+                     +-------+                    +-------+
   |   AS1 |2001:1::2/127        |   AS1 |       2001:1::5/127|  AS2  |
   |   PE1 |---------------------|   PE2 |--------------------|  PE3  |
   |       |        2001:1::3/127| (ASBR)|2001:1::4/127       |(ASBR) | 
   +-------+                     +-------+                    +-------+

             iBGP (Remote Peer)             eBGP (Local Peer)
 		

 	                        
          </artwork>
     </figure>       





 	</section>



    <section anchor="problem" title="SRv6 Inter Domain Routing - Inter-AS Local Peer">

      <section anchor="prob1" title="SRv6 Inter Domain Routing - SID Not Signalled ">

		<t>
        SRv6 Inter Domain Routing - eBGP Data Plane Broken:
 	    </t>

  		     <figure anchor="prob1a" title="SRv6 Inter Domain Routing - SID Not Signalled">
       <artwork align="center">
		   					   
	 eBGP Direct Peering  (NHC = Next Hop Changed) - (Local Peer)
                           ::4 - ::5 - SID Changes 

          Loc:fc00:0:2::/48           Loc:fc00:0:3::/48		             
          Lo0:fc00:0:2::1             Lo0:fc00:0:3::1
         +-------+                    +-------+
         |   AS1 |       2001:1::5/127|  AS2  |
         |   PE2 |--------------------|  PE3  |
         | (ASBR)|2001:1::4/127       |(ASBR) | 
         +-------+                    +-------+
         NHC:2001:1::4
         vpn sid:fc00:0:2::db8a::  
               
                       eBGP (Local Peer)
                       
 		
 If R2 advertised with NHC 2001:1::4
 vpn sid not preserved fc00:0:1:db8a::	
 when NH changes the service sid changes
 R3 Sees valid/best path but SID is locally generated
 	                        
          </artwork>
     </figure>       



		<t>
        SRv6 eBGP Inter-AS L2 EVPN, L3 VPN Overlay
 	    </t>       
        
		  <t>
		    SRv6 Data Plane Broken Characteristics:
		  </t>
		  <t>
		    1. When the Next hop changes the Label Changes
		  </t>    
		  <t>		     
		    NHC = Next Hop Changed is the default behavior on eBGP peering
		  </t> 
		  
		  <t>
		    2. MPLS Service Label (L2 VPN / L3 VPN) = SRv6 Service SID
		  </t>		  
		  		  
		  <t>
		    3. When the MPLS Label changes the SRv6 Service SID changes
		  </t>		
		  
		  <t>		      
		    SRv6 SID is now locally generated by SID Manager instead of being propagated
		  </t>
		  <t>  
		    <xref target="RFC9252"/> Rule-1: BGP Service Overlay Section 2 2nd to last paragraph when the Next Hop is Changed (NHC) the SRv6 Service SID is locally generated
		  </t>
		  	
		  <t>
		    4. SRv6 SID is not propagated end to end
		  </t>	

 	</section>

      <section anchor="sol1" title="SRv6 Inter Domain Routing - SID Signalled">
		  
		<t>
        SRv6 Inter Domain Routing - SID Signalled:
 	    </t>

  		     <figure anchor="sol1a" title="SRv6 Inter Domain Routing - SID Signalled">
       <artwork align="center">
		   					   
	eBGP Direct Peering  (NHU = Next Hop Unchanged) - (Local Peer)
                           

          Loc:fc00:0:2::/48           Loc:fc00:0:3::/48		             
          Lo0:fc00:0:2::1             Lo0:fc00:0:3::1
         +-------+                    +-------+
         |   AS1 |       2001:1::5/127|  AS2  |
         |   PE2 |--------------------|  PE3  |
         | (ASBR)|2001:1::4/127       |(ASBR) | 
         +-------+                    +-------+
         NHU:fc00:0:2::1
         vpn sid:fc00:0:2::e005::  
               
                       eBGP (Local Peer)
                       
 		
 If R2 advertised with NHU fc00:0:2::1
 vpn sid is preserved fc00:0:1:e005::	
 when NH changes the service sid changes
 R3 sees valid/best path next hop is accessible
 	                        
          </artwork>
     </figure>       



		<t>
        SRv6 eBGP Inter-AS L2 EVPN, L3 VPN Overlay
 	    </t>       
        
		  <t>
		    SRv6 Data Plane Working Characteristics:
		  </t>
		  <t>
		    1. When the Next hop is Unchanged the MPLS Label is Preserved
		  </t>
		  <t>		  		    
		    NHU = Next Hop Unchanged 
		  </t>
		  
		  <t>
		    2. MPLS Service Label (L2 VPN / L3 VPN) = SRv6 Service SID
		  </t>	
		  	  		  
		  <t>
		    3. When the MPLS Label is preserved the SRv6 Service SID is preserved
		  </t>
		  <t> 
		    <xref target="RFC9252"/> Rule-2: BGP Service Overlay Section 2 last paragraph when the next hop is Unchanged (NHU) the SRv6 Service SID is propagated
		  </t>
		  
		  <t>		  		    
		   4. SRv6 SID propagated end to end.
		  </t>
		  	


  	</section>	
  		
 </section>		  


    <section anchor="probleme2e" title="SRv6 Inter Domain Routing E2E - Inter-AS Remote Peer">

      <section anchor="probe2e1" title="SRv6 Inter Domain Routing E2E - eBGP / iBGP - SID Not Signalled">

		<t>
        SRv6 Inter Domain Routing - eBGP / iBGP - SID Not Signalled:
 	    </t>

  		     <figure anchor="probe2e1a" title="SRv6 Inter Domain Routing E2E - eBGP / iBGP - SID Not Signalled">
       <artwork align="center">
		   					   
		             SRv6 Data Plane Broken  (NHC = Next Hop Changed)
                                                      ::4 - ::5 
              NHS re-write Loopback0
  Loc:fc00:0:1::/48             Loc:fc00:0:2::/48       Loc:fc00:0:3::/48		             
  Lo0:fc00:0:1::1               Lo0:fc00:0:2::1         Lo0:fc00:0:3::1
   +-------+                     +-------+                    +-------+
   |   AS1 |2001:1::2/127        |   AS1 |       2001:1::5/127|  AS2  |
   |   PE1 |---------------------|   PE2 |--------------------|  PE3  |
   |       |        2001:1::3/127| (ASBR)|2001:1::4/127       |(ASBR) | 
   +-------+                     +-------+                    +-------+
NHC:fc00:0:1::1           NHC:2001:1::4              NHC:2001:1::4
vpn sid:fc00:0:1::abdf::  vpn sid:fc00:0:2::db8a::   vpn sid:fc00:0:2::db8a::
               
             iBGP (Remote Peer)             eBGP (Local Peer)
    ---------------------------------------------------------------->>  
NHC:fc00:0:1::1          If R2 advertises with NHC 2001:1::4   
vpn sid:fc00:0:1::abdf:: vpn sid not preserved fc00:0:2::db8a::
SID Not Preserved        R3 sees valid/best but sid locally generated on PE2	    
 		

 	                        
          </artwork>
     </figure>       



		<t>
        SRv6 eBGP Inter-AS L2 EVPN, L3 VPN Overlay
 	    </t>       
        
		  <t>
		    SRv6 Data Plane Broken Characteristics End to End:
		  </t>
		  <t>
		    1. When the Next hop changes the Label Changes
		  </t>    
		  <t>		     
		    NHC = Next Hop Changed is the default behavior on eBGP peering
		  </t>
		  <t>
		    <xref target="RFC9252"/> Rule-1: BGP Service Overlay Section 2 2nd to last paragraph when the Next Hop is Changed (NHC) the SRv6 Service SID is locally generated
		  </t> 

		  <t>		     
		    NHS = Next Hop Self configuration on iBGP peering PE-RR (Typical configuration)
		  </t> 

		  <t>		     
		    For the iBGP peering (Remote peering) with NHS the next hop is re-written to the Loopback0 (Changed)
		  </t>  
		  <t>  
		    <xref target="RFC9252"/> Rule-1: BGP Service Overlay Section 2 2nd to last paragraph when the Next Hop is Changed (NHC) the SRv6 Service SID is locally generated
		  </t> 
		  
		  <t>
		    2. MPLS Service Label (L2 VPN / L3 VPN) = SRv6 Service SID
		  </t>
		  		  		  
		  <t>
		    3. When the MPLS Label changes the SRv6 Service SID changes
		  </t>		
		  <t>		      
		    SRv6 SID is now locally generated by SID Manager instead of being propagated
		  </t>	
		  
		  <t>
		    4. SRv6 SID not propagated end to end
		  </t>	

 	</section>

      <section anchor="sole2e1" title="SRv6 Inter Domain Routing E2E - eBGP / iBGP - SID Signalled">
		  
		<t>
        SRv6 Inter Domain Routing - eBGP  - SID Signalled:
 	    </t>

  		     <figure anchor="sole2e1a" title="SRv6 Inter Domain Routing E2E - eBGP / iBGP - SID Signalled">
       <artwork align="center">


		             SRv6 Data Plane Working  (NHU = Next Hop Unchanged)
                                                      ::4 - ::5 
             No NHS re-write Loopback0
  Loc:fc00:0:1::/48             Loc:fc00:0:2::/48           Loc:fc00:0:3::/48		             
  Lo0:fc00:0:1::1               Lo0:fc00:0:2::1             Lo0:fc00:0:3::1
   +-------+                     +-------+                    +-------+
   |   AS1 |2001:1::2/127        |   AS1 |       2001:1::5/127|  AS2  |
   |   PE1 |---------------------|   PE2 |--------------------|  PE3  |
   |       |        2001:1::3/127| (ASBR)|2001:1::4/127       |(ASBR) | 
   +-------+                     +-------+                    +-------+
NHU:fc00:0:1::1           NHU:fc00:0:1::1           NHU:fc00:0:1::1
vpn sid:fc00:0:1::e006::  vpn sid:fc00:0:1::e006::  vpn sid:fc00:0:1::e006::
               
              iBGP (Remote Peer)             eBGP (Local Peer)
  ---------------------------------------------------------------->> 
   If R1 advertises with NHC fc00:0:1::1  
   vpn sid preserved fc00:0:1::e006::     
   R2 sees valid/best NH is accessible	   
             		   					   
                                   If R2 advertises with NHC fc00:0:1::1
                                   vpn sid preserved fc00:0:1::e006::
                                   R3 sees valid/best NH is accessible   	                        
          </artwork>
     </figure>       



		<t>
        SRv6 eBGP Inter-AS L2 EVPN, L3 VPN Overlay
 	    </t>       
        
		  <t>
		    SRv6 Data Plane Working Characteristics End to End:
		  </t>
		  <t>
		    1. When the Next hop is Unchanged the MPLS Label is Preserved
		  </t>
		  <t>  
		    <xref target="RFC9252"/> Rule-2: BGP Service Overlay Section 2 last paragraph when the next hop is Unchanged (NHU) the SRv6 Service SID is propagated
		  </t>
		  <t>		  		    
		    NHU = Next Hop Unchanged 
		  </t>
		  <t>		     
		    Remove NHS = Next Hop Self configuration on iBGP peering PE-RR
		  </t> 

		  <t>		     
		    By removing NHS the NH does not change essentially "unchanged" allowing the NH to be propagated end to end
		  </t>
		  <t>  
		    <xref target="RFC9252"/> Rule-2: BGP Service Overlay Section 2 last paragraph when the next hop is Unchanged (NHU) the SRv6 Service SID is propagated 
		  </t> 

		  
		  <t>
		    2. MPLS Service Label (L2 VPN / L3 VPN) = SRv6 Service SID
		  </t>	
		  	  		  
		  <t>
		    3. When the MPLS Label is preserved by not changing the SRv6 Service SID is preserved
		  </t>
		  <t>		  		    
		   4. SRv6 SID propagated end to end. 
		  </t>
		  		


  	</section>	
  		
 </section>		  


    <section anchor="Op" title="Operational Considerations">
    <t> 
	Operational Guidance to always use Next-Hop-Unchanged (NHU) on all eBGP boundaries on both sides of the eBGP peering to signal "End to End SID" for SID propagation
	End-to-End in both directions.	
    </t>

    <t> 
	Operational Guidance to not use Next-Hop-Self on iBGP PE-RR peering so that the received service SID from an Ingress Domain is propagated "End to End"
	to an Egress Domain and vice versa in both directions.
    </t>

    <t> 
	Operational Guidance is applicable to both SRv6 (Full SID) and SRv6 compression.
    </t>


	
    </section>

	
    <section anchor="IANA" title="IANA Considerations">
    <t> There are not any IANA considerations.
    </t>
	
    </section>
    
    <section anchor="security" title="Security Considerations">
	<t>
   No new extensions are defined in this document.  As such, no new security issues are raised beyond those
   that already exist in BGP-4 and use of MP-BGP for IPv6.
   </t>
	<t>
   The security features of BGP and corresponding security policy
   defined in the ISP domain are applicable.
   </t>
	<t>
   For the inter-AS distribution of IPv6 prefixes according to case (a) of
   Section 4 of this document, no new security issues are raised beyond
   those that already exist in the use of eBGP for IPv6 <xref target="RFC2545"/>.
   </t>
	</section>
	
		
	<section anchor="ack" title="Acknowledgments">
		<t></t> 
	</section>
  </middle>
  <back>
    <references title="Normative References">
      &RFC2119;
	  &RFC2545;
	  &RFC4291;
	  &RFC4364;
	  &RFC4760;
	  &RFC5492;
	  &RFC8174;
	  &RFC8277;
	  &RFC8950;
	  &RFC1812;
	  &RFC3031;
	  &RFC3032;
	  &RFC3036;
	  &RFC3107;	  
	  &RFC3270;	  
	  &RFC2460;
	  &RFC4443;
	  &RFC4029;	  
	  &RFC4271;	  
	  &RFC4182;	 
	  &RFC1122;	
	  &RFC5036;	
	  &RFC8660;		  	  	  
	  &RFC8986;	
	  &RFC8754;	
	  &RFC3209;	
	  &RFC8402;
	  &RFC7432;
	  &RFC9252;
	  &RFC9256;	  
	  &RFC7938;
	  &RFC9313;	   
	  &RFC9012;	
	  &RFC8669;		
	  &RFC8200;	  	  
	  &I-D.draft-ietf-idr-segment-routing-te-policy;
	  &I-D.draft-ietf-idr-bgp-sr-segtypes-ext;	
      &I-D.ietf-spring-srv6-srh-compression;	  	
    </references>
	<references title="Informative References">
	&DYN-CAP;
	&RFC4659;
	&RFC4684;
	&RFC4798;
	&RFC4925;
	&RFC8126;
	&RFC5549;
	&RFC5565;
	&RFC6074;
	&RFC6513;
	&RFC6514;
	&I-D.draft-mapathak-interas-ab;
    </references>
    <!-- references title="Informative References">
    </references -->
 
 	<section anchor="Appendix" title="APPENDIX-A">

      <t>
       SRv6 Compression <xref target="I-D.ietf-spring-srv6-srh-compression"/> C-SID Next C-SID (uSID) endpoint flavor Inter Domain Routing development work is all contained in GitHub link below.
      </t>
      <t>
       https://github.com/segmentrouting/srv6-labs/tree/main/3-srv6-dc-case-studies
      </t>       
         
       
  </section>	
        
  </back>
</rfc>
