<?xml version="1.0" encoding="US-ASCII"?>
<!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"?>
<rfc category="std" docName="draft-wang-lsr-hbh-process-00"
     ipr="trust200902">
  <front>
    <title abbrev="draft-wang-lsr-hbh-process-00"> 
	IGP Extensions for Advertising Hop-by-Hop Options Header Processing Action</title>

    <author fullname="Yali Wang" initials="Y." surname="Wang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>wangyali11@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhoutianran@huawei.com</email>

        <uri/>
      </address>
    </author>
	
	<author fullname="Zhibo Hu" initials="Z." surname="Hu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>huzhibo@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="29" month="October" year="2020"/>

    <workgroup>Link State Routing Working Group</workgroup>

    <abstract>
		<t>This document extends Node and Link attribute TLVs to Interior Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header processing action and supported services (e.g. IOAM Trace Option and Alternate Marking) at node and link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether the Hop-by-Hop Options header and specific services can be supported in a given network.</t>
    </abstract>

    <note title="Requirements Language">
		<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">	
		<t><xref target="RFC8200"/> specifies IPv6 extension headers, including Hop-by-Hop Options header, Destination Options header, Routing header, etc. An IPv6 packet may carry zero, one, or more extension headers that must be processed strictly in the order they appear in the packet. Except for the Hop-by-Hop Options header, other extension headers are not processed, inserted, or deleted by any transit node along a packet's delivery path, until the packet arrives at the Destination node.</t> 
		
		<t>As specified in <xref target="RFC8200"/>, although the Hop-by-Hop Options header is not inserted or deleted by any transit node along a packet's delivery path, it is only examined and processed by nodes along a packet's delivery path if they are explicitly configured to process. Besides, nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. In the results, devices of different vendors can be configured to process the Hop-by-Hop Options header in different ways.</t>
	
		<t>Until now, the Hop-by-Hop Options header has been widely used. In-situ Operations, Administration, and Maintenance (IOAM) data fields are encapsulated in two types of extension headers in IPv6 packets, either Hop-by-Hop Options header or Destination Options header, depending on IOAM usage <xref target="I-D.ietf-ippm-ioam-ipv6-options"/>. For example, IOAM-tracing options are represented as an IPv6 options in Hop-by-Hop extension header. Similarly, the Alternate Marking technique can be carried by the Hop-by-Hop Options header and the Destination Options header <xref target="I-D.ietf-6man-ipv6-alt-mark"/>. If nodes are not explicitly configured to process the Hop-by-Hop Option header, they should ignore them. In this case, the performance measurement does not account for all links and nodes along a path. Therefore, such advertisement can be useful for entities (e.g., the centralized controller) to determine whether a specific service can be implemented in IPv6 netowrk by encoding in the Hop-by-Hop Options header.</t>
		
		<t>BGP-LS defines a way to advertise topology and associated attributes and capabilities of the nodes in that topology to a centralized controller <xref target="RFC7752"/>. Typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. In order for BGP-LS to signal the processing action of the Hop-by-Hop Options header for all the devices in the network, the processing action SHOULD be advertised by every IGP router in the network.</t>
		
		<t>This document defines a mechanism to signal the configured processing action of the Hop-by-Hop Options header and supported services at node and/or link granularity using IS-IS, OSPFv2 and OSPFv3.</t>
    </section>
	
	<section title="Terminology">
		<t>Following are abbreviations used in this document:</t>
		<t><list style="symbols">
		<t>IGP: Interior Gateway Protocols</t>
		<t>IS-IS: Intermediate System to Intermediate System</t>
		<t>OSPF: Open Shortest Path First</t>
		<t>BGP-LS: Border Gateway Protocol - Link State</t>
		<t>NLRI: Network Layer Reachability Information</t>
	    </list></t>
	</section>


	<section title="Hop-by-Hop Options Header Processing Action">		
		<t>This document defines the information of processing action formed of a tuple of a 1-octet Extension Header Options identifier and 8-bit Processing Action Flag.</t>
			
		<t><figure align="center"
            title="Fig. 1 Processing Action Format">
			<artwork><![CDATA[
 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
+---------------+-------------------------------+---------------+
|  Action Flag  |          Services Flag        |  Max EH Len   |
+---------------+-------------------------------+---------------+
]]></artwork>
			</figure>Where:</t>
			<t><list style="symbols">
			
			<t>Action Flag: A 8-bit field. The highest-order 3-bit indicates the processing action, i.e., 000 - drop packets; 001 - dispatch to control plane; 010 - forward, skip to Next Header; 011 - forward, ignoring all extension Options header; 100 - examine and process.</t>
			
			<t>Max EH Len: A one octet field. The maximum length of the Extension Header in 8-octet units can be examined and processed at node or link granularity. The definition is same as the Next Header Length in <xref target="RFC8200"/>.</t>
			
			<t>Services Flag: A 16-bit bitmap. The format is defined as follows.</t>
			
			</list></t>

			<t><figure align="center"
            title="Fig. 2 Services Flag Format">
			<artwork><![CDATA[
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
+-------------------------------+
|O|A|          Reserved         |
+-------------------------------+
]]></artwork>
			</figure>where fields are defined as the following:</t>
			<t><list style="symbols">
			
			<t>O (IOAM Trace Option) is a one-bit flag. The O flag is set to 1 if the IOAM Trace Option is supported at node or link granularity.</t>
			
			<t>A (Alternate Marking) is a one-bit flag. The A flag is set to 1 if the Alternate Marking method is supported at node or link granularity.</t>
			
			<t>R - reserved bits for future use. These flags MUST be zeroed on transimit and ignored on receipt.</t>
			</list></t>

		
			<t>In this document, the processing action at link granularity is defined as the supported the Hop-by-Hop Options header processing action of the interface associated with the link. When all interfaces associated with links support the same processing action, the processing action at node granularity SHOULD represent the Link processing action. Both of Node and Link processing action information are formed of a tuple of a 1-octet Extension Header Options identifier and 8-bit Processing Action Flag.</t>
		
			<t>When both of Node and Link processing action are advertised, the Link processing action information MUST take precedence over the Node processing action. Besides, when a Link processing action is not signaled, then the Node processing action SHOULD be considered to be the processing action for this link.</t>
	</section>

	
	<section title="Signaling Processing Action Using IS-IS">
		<t>The IS-IS Extensions for advertising Router Information TLV named IS-IS Router CAPABILITY TLV <xref target="RFC7981"/>, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.</t>
		
		<section title="IS-IS Node Processing-Action Sub-TLV">
			<t>According to the format of IS-IS Router CAPABILITY TLV <xref target="RFC7981"/>, the Node Processing-Action sub-TLV within the body of the IS-IS router CAPABILITY TLV is composed of three fields, a one-octet Type field, a one-octet Length field, and a 4-octet Value field. The following format is used:</t>

			<t><figure align="center"
            title="Fig. 3 IS-IS Node Processing-Action Sub-TLV Format">
            <artwork><![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
+---------------+---------------+
|      Type     |    Length     |
+---------------+---------------+-------------------------------+
|                    Node-Processing-Action                     |
+---------------------------------------------------------------+
]]></artwork>
          </figure>Where:</t>
			<t><list style="symbols">
			<t>Type: To be assigned by IANA</t>

			<t>Length: A one-octet field that indicates the length of the value portion in octets. </t>
		
			<t>Node-Processing-Action: A 4-octet field, which is same as defined in Section 3.</t>
			</list></t>
		</section>
	
		<section title="IS-IS Link Processing-Action Sub-TLV">
			<t>The Link Processing-Action sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
			223 to carry the Processing-Action information of the interface associated with the link. The Link Processing-Action sub-TLV is formed of three fields, a one-octet Type field, a one-octet Length field, and a 4-octet Value field. The following format is used:</t>
		
			<t><figure align="center"
            title="Fig. 4 IS-IS Link Processing-Action Sub-TLV Format">
            <artwork><![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
+---------------+---------------+
|      Type     |    Length     |
+---------------+---------------+-------------------------------+
|                     Link-Processing-Action                    |
+---------------------------------------------------------------+
]]></artwork>
          </figure>Where:</t>
			<t><list style="symbols">
			<t>Type: To be assigned by IANA</t>

			<t>Length: A one-octet field that indicates the length of the value portion in octets. </t>
		
			<t>Link-Processing-Action: A 4-octet field, which is same as defined in Section 3.</t>
			</list></t>
		</section>
	</section>
	
	<section title="Signaling Processing Action Using OSPF">
		<t>Given that OSPF uses the options field in LSAs and hello packets to advertise optional router capabilities <xref target="RFC7770"/>, this document defines a new Node Processing-Action TLV within the body of the OSPF RI Opaque LSA <xref target="RFC7770"/> to carry the Processing Action of the router originating the RI LSA.</t>
	  
		<t>This document defines the Link Processing-Action sub-TLV to carry the Processing-Action information of the interface associated with the link. For OSPFv2, the link-level Processing-Action information is advertised as a sub-TLV of the OSPFv2 Extended Link TLV as defined in <xref target="RFC7684"/>. For OSPFv3, the link-level Processing-Action information is advertised a sub-TLV of the E-Router-LSA TLV as defined in <xref target="RFC8362"/>.</t>
	  
		<section title="OSPF Node Processing-Action TLV">
			<t>The Node Processing-Action TLV is composed of three fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet Value field. The following format is used:</t>
		
			<t><figure align="center"
            title="Fig. 5 OSPF Node Processing-Action TLV">
            <artwork><![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
+-------------------------------+-------------------------------+
|               Type            |            Length             |
+---------------------------------------------------------------+
|                     Node-Processing-Action                    |
+---------------------------------------------------------------+

]]></artwork>
          </figure>Where:</t>
		  <t><list style="symbols">
			<t>Type: To be assigned by IANA</t>

			<t>Length: A 2-octet field that indicates the length of the value field. </t>

			<t>Node-Processing-Action: A 4-octet field, which is as defined in Section 3.</t>
		  </list></t>
		</section>
	
		<section title="OSPFv2 Link Processing-Action sub-TLV">
			<t>The Link Processing-Action sub-TLV encoded in the OSPFv2 Extended Link TLV as defined in <xref target="RFC7684"/>, which is constructed of three fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet Value field. The following format is used:</t>
		
			<t><figure align="center"
            title="Fig. 6 OSPFv2 Link Processing-Action sub-TLV">
            <artwork><![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
+-------------------------------+-------------------------------+
|               Type            |            Length             |
+---------------------------------------------------------------+
|                     Link-Processing-Action                    |
+---------------------------------------------------------------+

]]></artwork>
          </figure>Where:</t>
		  <t><list style="symbols">
			<t>Type: To be assigned by IANA</t>

			<t>Length: A 2-octet field that indicates the length of the value field. </t>

			<t>Link-Processing-Action: A 4-octet field, which is as defined in Section 3.</t>
		  </list></t>
		</section>
	
		<section title="OSPFv3 Link Processing-Action Sub-TLV">
			<t>The Link Processing-Action sub-TLV encoded in the OSPFv3 E-Router-LSA TLV as defined in <xref target="RFC8362"/>, which is constructed of three fields, a 2-octet Type field, a 2-octet Length field, and a 4-octet Value field. The following format is used:</t>
		
			<t><figure align="center"
            title="Fig. 7 OSPFv3 Link Processing-Action sub-TLV">
            <artwork><![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
+-------------------------------+-------------------------------+
|               Type            |            Length             |
+---------------------------------------------------------------+
|                     Link-Processing-Action                    |
+---------------------------------------------------------------+

]]></artwork>
			</figure>Where:</t>
			<t><list style="symbols">
			<t>Type: To be assigned by IANA</t>

			<t>Length: A 2-octet field that indicates the length of the value field. </t>

			<t>Link-Processing-Action: A 4-octet field, which is as defined in Section 3.</t>
			</list></t>
		</section>
	</section>


    <section anchor="IANA" title="IANA Considerations">
        <t>IANA is requested to allocate values for the following new TLV and sub-TLVs.</t>

        <texttable align="center">
          <ttcol>Type</ttcol>

          <ttcol>Description</ttcol>

          <c>TBA</c>

          <c>IS-IS Node Processing-Action Sub-TLV</c>
		  
		  <c>TBA</c>

          <c>IS-IS Link Processing-Action Sub-TLV</c>
        </texttable>
		
		
		<texttable align="center">
          <ttcol>Type</ttcol>

          <ttcol>Description</ttcol>

          <c>TBA</c>

          <c>OSPF Node Processing-Action TLV</c>
		  
		  <c>TBA</c>

          <c>OSPFv2 Link Processing-Action sub-TLV</c>
		  
		  <c>TBA</c>

          <c>OSPFv3 Link Processing-Action sub-TLV</c>
        </texttable>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document introduces new IGP Node and Link Attribute TLVs and sub-TLVs for dvertising processing actions of the Hop-by-Hop Options header at node and/or link granularity. It does not introduce any new security risks to IS-IS, OSPFv2 and OSPFv3.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <reference anchor="RFC7770"
                 target="https://www.rfc-editor.org/info/rfc7770">
        <front>
          <title>Extensions to OSPF for Advertising Optional Router Capabilities</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	  <reference anchor="RFC7684"
                 target="https://www.rfc-editor.org/info/rfc7684">
        <front>
          <title>OSPFv2 Prefix/Link Attribute Advertisement</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	  <reference anchor="RFC8362"
                 target="https://www.rfc-editor.org/info/rfc8362">
        <front>
          <title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	  <reference anchor="RFC7981"
                 target="https://www.rfc-editor.org/info/rfc7981">
        <front>
          <title>IS-IS Extensions for Advertising Router Information</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	  <reference anchor="RFC7752"
                 target="https://datatracker.ietf.org/doc/rfc7752/">
        <front>
          <title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	  <reference anchor="RFC8200"
                 target="https://datatracker.ietf.org/doc/rfc8200/">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) Specification</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	</references>

    <references title="Informative References">
      <reference anchor="I-D.ietf-6man-ipv6-alt-mark"
                 target="https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/">
        <front>
          <title>IPv6 Application of the Alternate Marking Method</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
	  <reference anchor="I-D.ietf-ippm-ioam-ipv6-options"
                 target="https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/">
        <front>
          <title>In-situ OAM IPv6 Options</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
	  
    </references>
  </back>
</rfc>
