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

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-liu-opsawg-ipfix-bgp-vpn-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <title abbrev="IPFIX for BGP VPN">Export of BGP VPN Information in IPFIX</title>
    <seriesInfo name="Internet-Draft" value="draft-liu-opsawg-ipfix-bgp-vpn-01"/>
   <author fullname="Yao Liu" surname="Liu">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>liu.yao71@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Liman Zhao" surname="Zhao">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone></phone>
        <email>zhao.liman@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Yisong Liu" surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone></phone>
        <email>liuyisong@chinamobile.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	

	
    <date year="2026"/>

   <!-- Meta-data Declarations -->

   <area>OPS</area>
    <workgroup>OPSAWG</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>IPFIX</keyword>
   <keyword>BGP VPN</keyword>
   <keyword>Segment Routing</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>This document introduces new IP Flow Information Export (IPFIX) information elements to carry the egress PE information in IPFIX. <!--This document also discusses how to export the forwarding path information of the VPN traffic flow in IPFIX.--></t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  <t>BGP/MPLS VPN, as described in <xref target="RFC4364"></xref>, is a method that uses BGP to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. And each route within a VPN is assigned an MPLS label.</t>	
	  <t>Typical MPLS VPN scenarios include:</t>
	  <ul spacing="normal">
		<li>MPLS VPN over MPLS traffic engineering (MPLS-TE) tunnel: The MPLS-TE tunnel can be built based on RSVP-TE LSP <xref target="RFC5824"></xref> or SR-MPLS Policy.</li>
		<li>MPLS VPN with MPLS best effort tunnel: A single MPLS label/SR-MPLS SID for the FEC on the egress PE is used to tunnel the VPN traffic over the backbone.</li>
		</ul>
	  
	  <t>For SRv6 VPN services, <xref target="RFC9252"></xref> defines procedures and messages for SRv6-based BGP services, including L3VPN, EVPN, and Internet services. SRv6 Service SID refers to an SRv6 SID associated with one of the service-specific SRv6 Endpoint Behaviors on the advertising PE router.</t>
	  
	  <t>As in <xref target="RFC9252"></xref>, typical SRv6 VPN scenario includes:</t>
	  <ul spacing="normal">
		<li>SRv6 service with SRv6-TE connectivity: To provide SRv6 service in conjunction with an underlay Service Level Agreement (SLA) from the ingress PE to the egress PE, the egress PE colors the overlay service route with a Color Extended Community <xref target="RFC9012"></xref> for steering flows for those routes. The ingress PE encapsulates the payload packet in an outer IPv6 header with the SR Policy segment list associated with the related SLA along with the SRv6 Service SID associated with the route using the Segment Routing Header (SRH) <xref target="RFC8754"></xref>.</li>
		<li>SRv6 service with best-effort(SRv6-BE) connectivity: The egress PE signals an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. The underlay between the PEs only needs to support plain IPv6 forwarding.</li>
		</ul>	  

	<t>When monitoring traffic flows on the ingress PE in a network with BGP VPN deployed, the network monitor may want to know the following information:</t>
		<ul spacing="normal">
		<li>Which egress PE is the flow forwarded to ?</li>
		<li>How is the traffic transmitted through the network ?</li>
		</ul>
	
	<t>This document introduces new IP Flow Information Export (IPFIX) information elements to carry the egress PE information in IPFIX. <!--This document also discusses how to export the forwarding path information of the VPN traffic flow in IPFIX.--></t>
	 </section>		
		


<section numbered="true" toc="default">
        <name>Terminology</name>
		<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"></xref> <xref target="RFC8174" format="default"></xref> when, and only when, they appear in all capitals, as shown here.</t>
		<t>This document makes use of the terms defined in <xref target="RFC7011" format="default"></xref>, <xref target="RFC8402" format="default"></xref> and <xref target="RFC9252" format="default"></xref>.</t>
		<t>The following terms are used as defined in <xref target="RFC7011" format="default"></xref>:</t>	
		<ul spacing="normal">
		<li>IPFIX</li>
		<li>IPFIX Information Elements</li>
		<li>Metering Process</li>
		<li>Template Record</li>
		<li>Data Record</li>
		<li>Collector</li>		
		</ul>
		<t>The following terms are used as defined in <xref target="RFC8402" format="default"></xref>:</t>	
		<ul spacing="normal">
		<li>Segment Routing (SR)</li>
		<li>Segment List</li>
		<li>SRv6</li>
		<li>SR-MPLS</li>
		<li>Segment Identifier (SID)</li>
		</ul>
		<t>The following terms are used as defined in <xref target="RFC9252" format="default"></xref>:</t>	
		<ul spacing="normal">
		<li>SRv6 Service SID</li>
		</ul>		
      </section>

