<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-yu-spring-srv6-gbp-00"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
  <front>
    <title abbrev="Abbreviated Title">SRv6 Group Based Policy</title>

    <seriesInfo name="Internet-Draft" value="draft-yu-spring-srv6-gbp-00"/>
   
    <author fullname="Tianpeng Yu" initials="T." role="editor" surname="Yu"> 
            <organization> </organization>
            <address>
                <postal>
                    <street />
                    <city />
                    <region />
                    <code />
                    <country />
                </postal>
                <phone />
                <email>yutianpengietf@163.com</email>
            </address>
    </author>

    <date year="2025"/>
 

    <area>Routing Area</area>
    <workgroup>Source Packet Routing in Networking</workgroup>


    <keyword></keyword>


    <abstract>
      <t> This document extends the <xref target="RFC8986"> Segment Routing over IPv6 (SRv6)
                Network Programming framework</xref> by incorporating group-based policy
                capabilities. </t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
     <t> The Group-based Policy (GBP) <xref target="GROUPBASEDPOLICY"> </xref> initially was .It abstractions
                provide an intent-driven declarative policy model that presents simplified
                application-oriented interfaces to the user. Group-Based Policy (GBP) is a critical
                concept in networking and security, particularly in environments like
                Software-Defined Networking (SDN), cloud computing, and enterprise networks. It
                provides a flexible and scalable way to manage network policies based on groups of
                endpoints rather than individual devices, IP addresses, or flows. </t>
    </section>
    <section>
          <name>Specification of Requirements</name>
            <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" />. </t>
    </section> 
            <section>  
          <name>Terminology</name>
            <t>GBP: Group-based Policy described in <xref target="GROUPBASEDPOLICY"> </xref></t>
            <t>EVPN: BGP MPLS-Based Ethernet VPN defined in <xref target="RFC7432"> </xref>.</t>
        </section>
        <section>
          <name>SRv6 SIDs with GBP</name>
            <t> This documents defines the behaviors of END.DX6 with GBP, END.DX4 with GBP, END.DT6 with GBP, END.DT4 with GBP, END.DT46 with GBP, END.DT2U with GBP by allowing these SID behaviors taking an argument: "Arg.Src-GBP-ID". The Src-GBP-ID info allows endpoint node to determine the behavior (allowed or denied) when traffic is being forwarded to specific host. The allocation of the GBP-id argument values planned gloabally, and the behavior of traffic from one Src-GBP-ID to another Dst-GBP-ID is specified locally.
            The SRv6 SIDs with the GBP argument mentioned in this document is not signaled to other nodes via the control plane, which means they are local significant only. The control plane process described in <xref target="RFC9252"> </xref> still applies.
            </t>

            <t>Group 0 is the default group based policy ID. If no group based policy is specified, then value 0 is used. The default behavior of the group 0 is implementation defined and SHOULD be configurable (allowed/denied).</t>

            <section>
              <name>END.DX6 with GBP</name>
<t>When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX6 with GBP SID, N does the following:</t>

<sourcecode type="pseudocode">
<![CDATA[
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S04.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05.    If (Matched){
S06.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07.    } Else {
S08.        Forward the exposed IPv6 packet to the L3 adjacency J
S09.    }
S10. } Else {
S11.    Process as per Section 4.1.1 in RFC8986
S12. }        ]]>
</sourcecode>
            </section>
            <section title="END.DX4 with GBP">
<t>When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX4 with GBP SID, N does the following:</t>

<sourcecode type="pseudocode">
<![CDATA[
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S04.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05.    If (Matched){
S06.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07.    } Else {
S08.        Forward the exposed IPv4 packet to the L3 adjacency J
S09.    }
S10. } Else {
S11.    Process as per Section 4.1.1 in RFC8986
S12. }          
]]>
</sourcecode>
            </section>

            <section title="End.DT6 with GBP">
<t>When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT6 with GBP SID, N does the following:</t>

<sourcecode type="pseudocode">
<![CDATA[
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Set the packet's associated FIB table to T
S04.    Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S05.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S06.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S07.    If (Matched){
S08.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S09.    } Else {
S10.        Forward the exposed IPv6 packet to the oIF.
S11.    }
S12. } Else {
S13.    Process as per Section 4.1.1 in RFC8986
S14. }          
]]>
</sourcecode>

