<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sfc-nsh-tlv-15" number="9263" submissionType="IETF" category="std" consensus="true" ipr="trust200902" docName="draft-ietf-sfc-nsh-tlv-15">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.5 -->

  <front>
    <title abbrev="NSH MD2 Context Headers">Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers</title>
    <seriesInfo name="RFC" value="9263"/>
    <author fullname="Yuehua Wei" initials="Yuehua" role="editor" surname="Wei"> initials="Y." surname="Wei" role="editor">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street>No.50, Software Avenue</street>
          <city>Nanjing</city>
          <region/>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>wei.yuehua@zte.com.cn</email>
      </address>
    </author>
    <author initials="U." surname="Elzur" fullname="Uri Elzur">
      <organization>Intel</organization>
      <address>
        <email>uri.elzur@intel.com</email>
      </address>
    </author>
    <author initials="S." surname="Majee" fullname="Sumandra Majee">
      <organization>Individual contributor</organization> Contributor</organization>
      <address>
        <email>Sum.majee@gmail.com</email>
      </address>
    </author>
    <author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
      <organization>Cisco</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Eastlake" surname="Eastlake 3rd" fullname="Donald E. Eastlake"> Eastlake, 3rd">
      <organization>Futurewei Technologies</organization>
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
          <city>Apopka</city>
          <region>FL</region>
          <code>32703</code>
			    <country>USA</country>
          <country>United States of America</country>
        </postal>
	<phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
      </address>
    </author>
    <date year="2022"/>

    <area>Routing</area>

    <workgroup>Service Function Chaining Working Group</workgroup> year="2022" month="August"/>
    <area>RTG</area>
    <workgroup>SFC</workgroup>
    <keyword>SFC metadata</keyword>
    <abstract>
      <t>
   Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata metadata (MD) with each packet. Such Metadata metadata can be of various Types types, including MD Type 2 2, consisting of variable length context headers. Variable-Length Context Headers. This document specifies several such context headers Context Headers that can be used within a service function path. Service Function Path (SFP).
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   The Network Service Header (NSH) <xref target="RFC8300"/> target="RFC8300" format="default"/> is the
   Service Function Chaining (SFC) encapsulation that supports the SFC architecture <xref target="RFC7665"/>. target="RFC7665" format="default"/>.  As such, the NSH provides the following key elements:
   <list style="numbers">
   <t>Service
      </t>
      <ol spacing="normal" type="1">
	<li>Service Function Path (SFP) identification.</t>
   <t>Indication identification</li>
        <li>indication of location within a Service Function Path.</t>
   <t>Optional, an SFP</li>
        <li>optional, per-packet metadata (fixed-length or variable-length).</t>
   </list>
 </t> variable-length)</li>
      </ol>
      <t>
    <xref target="RFC8300"/> target="RFC8300" format="default"/> further defines two metadata formats (MD Types): 1 and 2.  MD
   Type 1 defines the fixed-length, 16-octet long metadata, whereas MD Type 2
   defines a variable-length context format for metadata.  This document defines several common metadata context headers Context Headers for use within NSH MD Type 2.
   These supplement the Subscriber Identity Identifier and Performance Policy MD Type 2 metadata context headers Context Headers specified in <xref target="RFC8979"/>. target="RFC8979" format="default"/>.
      </t>
      <t>
      This document does not address metadata usage, updating/chaining of
   metadata, or other SFP functions.  Those topics are described in <xref target="RFC8300"/>. target="RFC8300" format="default"/>.
      </t>
    </section>
    <section title="Conventions used numbered="true" toc="default">
      <name>Conventions Used in this document"> This Document</name>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>This document uses the terminology defined in the SFC Architecture architecture <xref target="RFC7665"/> target="RFC7665" format="default"/> and the Network Service Header NSH <xref target="RFC8300"/>.</t> target="RFC8300" format="default"/>.</t>
      </section>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>
	        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="nsh-t2-format-sec" title="NSH numbered="true" toc="default">
      <name>NSH MD Type 2 format"> Format</name>
      <t>
   An NSH is composed of a 4-octet Base Header, a 4-octet Service Path
   Header
   Header, and optional Context Headers.  The Base Header identifies the MD-Type MD Type
   in use:
      </t>
      <figure align="center" anchor="nsh-base-hdr-fig" title="NSH anchor="nsh-base-hdr-fig">
        <name>NSH Base Header">
          <artwork><![CDATA[ Header</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>
  Please refer to the NSH <xref target="RFC8300"/> target="RFC8300" format="default"/> for a detailed header description.
</t>
      <t>
   When the base header Base Header specifies MD Type = 0x2, zero or more Variable
   Length Variable-Length Context Headers MAY <bcp14>MAY</bcp14> be added, immediately following the
   Service Path Header. <xref target="nsh-tlv-fig"/> target="nsh-tlv-fig" format="default"/> below depicts the format of the Context Header
   as defined in Section 2.5.1 of <xref target="RFC8300"/>. target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>.
      </t>
      <figure align="left" anchor="nsh-tlv-fig" title="NSH anchor="nsh-tlv-fig">
        <name>NSH Variable-Length Context Headers">
   <artwork><![CDATA[ Headers</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Metadata Class       |      Type     |U|    Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Variable-Length Metadata                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
   </t>
    </section>
    <section anchor="nsh-tlvs-sec" title="NSH numbered="true" toc="default">
      <name>NSH MD Type 2 Context Headers"> Headers</name>
      <t>
   <xref target="RFC8300"/> target="RFC8300" format="default"/> specifies Metadata Class 0x0000 as IETF Base NSH MD Class.  In this document, metadata types are defined for the IETF Base NSH MD Class. The Context Headers specified in the subsections below are as follows:
      </t>
	<t>1.
      <ol spacing="normal">
	<li> Forwarding Context</t>
	<t>2. Context</li>
	<li> Tenant Identifier</t>
	<t>3. ID</li>
	<li> Ingress Network Node Information</t>
	<t>4. Information</li>
	<li> Ingress Node Source Interface</t>
	<t>5. Interface</li>
	<li> Flow ID</t>
	<t>6. ID</li>
	<li> Source and/or Destination Groups</t>
	<t>7. Groups</li>
	<li> Policy Identifier</t> ID</li>
      </ol>
      <section anchor="fwd-context-sec" title="Forwarding Context"> numbered="true" toc="default">
        <name>Forwarding Context</name>
        <t>
       This metadata context carries a network forwarding context, used for
       segregation and forwarding scope.
       Forwarding context can take
       several forms depending on the network environment.  For environment, for example, VXLAN/VXLAN-GPE VNID, VRF Virtual
       eXtensible Local Area Network (VXLAN) / Generic Protocol Extension for
	VXLAN (VXLAN-GPE) Virtual Network Identifier (VNID), VPN Routing and Forwarding (VRF) identification, or VLAN. VLAN.</t>
        <figure align="left" anchor="fwd-context-fig1" title="VLAN anchor="fwd-context-fig1">
          <name>VLAN Forwarding Context">
				<artwork><![CDATA[ Context</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA1 0x04  |U|  Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x0 |             Reserved          |        VLAN ID        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <figure align="left" anchor="fwd-context-fig2" title="QinQ anchor="fwd-context-fig2">
          <name>QinQ Forwarding Context">
				<artwork><![CDATA[ Context</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA1 0x04  |U|  Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x1 |Resv   |     Service VLAN ID   |    Customer VLAN ID   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <figure align="left" anchor="fwd-context-fig3" title="MPLS anchor="fwd-context-fig3">
          <name>MPLS VPN Forwarding Context">
				<artwork><![CDATA[ Context</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA1 0x04  |U|  Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x2 |   Reserved    |              MPLS VPN Label           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <figure align="left" anchor="fwd-context-fig4" title="VNI anchor="fwd-context-fig4">
          <name>VNI Forwarding Context">
				<artwork><![CDATA[ Context</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA1 0x04  |U|  Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x3 | Resv  |            Virtual Network Identifier         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <figure align="left" anchor="fwd-context-fig5" title="Session anchor="fwd-context-fig5">
          <name>Session ID Forwarding Context">
			<artwork><![CDATA[ Context</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA1 0x04  |U|  Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x4 |             Reserved                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Session ID                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
       </t>
       <t>
       where:
       <list>
       <t>Context
	  <t>The fields are described as follows:</t>
	    <dl newline="false" spacing="normal">
              <dt>Context Type (CT) is four bits-long (CT):</dt><dd><t>This 4-bit field that defines the interpretation of the Forwarding Context field. Please see the IANA Considerations considerations in <xref target="iana-fc-type"/>. target="iana-fc-type" format="default"/>. This document defines these CT values:
			<list style="simbols">
			<t>0x0 - 12 bits values:</t>
		<dl newline="false" spacing="normal" indent="6">
		  <dt>0x0:</dt> <dd>12-bit VLAN identifier <xref target="IEEE.802.1Q_2018"/>. target="IEEE.802.1Q_2018" format="default"/>. See <xref target='fwd-context-fig1'/>. </t>
			<t>0x1 - 24 bits target="fwd-context-fig1" format="default"/>. </dd>
		  <dt>0x1:</dt> <dd>24-bit double tagging identifiers. A service VLAN tag followed by a customer VLAN tag <xref target="IEEE.802.1Q_2018"/>. target="IEEE.802.1Q_2018" format="default"/>. The two VLAN IDs are concatenated and appear in the same order that they appeared in the payload. See <xref target='fwd-context-fig2'/>.</t>
			<t>0x2 - 20 bits target="fwd-context-fig2" format="default"/>.</dd>
		  <dt>0x2:</dt> <dd>20-bit MPLS VPN label(<xref target="RFC3032"/>)(<xref target="RFC4364"/>). label <xref target="RFC3032" format="default"/> <xref target="RFC4364" format="default"/>. See <xref target='fwd-context-fig3'/>.</t>
			<t>0x3 - 24 bits target="fwd-context-fig3" format="default"/>.</dd>
		  <dt>0x3:</dt> <dd>24-bit virtual network identifier (VNI)<xref target="RFC8926"/>. (VNI) <xref target="RFC8926" format="default"/>. See <xref target='fwd-context-fig4'/>. </t>
			<t>0x4 - 32 bits target="fwd-context-fig4" format="default"/>. </dd>
		  <dt>0x4:</dt> <dd>32-bit Session ID (<xref target="RFC3931"/>). <xref target="RFC3931" format="default"/>. This is called Key in GRE <xref target="RFC2890"/>. target="RFC2890" format="default"/>. See <xref target='fwd-context-fig5'/>.	</t>
			</list>
			Reserved (Resv) target="fwd-context-fig5" format="default"/>.</dd>
		</dl>
	      </dd>
              <dt>Reserved (Resv):</dt><dd>These bits in the context fields MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.
       </t>
       </list>

       </t> receipt.</dd>
	    </dl>

      </section>
      <section anchor="tenant-sec" title="Tenant Identifier"> numbered="true" toc="default">
        <name>Tenant ID</name>
        <t>
       Tenant identification is often used for segregation within a
       multi-tenant environment.  Orchestration system-generated tenant Tenant
       IDs are an example of such data. This context header Context Header carries the value of the Tenant identifier. <xref target="OpenDaylight-VTN"/> ID. Virtual Tenant Network (VTN) <xref target="OpenDaylight-VTN" format="default"/> is an application that provides multi-tenant virtual network networks on an SDN a Software-Defined Networking (SDN) controller.
        </t>
        <figure align="left" anchor="tenant-fig" title="Tenant Identifier List">
          <artwork><![CDATA[ anchor="tenant-fig">
          <name>Tenant ID List</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA2 0x05  |U|    Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         Tenant ID                             ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
       </t>
        <t>The fields are described as follows:
         <list>
         <t>Length: Indicates follows:</t>
        <dl newline="false" spacing="normal">
          <dt>Length:</dt>
	  <dd>Indicates the length of the Tenant ID in octets (see Section 2.5.1 of <xref target="RFC8300"/>).</t>

         <t>Tenant ID: Represents target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
          <dt>Tenant ID:</dt>
	  <dd>Represents an opaque value pointing to Orchestration orchestration system-generated tenant identifier. Tenant ID. The structure and semantics of this field are specific to the operator's deployment across its operational domain, domain and are specified and assigned by an orchestration function. The specifics of that orchestration-based assignment are outside the scope of this document.</t>
	     </list>
	 </t> document.</dd>
        </dl>
      </section>
      <section anchor="ingress-net-nodeid-sec" title="Ingress numbered="true" toc="default">
        <name>Ingress Network Node Information"> Information</name>
        <t>
       This context header Context Header carries a Node ID of the network node at which the packet entered the SFC-enabled domain. This node will necessarily be a Classifier classifier <xref target="RFC7665"/>. target="RFC7665" format="default"/>. In cases where the SPI Service Path Identifier (SPI) identifies the ingress node, this context header Context Header is superfluous.
        </t>
        <figure align="left" anchor="ingress-net-nodeid-fig" title="Ingress anchor="ingress-net-nodeid-fig">
          <name>Ingress Network Node ID">
          <artwork><![CDATA[ ID</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA3 0x06  |U|   Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        Node ID                                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
       </t>
<t>
   The
	  <t>The fields are described as follows:
   <list>
        <t>Length: Indicates follows:</t>
          <dl newline="false" spacing="normal">
          <dt>Length:</dt>
	  <dd>Indicates the length of the Node ID in octets (see Section 2.5.1 of <xref target="RFC8300"/>).</t>

        <t>Node ID: Represents target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
          <dt>Node ID:</dt>
	  <dd>Represents an opaque value of the ingress network node Node ID. The structure and semantics of this field are deployment specific. For example, Node ID may be a 4 octets 4-octet IPv4 address Node ID, or a 16 octets 16-octet IPv6 address Node ID, or a 6 octets 6-octet MAC address, or 8 octets an 8-octet MAC address (EUI-64), etc.</t>
   </list>
</t> (64-bit Extended Unique Identifier (EUI-64)), etc.</dd>
	</dl>
      </section>

      <section anchor="ingress-net-sitf-sec" title="Ingress numbered="true" toc="default">
        <name>Ingress Network Source Interface"> Interface</name>
        <t>This context identifies the ingress interface of the ingress network node. The l2vlan (135), l3ipvlan (136), ipForward (142), and mpls (166) in <xref target="IANAifType"/> target="IANAifType" format="default"/> are examples of source interfaces.
</t>
        <figure align="left" anchor="ingress-net-sitf-fig" title="Ingress anchor="ingress-net-sitf-fig">
          <name>Ingress Network Source Interface">
          <artwork><![CDATA[ Interface</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA4 0x07  |U|    Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                     Source Interface                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
</t>
	    <t>The fields are described as follows:
	<list>
	<t>Length: Indicates follows:</t>
	      <dl newline="false" spacing="normal">
		<dt>Length:</dt>
		<dd>Indicates the length of the Source Interface in octets (see Section 2.5.1 of <xref target="RFC8300"/>).</t>
    <t>Source Interface: Represents target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
		<dt>Source Interface:</dt>
		<dd>Represents an opaque value of the identifier of the ingress interface of the ingress network node.</t>
	</list>
	</t> node.</dd>
              </dl>

      </section>
      <section anchor="flow-id-sec" title="Flow ID"> numbered="true" toc="default">
        <name>Flow ID</name>
        <t>
    Flow ID provides a field in the NSH MD Type 2 to label packets belonging to the same flow. For example, <xref target="RFC8200"/> defined target="RFC8200" format="default"/> defines IPv6 Flow Label as Flow ID, ID. Another example of Flow ID is how <xref target="RFC6790"/> defined target="RFC6790" format="default"/> defines an entropy label which that is generated based on flow information in the MPLS network is another example of Flow ID. network. Absence of this field, field or
    a value of zero denotes that packets have not been labeled with a Flow ID.
</t>
<t>
        <figure align="left" anchor="flow-id-ipv6-fig1" title="IPv6 anchor="flow-id-ipv6-fig1">
          <name>IPv6 Flow ID">
    <artwork><![CDATA[ ID</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA5 0x08  |U| Length = 4  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x0 |   Reserved    |           IPv6 Flow ID                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
</t>
<t>
        <figure align="left" anchor="flow-id-mplse-fig2" title="MPLS entropy label">
    <artwork><![CDATA[ anchor="flow-id-mplse-fig2">
          <name>MPLS Entropy Label</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA5 0x08  |U| Length = 4  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x1 |   Reserved    |        MPLS entropy label             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
</t>
<t>
   The

	  <t>The fields are described as follows:
   <list>
		<t>Length: Indicates follows:</t>

	    <dl newline="false" spacing="normal">
              <dt>Length:</dt>
	      <dd>Indicates the length of the Flow ID in octets (see Section 2.5.1 of <xref target="RFC8300"/>). target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>). For example, the IPv6 Flow Label in <xref target="RFC8200"/> target="RFC8200" format="default"/> is 20-bit 20 bits long. An entropy label in the MPLS network in <xref target="RFC6790"/> target="RFC6790" format="default"/> is also 20-bit 20 bits long. </t>

       <t>Context </dd>
              <dt>Context Type (CT) is four bits-long (CT):</dt><dd><t>This 4-bit field that defines the interpretation of the Flow ID field. Please see the IANA Considerations considerations in <xref target="iana-tlv-flowid-type"/>. target="iana-tlv-flowid-type" format="default"/>. This document defines these CT values:
			<list style="simbols">
			<t>0x0 - 20 bits values:</t>

		<dl newline="false" spacing="normal" indent="6">
		  <dt>0x0:</dt> <dd>20-bit IPv6 Flow Label in <xref target="RFC8200"/>. target="RFC8200" format="default"/>. See <xref target='flow-id-ipv6-fig1'/>. </t>
			<t>0x1 - 20 bits target="flow-id-ipv6-fig1" format="default"/>. </dd>
		  <dt>0x1:</dt> <dd>20-bit entropy label in the MPLS network in <xref target="RFC6790"/>. target="RFC6790" format="default"/>. See <xref target='flow-id-mplse-fig2'/>.</t>
			</list>
			Reserved target="flow-id-mplse-fig2" format="default"/>.</dd>
		</dl>
	      </dd>
              <dt>Reserved:</dt><dd>These bits in the context fields MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.
       </t>
   </list>
</t> receipt.</dd>
	    </dl>

      </section>
      <section anchor="src-dst-group-sec" title="Source numbered="true" toc="default">
        <name>Source and/or Destination Groups"> Groups</name>
        <t>
       Intent-based systems can use this data to express the logical
       grouping of source and/or destination objects.
       <xref target="OpenStack"/> target="OpenStack" format="default"/> and <xref target="OpenDaylight"/> target="OpenDaylight" format="default"/> provide examples of such a
       system. Each is expressed as a 32-bit opaque object.
        </t>
        <figure align="left" anchor="src-dst-group-fig" title="Source/Destination Groups">
          <artwork><![CDATA[ anchor="src-dst-group-fig">
          <name>Source/Destination Groups</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA6 0x09  |U|  Length=8   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Source Group                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Destination Group                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
       </t>
        <t>
If there is no group information specified for the source group Source Group or destination group Destination Group field, the field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.
</t>
      </section>
      <section anchor="policy-id-sec" title="Policy Identifier"> numbered="true" toc="default">
        <name>Policy ID</name>
        <t>
       Traffic handling policies are often referred to by a system-generated identifier, which
       is then used by the devices to look up the policy's content
       locally.  For example, this identifier could be an index to an
       array, a lookup key, or a database Id. ID.  The identifier allows
       enforcement agents or services to look up the content of their
       part of the policy.
        </t>
        <figure align="left" anchor="policy-id-fig" title="Policy ID">
          <artwork><![CDATA[ anchor="policy-id-fig">
          <name>Policy ID</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Metadata Class = 0x0000    |  Type = TBA7 0x0A  |U|    Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                           Policy ID                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
       </t>
<t>
   The
	    <t>The fields are described as follows:
   <list>
        <t>Length: Indicates follows:</t>

	      <dl newline="false" spacing="normal">
		<dt>Length:</dt>
		<dd>Indicates the length of the Policy ID in octets (see Section 2.5.1 of <xref target="RFC8300"/>).</t>

        <t>Policy ID: Represents target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
		<dt>Policy ID:</dt>
		<dd>Represents an opaque value of the Policy ID.</t>
   </list>
</t> ID.</dd>
              </dl>

        <t>
This policy identifier Policy ID is a general policy Policy ID, essentially a key to allow Service Functions (SFs) to know which policies to apply to packets.  Those policies generally will not have much to do with performance, performance but rather with what specific
treatment to apply. It may may, for example example, select a URL filter data set for a URL filter, filter or select a video transcoding policy in a transcoding SF. The Performance Policy Identifier ID in <xref target="RFC8979"/> target="RFC8979" format="default"/> is described there as having very specific use, and use and, for example example, says that fully controlled SFPs would not use it. The Policy ID in this document is for cases not covered by <xref target="RFC8979"/>. target="RFC8979" format="default"/>.

</t>
      </section>
    </section>
    <section anchor="security-sec" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>A misbehaving node from within the SFC-enabled domain may alter the content of the Context Headers, which may lead to service disruption. Such an attack is not unique to the Context Headers defined in this document. Measures discussed in Section 8 of <xref target="RFC8300"/> target="RFC8300" section="8" sectionFormat="of" format="default"/> describes the general security considerations for protecting the NSH. <xref target="I-D.ietf-sfc-nsh-integrity"/> target="RFC9145" format="default"/> specifies methods of protecting the integrity of the NSH metadata. If the NSH includes the MAC Message Authentication Code (MAC) and Encrypted Metadata Context Header <xref target="RFC9145"/>, target="RFC9145" format="default"/>, the authentication of the packet MUST <bcp14>MUST</bcp14> be verified before using any data. If the verification fails, the receiver MUST <bcp14>MUST</bcp14> stop processing the variable length context headers Variable-Length Context Headers and notify an operator.
</t>
      <t>The security and privacy considerations for the 7 types of context header Context Headers specified above are discussed below. Since NSH ignorant NSH-ignorant SFs will never see the NSH, then even if they are malign, they cannot compromise security or privacy based on the NSH or any of these context headers, although Context Headers; however, they could cause compromise based on the rest of the packet. To the extent that any of these headers is are included when it they would be unneeded or have no effect, they provide a covert channel for the entity adding the context header Context Header to communicate a limited amount of arbitrary information to downstream entities within the SFC-enabled domain.</t>
      <section title="Forwarding Context"> numbered="true" toc="default">
        <name>Forwarding Context</name>
        <t>All of the Forwarding Context variants specified in this document (those with CT values between 0 and 4) merely repeat a field that is available in the packet encapsulated by the NSH. These variants repeat that field in the NSH for convenience. Thus, there are no special security or privacy considerations in these cases. Any future new values of CT for the Forwarding Context must specify the security and privacy considerations for those extensions.
</t>
      </section>
      <section title="Tenant Identifier"> numbered="true" toc="default">
        <name>Tenant ID</name>
        <t>The Tenant ID indicates the tenant to which traffic belongs and might be used to tie together and correlate packets for a tenant that some monitoring function could not otherwise group group, especially if other possible identifiers were being randomized. As such, it may reduce security by facilitating traffic analysis but only within the SFC-enabled domain where this context header Context Header is present in packets.
</t>
      </section>
      <section title="Ingress numbered="true" toc="default">
        <name>Ingress Network Node Information"> Information</name>
        <t>The SFC-enabled domain manager normally operates the initial ingress / classifier ingress/classifier node and is thus potentially aware of the information provided by this context header. Context Header. Furthermore, in many cases cases, the SPI that will be present in the NSH identifies or closely constrains the ingress node. Also, in most cases, it is anticipated that many entities will be sending packets into an SFC-enabled domain through the same ingress node. Thus, under most circumstances, this context header Context Header is expected to weaken security and privacy to only a minor extent and only within the SFC-enabled domain.
</t>
      </section>
      <section title="Ingress numbered="true" toc="default">
        <name>Ingress Node Source Interface"> Interface</name>
        <t>This context header Context Header is likely to be meaningless unless the Ingress Network Node Information context header Context Header is also present. When that node information header is present, this source interface header provides a more fine-grained view of the source by identifying not just the initial ingress / classifier ingress/classifier node but also the port of that node on which the data arrived. Thus, it is more likely to identify a specific source entity or at least to more tightly constrain the set of possible source entities, entities than just the node information header. As a result, inclusion of this context header Context Header with the node information context header Context Header is potentially a greater threat to security and privacy than the node information header alone alone, but this threat is still constrained to the SFC-enabled domain.</t>
      </section>
      <section title="Flow ID"> numbered="true" toc="default">
        <name>Flow ID</name>
        <t>The variations of this context header Context Header specified in this document simply repeat fields already available in the packet and thus have no special security or privacy considerations. Any future new values of CT for the Flow ID must specify the security and privacy considerations for those extensions.
</t>
      </section>
      <section title="Source numbered="true" toc="default">
        <name>Source and/or Destination Groups"> Groups</name>
        <t>This context header Context Header provides additional information that might help identify the source and/or destination of packets. Depending on the granularity of the groups, it could either (1) distinguish packets as part of flows from and/or to objects where those flows could not otherwise be easily distinguished but appear to be part of one or fewer flows or (2) group packet flows that are from and/or to an object where those flows could not otherwise be easily grouped for analysis or whatever. another purpose.
Thus, the presence of this context header Context Header with non-zero source and/or destination groups can, within the SFC-enabled domain, erode security and privacy to an extent that depends on the details of the grouping.
</t>
      </section>
      <section title="Policy Identifier"> numbered="true" toc="default">
        <name>Policy ID</name>
        <t>
This context header Context Header carries an identifier that nodes in the SFC-enabled domain can use to look up policy to potentially
influence their actions with regard to the packet carrying this header. If there are no such action decisions, decisions regarding their actions, then the header should not be included. If there are such decisions, the information on which they are to be based needs to be included somewhere in the packet. There is no reason for inclusion in this context header Context Header to have any security or privacy considerations that would not apply to any other plaintext way of including such information. It may provide additional information to help identify a flow of data for analysis.
</t>
      </section>
    </section>
    <section title="Acknowledgments">
	<t>
	The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von Hugo, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for providing invaluable concepts and content for this document.
	</t>
</section>

<section anchor="iana-tlv-class-reg-sec" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="iana-tlv-class-context-type" title="MD numbered="true" toc="default">
        <name>MD Type 2 Context Types"> Types</name>
        <t>
	IANA is requested to assign has assigned the following types (<xref target="type-values-tbl"/>) target="type-values-tbl" format="default"/>) from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry available at <xref target="IANA-NSH-MD2"/>. target="IANA-NSH-MD2" format="default"/>.
        </t>
		<texttable
        <table anchor="type-values-tbl" title="Type Values">
			<ttcol align="left">Value</ttcol>
			<ttcol align="center">Description</ttcol>
			<ttcol align="left">Reference</ttcol>
			<c>TBA1</c>
			<c>Forwarding Context</c>
			<c>This&nbsp;document</c>
			<c>TBA2</c>
			<c>Tenant Identifier</c>
			<c>This&nbsp;document</c>
			<c>TBA3</c>
			<c>Ingress align="center">
          <name>Type Values</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="center">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x04</td>
              <td align="center">Forwarding Context</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x05</td>
              <td align="center">Tenant ID</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x06</td>
              <td align="center">Ingress Network NodeID</c>
			<c>This&nbsp;document</c>
			<c>TBA4</c>
			<c>Ingress Node ID</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x07</td>
              <td align="center">Ingress Network Interface</c>
			<c>This&nbsp;document</c>
			<c>TBA5</c>
			<c>Flow ID</c>
			<c>This&nbsp;document</c>
			<c>TBA6</c>
			<c>Source Interface</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x08</td>
              <td align="center">Flow ID</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x09</td>
              <td align="center">Source and/or Destination Groups</c>
			<c>This&nbsp;document</c>
			<c>TBA7</c>
			<c>Policy Identifier</c>
			<c>This&nbsp;document</c>
		</texttable> Groups</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x0A</td>
              <td align="center">Policy ID</td>
              <td align="left">RFC 9263</td>
            </tr>
          </tbody>
        </table>
      </section>

	<!-- Add forwarding context Type sub-registry -->
	<section anchor="iana-fc-type" title="Forwarding numbered="true" toc="default">
        <name>Forwarding Context Types"> Types</name>
        <t>IANA is requested to create has created a new sub-registry subregistry for "Forwarding Context" context types Context Types"  at <xref target="IANA-NSH-MD2"/> target="IANA-NSH-MD2" format="default"/> as follows: follows.
        </t>
        <t>The Registration Policy registration policy is IETF Review</t>
		<texttable Review.</t>
        <table anchor="Forwarding-CT-iana-tbl" title="Forwarding Context Types">
			<ttcol align="left">Value</ttcol>
			<ttcol align="center">Forwarding align="center">
          <name>Forwarding Context Header Types</ttcol>
			<ttcol align="left">Reference</ttcol>
			<c>0x0</c>
			<c>12-bit Types</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="center">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x0</td>
              <td align="center">12-bit VLAN identifier</c>
			<c>This&nbsp;document</c>
			<c>0x1</c>
			<c>24-bit identifier</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x1</td>
              <td align="center">24-bit double tagging identifiers</c>
			<c>This&nbsp;document</c>
			<c>0x2</c>
			<c>20-bit identifiers</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x2</td>
              <td align="center">20-bit MPLS VPN label</c>
			<c>This&nbsp;document</c>
			<c>0x3</c>
			<c>24-bit label</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x3</td>
              <td align="center">24-bit virtual network identifier (VNI)</c>
			<c>This&nbsp;document</c>
			<c>0x4</c>
			<c>32-bit (VNI)</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x4</td>
              <td align="center">32-bit Session ID</c>
			<c>This&nbsp;document</c>
			<c>0x5-0xE</c>
			<c>Unassigned</c>
			<c></c>
			<c>0xF</c>
			<c>Reserved</c>
			<c>This&nbsp;document</c>
			</texttable> ID</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x5-0xE</td>
              <td align="center">Unassigned</td>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left">0xF</td>
              <td align="center">Reserved</td>
              <td align="left">RFC 9263</td>
            </tr>
          </tbody>
        </table>
      </section>
	<!-- end of	forwarding context Type sub-registry  -->

	<!-- Add flow id context Type sub-registry -->
	<section anchor="iana-tlv-flowid-type" title="Flow numbered="true" toc="default">
        <name>Flow ID Context Types"> Types</name>
        <t>IANA is requested to create has created a new sub-registry subregistry for "Flow ID Context" context types Context Types" at <xref target="IANA-NSH-MD2"/> target="IANA-NSH-MD2" format="default"/> as follows: follows.
        </t>
        <t>The Registration Policy registration policy is IETF Review</t>
		<texttable Review.</t>
        <table anchor="flow-id-CT-iana-tbl" title="Flow ID Context Types">
			<ttcol align="left">Value</ttcol>
			<ttcol align="center">Flow align="center">
          <name>Flow ID Context Header Types</ttcol>
			<ttcol align="left">Reference</ttcol>
			<c>0x0</c>
			<c>20-bit Types</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="center">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x0</td>
              <td align="center">20-bit IPv6 Flow Label</c>
			<c>This&nbsp;document</c>
			<c>0x1</c>
			<c>20-bit Label</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x1</td>
              <td align="center">20-bit entropy label in the MPLS network</c>
			<c>This&nbsp;document</c>
			<c>0x2-0xE</c>
			<c>Unassigned</c>
			<c></c>
			<c>0xF</c>
			<c>Reserved</c>
			<c>This&nbsp;document</c>
			</texttable> network</td>
              <td align="left">RFC 9263</td>
            </tr>
            <tr>
              <td align="left">0x2-0xE</td>
              <td align="center">Unassigned</td>
              <td align="left"/>
            </tr>
            <tr>
              <td align="left">0xF</td>
              <td align="center">Reserved</td>
              <td align="left">RFC 9263</td>
            </tr>
          </tbody>
        </table>
      </section>
	<!-- end of	flowid context Type sub-registry  -->

</section>
  </middle>
  <back>
    <references title="Normative References">

		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.3931"?>
		<?rfc include="reference.RFC.8174"?>

		<?rfc include="reference.RFC.8300"?>
		<?rfc include="reference.RFC.9145"?>
		<?rfc include='reference.I-D.ietf-sfc-nsh-integrity'?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9145.xml"/>

        <reference anchor="IEEE.802.1Q_2018" target="http://ieeexplore.ieee.org/servlet/opac?punumber=8403925" > target="https://ieeexplore.ieee.org/document/8403927">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges Network -- Bridges and Bridged Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="July" year="2018"/>
          </front>
        </reference>

        <reference anchor="IANA-NSH-MD2" target="https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types"> target="https://www.iana.org/assignments/nsh">
          <front>
            <title>
				NSH IETF-Assigned Optional Variable-Length Metadata Types
		Network Service Header (NSH) Parameters
            </title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
        </front>
		</reference>

<!--
		<reference anchor="IANA-NSH-MD4">
			<front>
				<title>NSH IETF-Assigned Optional Variable-Length Metadata Types</title>
				<author>
					<organization>IANA</organization>
				</author>
				<date/>
          </front>
			<format type="https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types"/>
        </reference>
-->

    </references>

    <references title="Informative References">
		<?rfc include="reference.RFC.8200"?>
		<?rfc include="reference.RFC.6790"?>
		<?rfc include="reference.RFC.8979"?>
		<?rfc include="reference.RFC.2890"?>
		<?rfc include="reference.RFC.7665"?>
        <?rfc include="reference.RFC.8926"?>
		<?rfc include="reference.RFC.3032"?>
        <?rfc include="reference.RFC.4364"?>
      <references>
        <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8979.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>

<reference anchor="OpenDaylight-VTN" target="https://nexus.opendaylight.org/content/sites/site/org.opendaylight.docs/master/userguide/manuals/userguide/bk-user-guide/content/_vtn.html">
          <front>
            <title>OpenDaylight VTN</title>
            <author>
              <organization>OpenDaylight</organization>
            </author>
            <date year="2021"/>
          </front>
        </reference>

        <reference anchor="IANAifType" target="https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib">
          <front>
				<title>IANAifType</title>
            <title>IANAifType-MIB DEFINITIONS</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date year="2021"/>
          </front>
        </reference>

        <reference anchor="OpenStack" target="https://wiki.openstack.org/wiki/GroupBasedPolicy">
          <front>
				<title>Group Based Policy</title>
            <title>GroupBasedPolicy</title>
            <author>
              <organization>OpenStack</organization>
            </author>
            <date year="2021"/>
          </front>
			<!--<format type="https://wiki.openstack.org/wiki/GroupBasedPolicy"/>-->
		</reference>

        <reference anchor="OpenDaylight" target="https://docs.opendaylight.org/en/stable-fluorine/user-guide/group-based-policy-user-guide.html?highlight=group%20policy#">
          <front>
            <title>Group Based Policy</title> Policy User Guide</title>
            <author>
              <organization>OpenDaylight</organization>
            </author>
            <date year="2021"/>
          </front>
			<!--<format type="https://docs.opendaylight.org/en/stable-fluorine/user-guide/group-based-policy-user-guide.html?highlight=group%20policy#"/>-->
		</reference>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
	The authors would like to thank <contact fullname="Paul Quinn"/>, <contact fullname="Behcet Sarikaya"/>, <contact fullname="Dirk von Hugo"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Gregory Mirsky"/>, and <contact fullname="Joel Halpern"/> for providing invaluable concepts and content for this document.
      </t>
    </section>
  </back>
</rfc>