<section numbered="true" toc="default">
	<name>New IPFIX IEs for VPN Egress PE Information </name>	
<t>The following subsections defines different types of IEs to fulfill the requirement to obtain the egress PE information via IPFIX.</t>
<section numbered="true" toc="default" anchor="section3.1" >
	<name>BGP VPN Next Hop Information</name>	
	<t>Two new IEs are defined in this section to identify the next hop address of the BGP VPN route. One for IPv4 address and the other for IPv6 address. The BGP next hop address is an address of the egress PE router as in <xref target="RFC4364"></xref>. </t>
<section numbered="true" toc="default" anchor="section3.1.1" >
	<name>bgpVpnNextHopIPv4Address</name>
	
		<dl newline="false" indent="3" spacing="normal" >
          <dt>Name:</dt>
          <dd>
            <t>bgpVpnNextHopIPv4Address</t>
          </dd>
          <dt>ElementID:</dt>
          <dd >
            <t>TBD1</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t indent="0">The 32-bit IPv4 address on the egress PE which is used as the next hop address of the BGP VPN route.</t> 
          </dd>
          <dt>Abstract Data Type:</dt>
          <dd>
            <t indent="0" >default</t>
          </dd>
          <dt>Data Type Semantics:</dt>
          <dd >
            <t indent="0">ipv4Address</t>
          </dd>
          <dt>Additional Information:</dt>
          <dd>
            <t indent="0">Specified in <xref target="RFC4364" format="default"></xref>.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t indent="0" >This document.</t>
          </dd>
        </dl>
</section>

<section numbered="true" toc="default" anchor="section3.1.2" >
	<name>bgpVpnNextHopIPv6Address</name>
		
<dl newline="false" indent="3" spacing="normal" >
          <dt>Name:</dt>
          <dd>
            <t>bgpVpnNextHopIPv6Address</t>
          </dd>
          <dt>ElementID:</dt>
          <dd >
            <t>TBD2</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t indent="0">The 128-bit IPv6 address on the egress PE which is used as the next hop address of the BGP VPN route.</t> 
          </dd>
          <dt>Abstract Data Type:</dt>
          <dd>
            <t indent="0" >default</t>
          </dd>
          <dt>Data Type Semantics:</dt>
          <dd >
            <t indent="0">ipv6Address</t>
          </dd>
          <dt>Additional Information:</dt>
          <dd>
            <t indent="0">See <xref target="RFC4659" format="default"></xref> for more information about the IPv6 Next Hop Network Address.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t indent="0" >This document.</t>
          </dd>
        </dl>
</section>		
</section>
<section numbered="true" toc="default" anchor="section3.2">
	<name>SRv6 Service SID Locator in IPFIX </name>	
	<t>In the case of SRv6 VPN, another choice to be aware of the egress PE information is to export the locator information of the SRv6 service SID, since generally the SRv6 locators are well planned in the network, and different PEs are usually assigned with different locators. </t>
	<t><xref target="RFC9487" format="default"></xref> defines IE "srhSegmentIPv6" and IE "srhSegmentIPv6LocatorLength", and it enables the calculation of the SRv6 Locator when the two IEs are used together. However, the requirement to export the locator of the SRv6 service SID can not be fulfilled using "srhSegmentIPv6" and "srhSegmentIPv6LocatorLength" due to the following reasons: </t>
	
		  <ul spacing="normal">
		<li>In the SRv6-TE scenario, the SRv6 service SID would be encapsulated in the SRH as the last segment(i.e, Segment List[0]) of the segment list in SRH. Although "srhSegmentIPv6" is the 128-bit IPv6 address that represents an SRv6 segment, there's no mechanism yet to solely export Segment List[0](or any other segment besides the active segment) in the SRH.</li>
		<li>In the SRv6-BE scenario, the SRv6 service SID is encapsulated as the destination address of the IPv6 header by the ingress PE. Theoretically, the IE "destinationIPv6Address" and "destinationIPv6PrefixLength" defined in <xref target="RFC7012" format="default"></xref> can be used to calculate the the IPv6 prefix length of the SRv6 service SID. But if this method is used, the network analyzer needs to know exactly which flows are VPN flows using SRv6-BE forwarding to distinguish SRv6 Service SID from the normal IPv6 address carried in the IPv6 destination address field.</li>
		</ul>