<t>An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.</t>
<sourcecode type="pseudocode">
  <![CDATA[
S01. If (Upper-Layer header type == 41(IPv6) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S04.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05.    If (Matched){
S06.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07.    } Else {
S08.        Set the packet's associated FIB table to T
S09.        Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination
S10.    }
S11. } Else {
S12.    Process as per Section 4.1.1 in RFC8986
S13. }          
]]>
</sourcecode>
            </section>

            <section title="End.DT4 with GBP">
<t>When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT4 with GBP SID, N does the following:</t>

<sourcecode type="pseudocode">
  <![CDATA[
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Set the packet's associated FIB table to T
S04.    Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S05.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S06.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S07.    If (Matched){
S08.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S09.    } Else {
S10.        Forward the exposed IPv4 packet to the oIF.
S11.    }
S12. } Else {
S13.    Process as per Section 4.1.1 in RFC8986
S14. }          
]]>
</sourcecode>

<t>An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.</t>
<sourcecode type="pseudocode">
  <![CDATA[
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S04.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05.    If (Matched){
S06.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07.    } Else {
S08.        Set the packet's associated FIB table to T
S09.        Submit the packet to the egress IPv4 FIB lookup for transmission to the new destination
S10.    }
S11. } Else {
S12.    Process as per Section 4.1.1 in RFC8986
S13. }
]]>
</sourcecode>
            </section>


            <section title="End.DT46 with GBP">
<t>When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT46 with GBP SID, N does the following:</t>

<sourcecode type="pseudocode">
    <![CDATA[
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Set the packet's associated FIB table to T
S04.    Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S05.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S06.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S07.    If (Matched){
S08.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S09.    } Else {
S10.        Forward the exposed IPv4 packet to the oIF.
S11.    }
S12. } Else If (Upper-Layer header type == 41(IPv6) ) {
S13.    Remove the outer IPv6 header with all its extension headers
S14.    Set the packet's associated FIB table to T
S15.    Submit the packet to the egress IPv6 FIB lookup and get destination oIF
S16.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S17.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S18.    If (Matched){
S19.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S20.    } Else {
S21.        Forward the exposed IPv6 packet to the oIF.
S22.    }
S23. } Else {
S24.    Process as per Section 4.1.1 in RFC8986
S25. } 
]]>
</sourcecode>

<t>An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.</t>
<sourcecode type="pseudocode">
    <![CDATA[
S01. If (Upper-Layer header type == 4(IPv4) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S04.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S05.    If (Matched){
S06.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S07.    } Else {
S08.        Set the packet's associated FIB table to T
S09.        Submit the packet to the egress IPv4 FIB lookup for transmission to the new destination
S10.    }
S11. } Else If (Upper-Layer header type == 41(IPv6) ) {
S12.    Remove the outer IPv6 header with all its extension headers
S13.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S14.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S15.    If (Matched){
S16.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S17.    } Else {
S18.        Set the packet's associated FIB table to T
S19.        Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination
S20.    }
S21. } Else {
S22.    Process as per Section 4.1.1 in RFC8986
S23. }
]]>
</sourcecode>
            </section>


            <section title="End.DT2U with GBP">
<t>When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DT4 SID, N does the following:</t>

<sourcecode type="pseudocode">
    <![CDATA[
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Learn the exposed MAC Source Address in L2 table T
S04.    Look up the exposed MAC Destination Address in L2 table T
S05.    If (matched entry in T with destination oIF) {
S06.        Search GBP matching table with exposed packet and get Dst-GBP-ID
S07.        Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S08.        If (Matched){
S09.            Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S10.        } Else {
S11.            Forward the exposed packet to oIF
S12.        } 
S13.    } Else {
S14.       Forward via all L2 OIFs in table T
S15.    }
S16. } Else {
S17.    Process as per Section 4.1.1 in RFC8986
S18. }
]]>
</sourcecode>
<t>An implementation which is hardware based might be restricted to the pipeline of the ASCI. The process below is also possible. The difference is that oIF is impossible to be part of the GBP match criteria.</t>
<sourcecode type="pseudocode">
    <![CDATA[
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02.    Remove the outer IPv6 header with all its extension headers
S03.    Learn the exposed MAC Source Address in L2 table T
S04.    Search GBP matching table with exposed packet and get Dst-GBP-ID
S05.    Search GBP enforcement table with Src-GBP-ID and Dst-GBP-ID
S06.    If (Matched){
S07.        Process the exposed IPv6 packet based on the action of match GBP enforcement rule
S08.    } Else {
S09.        Look up the exposed MAC Destination Address in L2 table T
S10.        If (matched entry in T with destination oIF){
S11.            Forward the exposed packet to oIF
S12.        } Else {
S13.       Forward via all L2 OIFs in table T
S14.       }
S15.   } Else {
S16.    Process as per Section 4.1.1 in RFC8986
S17.   }
S18. }
]]>
</sourcecode>
            </section>

        </section>
    <section>
    <name>Source Node Behavior</name>
    <t>The souce node can use various clarification methods to identify the Src-GBP-ID of a host it belongs to.</t>
    <t>When encapsulating the SRv6 header, the Src-GBP-ID is encapsulated into the argument part of the packet.</t>
    </section>
 
    
    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>This document requests the IANA to allocate, within the "SRv6 Endpoint Behaviors" sub-registry beloto the top-level "Segment-routing with IPv6 dataplane (SRv6) Parameters" registry, the following allocations:
      </t>
<table>
    <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
    </thead>
    <tbody>
    <tr>
      <td>TBA1</td>
      <td>END.DX6 with GBP</td>
      <td>[This document]</td>
    </tr>
    <tr>
      <td>TBA2</td>
      <td>END.DX4 with GBP</td>
      <td>[This document]</td>
    </tr>
    <tr>
      <td>TBA3</td>
      <td>END.DT6 with GBP</td>
      <td>[This document]</td>
    </tr>
    <tr>
      <td>TBA4</td>
      <td>END.DT4 with GBP</td>
      <td>[This document]</td>
    </tr>
    <tr>
      <td>TBA4</td>
      <td>END.DT46 with GBP</td>
      <td>[This document]</td>
    </tr>
    <tr>
      <td>TBA4</td>
      <td>END.DT2U with GBP</td>
      <td>[This document]</td>
    </tr>
  </tbody>
</table>

    </section>
    
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>The mechanism described in this document leverage the security rules defined in Section 7 of <xref target="RFC8986">RFC8986</xref>.</t>
    </section>

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
 
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>   

<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>

<reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986">
<front>
<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
<author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<date month="February" year="2021"/>
<abstract>
<t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
<t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
<t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8986"/>
<seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>
            <!--       
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        -->
      </references>
 
      <references>
        <name>Informative References</name>
        <reference anchor="GROUPBASEDPOLICY" target="https://wiki.openstack.org/wiki/GroupBasedPolicy">
          <front>
            <title>Group Based Policy</title>
            <author>
              <organization>OpenStack</organization>
            </author>
            <date year="2015"/>
 
          </front>
        </reference>       
       <reference anchor="RFC7432" target="https://www.rfc-editor.org/info/rfc7432">
<front>
<title>BGP MPLS-Based Ethernet VPN</title>
<author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
<author fullname="N. Bitar" initials="N." surname="Bitar"/>
<author fullname="A. Isaac" initials="A." surname="Isaac"/>
<author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
<author fullname="J. Drake" initials="J." surname="Drake"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
<date month="February" year="2015"/>
<abstract>
<t>This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7432"/>
<seriesInfo name="DOI" value="10.17487/RFC7432"/>
</reference>

<reference anchor="RFC9252" target="https://www.rfc-editor.org/info/rfc9252">
<front>
<title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)</title>
<author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
<author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
<author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
<date month="July" year="2022"/>
<abstract>
<t>This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9252"/>
<seriesInfo name="DOI" value="10.17487/RFC9252"/>
</reference>
      </references>
    </references>

    <section>
      <name>Appendix 1 Examples of GBP Usage</name>
      <t>This section describes the examples of GBP usage. An implementation is not enforced to achieve all scenarios mentioned in this section.</t>
      <t>Example 1: Deny traffic from specific Src-GBP-ID = 100 (e.g. traffic from guest network)</t>
      <t>rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = any, action: deny</t>
      <t>Example 2: Deny traffic from specific Src-GBP-ID = 100 to Dst-GBP-ID = 200 (e.g. traffic from untrusted host to server)</t>
      <t>rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = 200, action: deny</t>
      <t>Example 3: Redirect L3 traffic from specific Src-GBP-ID = 100 to Dst-GBP-ID = 200 (e.g. to a cleaning device)</t>
      <t>rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = 200, action: redirect</t>
      <t>Example 4: RSPAN traffic from specific Src-GBP-ID = 100 to Dst-GBP-ID = 200 (e.g. to a monitoring device)</t>
      <t>rule 1: match Src-GBP-ID = 100 and Dst-GBP-ID = 200, action: RSPAN</t>
    </section>
    <!--
    <section anchor="Acknowledgements" numbered="false">
   [REPLACE/DELETE] an Acknowledgements section is optional 
      <name>Acknowledgements</name>
      <t></t>
    </section>-->
 </back>
</rfc>