<t>To export locator of the SRv6 Service SID which is advertised via BGP VPN routes, the following IEs are defined, and this method is applicable for both SRv6-TE and SRv6-BE scenario.</t>

<section numbered="true" toc="default" anchor="section3.2.1" >
	<name>srv6ServiceSidLocator</name>

<dl newline="false" indent="3" spacing="normal" >
          <dt>Name:</dt>
          <dd>
            <t>srv6ServiceSidLocator</t>
          </dd>
          <dt>ElementID:</dt>
          <dd >
            <t>TBD3</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t indent="0">The Locator of the SRv6 Service SID signaled by the egress PE via BGP.</t> 
          </dd>
          <dt>Abstract Data Type:</dt>
          <dd>
            <t indent="0" >default</t>
          </dd>
          <dt>Data Type Semantics:</dt>
          <dd >
            <t indent="0">ipv6Address</t>
          </dd>
          <dt>Additional Information:</dt>
          <dd>
            <t indent="0">See <xref target="RFC9252" format="default"></xref> for more information about the SRv6 service SID. See Section 3.1 of <xref target="RFC8986" format="default"></xref> for more details about the SID format.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t indent="0" >This document.</t>
          </dd>
        </dl>
</section>

<section numbered="true" toc="default" anchor="section3.2.2" >
	<name>srv6ServiceSidLocatorLength</name>
<dl newline="false" indent="3" spacing="normal" >
          <dt>Name:</dt>
          <dd>
            <t>srv6ServiceSidLocatorLength</t>
          </dd>
          <dt>ElementID:</dt>
          <dd >
            <t>TBD4</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t indent="0">The length of the SRv6 Locator of the SRv6 service SID specified as the number of significant bits. Together with srv6ServiceSid, it enables the calculation of SRv6 Locator of the SRv6 service SID.</t> 
          </dd>
          <dt>Abstract Data Type:</dt>
          <dd>
            <t indent="0" >default</t>
          </dd>
          <dt>Data Type Semantics:</dt>
          <dd >
            <t indent="0">default</t>
          </dd>
          <dt>Additional Information:</dt>
          <dd>
            <t indent="0">See Section 3.1 of <xref target="RFC8986" format="default"></xref> for more details about the SID format.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t indent="0" >This document.</t>
          </dd>
        </dl>
</section>




	
</section>		
</section>
<!--
<section numbered="true" toc="default">
	<name>Exporting Forwarding Path Information of VPN Traffic </name>
	<t>In the case that a TE tunnel(e.g., an RSVP-TE LSP, SR-MPLS Policy or SRv6 Policy) is used for VPN traffic tunneling, the forwarding path of the VPN traffic can be obtained by exporting the tunnel information. </t>
	<t>However, when SR-MPLS BE are used to tunnel the VPN packets over the backbone, e.g., the ingress PE encapsulates the packets with the Prefix-SID of the egress PE and the VPN label, by looking at the top MPLS label and the next hop address of the BGP VPN route, the forwarding path information is not clear. A possible method is to export the corresponding prefix of the prefix SID of the egress PE, which is advertised to the ingress PE via IGP, using IE mplsTopLabelIPv4Address(47)/mplsTopLabelIPv6Address(140), together with the IGP algorithm [draft-liu-opsawg-ipfix-igp-algo], the information of egress PE and the forwarding plane can be obtained. </t>
	<t>It should be noticed that, the prefix of the prefix-SID and next hop of the BGP VPN route of the may be the same address on the egress PE(e.g., the loopback address on the egress PE), or they may be different addresses on the egress PE(e.g., the loopback address on the egress PE is used as the BGP next hop and an address of the interface on PE is assign with an prefix-SID).</t>
	
</section>	
-->
	
<section numbered="true" toc="default">
	<name>Operational Considerations</name>
	<t>The IE bgpNextHopIPv4Address(18) and bgpNextHopIPv6Address(63) define the IPv4/IPv6 address of the next (adjacent) BGP hop. If BGP VPN route is the only BGP route deployed on the PE, IE 18 and IE 63 MAY be used to indicate the next hop address of the BGP VPN route. However, when there're many types of BGP route used in the network(e.g., BGP VPN <xref target="RFC4364" format="default"></xref> is used together with BGP-LU<xref target="RFC8277" format="default"></xref>), it is not clear which type of the BGP route the next BGP hop carried in IE 18 or IE 63 belongs to. In this case, using bgpVpnNextHopIPv4Address and bgpVpnNextHopIPv6Address defined in this document to carry the next hop address of the BGP VPN route is more appropriate.</t>
	<t>In the multi-as backbones, if inter-AS option A or option B with BGP next-hop changed are used as described in <xref target="RFC4364" sectionFormat="of" section="10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4364#section-10" derivedContent="RFC4364"/>, the address of the egress PE can't be obtained via "bgpVpnNextHopIPv4Address" or "bgpVpnNextHopIPv6Address" since the next hop address of the BGP VPN route received by the ingress PE is not the address of the egress PE. </t>	

</section>


<section numbered="true" toc="default">
	<name>Security Considerations</name>
		<t>There are no additional security considerations regarding allocation of these new IPFIX IEs compared to <xref target="RFC7012" format="default"></xref>.</t>
		<t>Other security considerations for BGP/MPLS VPN in <xref target="RFC4364"></xref> and  for BGP Overlay Services Based on SRv6 in <xref target="RFC9252"></xref> apply to this document.</t>
</section>	

<section numbered="true" toc="default">
	<name>IANA Considerations</name>
		<t>This document requests IANA to create new IEs under the "IPFIX Information Elements" registry <xref target="RFC7012" format="default"></xref> available at <xref target="IANA-IPFIX" format="default" sectionFormat="of" derivedContent="IANA-IPFIX"/>.</t>
		
				<table anchor="iana-psid">
		<name>IPFIX Information Elements Registry</name>
		<thead>
		<tr>
		<td>Element ID</td><td>Name</td><td>Reference</td>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>TBD1</td><td>bgpVpnNextHopIPv4Address</td><td><xref target="section3.1.1"/></td>
		</tr>
		</tbody>
		<tbody>
		<tr>
		<td>TBD2</td><td>bgpVpnNextHopIPv6Address</td><td><xref target="section3.1.2"/></td>
		</tr>
		</tbody>
		<tbody>
		<tr>
		<td>TBD3</td><td>srv6ServiceSidLocator</td><td><xref target="section3.2.1"/></td>
		</tr>
		</tbody>
		<tbody>
		<tr>
		<td>TBD4</td><td>srv6ServiceSidLocatorLength</td><td><xref target="section3.2.2"/></td>
		</tr>
		</tbody>		
	</table>		
		

	</section>


	
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

		<?rfc include="reference.RFC.2119.xml"?>
		<?rfc include="reference.RFC.8174.xml"?>
		<?rfc include="reference.RFC.9252.xml"?>
		<?rfc include="reference.RFC.7012.xml"?>
		<?rfc include="reference.RFC.4659.xml"?>
		<?rfc include="reference.RFC.7011.xml"?> 
		<?rfc include="reference.RFC.8986.xml"?> 
		<?rfc include="reference.RFC.4364.xml"?>
		
		
		<reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/ipfix" quoteTitle="true" derivedAnchor="IANA-IPFIX">
          <front>
            <title>IP Flow Information Export (IPFIX) Entities</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
	  
      </references>
      <references>
        <name>Informative References</name>
		<?rfc include="reference.RFC.8402.xml"?>
		<?rfc include="reference.RFC.9487.xml"?>		
		<?rfc include="reference.RFC.9012.xml"?>
		<?rfc include="reference.RFC.8754.xml"?>
		<?rfc include="reference.RFC.5824.xml"?>
		<?rfc include="reference.RFC.8277.xml"?>
      </references>
    </references>


 </back>
</rfc>
