<?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-idr-bgp-ls-ifit-node-capability-01"
     ipr="trust200902">
  <front>
    <title abbrev="draft-wang-idr-bgp-ls-ifit-node-capability-01">Extensions to BGP-LS
     for Advertising IFIT Node Capability</title>

    <author fullname="Yali Wang" initials="Y." role="editor" 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." role="editor" 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="Ran Pang" initials="R." role="editor" surname="Pang">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street>9 Shouti South Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>pangran@chinaunicom.com</email>

        <uri/>
      </address>
    </author>

    <date day="09" month="March" year="2020"/>

    <workgroup>Interdomain Routing Working Group</workgroup>

    <abstract>
      <t> This document defines a way for an a Border Gateway Protocol Link-State (BGP-LS) speaker to announce IFIT node capabilities of routers to BGP-LS consumer. In this document, IFIT Node Capability TLV is defined as a new Node Attribute TLV that is encoded in the BGP-LS attribute with Node NLRIs <xref target="RFC7752"/>. Such advertisements enable IFIT applications in an operational network domain.</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>IFIT provides a complete framework architecture and a reflection-loop
      working solution for on-path flow telemetry <xref
      target="I-D.song-opsawg-ifit-framework"/>. At present, there are a
      family of emerging on-path flow telemetry techniques, including In-situ
      OAM (IOAM) <xref target="I-D.ietf-ippm-ioam-data"/>, PBT <xref
      target="I-D.song-ippm-postcard-based-telemetry"/> , IOAM Direct Export
      (DEX) <xref target="I-D.ioamteam-ippm-ioam-direct-export"/> , Enhanced Alternate Marking (EAM) <xref target="I-D.zhou-ippm-enhanced-alternate-marking"/>, etc. 
	  IFIT is a solution focusing on network domains. The "network domain" consists of a set of network devices
      or entities within a single administration. For example, a network
      domain can be one or more IGP routing domains. 
	  The family of emerging on-path flow telemetry techniques may be selectively or partially implemented in different vendors' devices as an emerging feature for various use cases of application-aware network operations.
	  Hence, in order to enable IFIT applications in an operational network domain, IFIT node capabilities SHOULD be advertised by every Intermediate System to Intermediate System (IS-IS) router in the network domain.</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"/>. This document defines extensions to BGP-LS to advertise the IFIT node capabilities to BGP-LS consumers.</t>
	  
	  <section title="Terminology">
	    <t>BGP-LS: Advertisement of Link-State and TE Information using Border Gateway Protocol</t>
	  </section>
    </section>

    <section title="Concepts">

      <section title="IFIT Domain">
        <t>IFIT is expected to be deployed in a specific domain referred as the IFIT domain. An IFIT domain may cross multiple 
		network domains. One network domain may consists of multiple IFIT domain. 
		Within the IFIT domain, the IFIT data
        fields of flow information head MAY be updated by network nodes that the packet traverses.</t>
      </section>
	  
	  <section title="IFIT Node Capability Information">
        <t>Each IFIT node is configured with a node-id which uniquely identifies a node within the associated IFIT domain. 
		To accommodate the different use cases or requirements of in-situ flow
        information telemetry, IFIT data fields updated by network nodes fall into different categories
        which are referred as different IFIT option types, including IOAM Trace Option-Types <xref target="I-D.ietf-ippm-ioam-data"/>, IOAM Edge-to-Edge (E2E) Option-Type <xref target="I-D.ietf-ippm-ioam-data"/>, IOAM DEX Option-Type <xref target="I-D.ioamteam-ippm-ioam-direct-export"/> and Enhanced Alternate Marking (EAM) Option-Type <xref target="I-D.zhou-ippm-enhanced-alternate-marking"/>. So IFIT Option Types SHOULD be carried in IFIT node capability advertisment.
        </t>
      </section>
    </section>

    <section title="Advertisement of the IFIT Node Capabilities via BGP-LS">
	  <t>This document describes extensions enabling BGP-LS speakers to announce the IFIT node capabilities of routers in a network to a BGP-LS consumer (e.g. a centralized controller). The centralized controller can leverage this information in enabling IFIT applications in network domains based on IFIT node capabilities and OAM use cases. 
	  </t>

      <section title="IFIT Node Capability TLV">
        <t>IFIT Node-Capability TLV is defined as a new Node Attribute TLV that is encoded in the BGP-LS attribute with Node NLRIs <xref target="RFC7752"/>. The IFIT Node Capability TLV is defined as a TLV triplet, i.e. a
        two-octet Type field, a two-octet Length field, and 4-octet Value field. 
		The Type field indicates the type of items in the
        Value field. The Length field indicates the length of the Value field
        in octets. The Value field indicates the IFIT Node Capability, which is a 4-octet IFIT Option Type-enabled Flag bitmap.</t>
		
        <t>The IFIT Node capability TLV has the following format: </t>

        <t><figure align="center"
            title="Fig. 1 IFIT Node Capability 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             |
    +---------------------------------------------------------------+
    |                 IFIT Option Type-enabled Flag                 |
    +---------------------------------------------------------------+

]]></artwork>
          </figure></t>

        <t>Type: To be assigned by IANA</t>

        <t>Length: A 8-bit field that indicates the length of the value
        portion in octets and will be a multiple of 4 octets dependent on the
        number of capabilities advertised. </t>

        <t>IFIT Option Type-enabled Flag: A 4-octet field, which is defined as following:</t>
		
        <t><figure>
            <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
     +---------------------------------------------------------------+
     |p|i|d|e|m|                       Reserved                      |
     +---------------------------------------------------------------+

]]></artwork>
          </figure>Where: </t>

        <t>p-Flag: IOAM Pre-allocated Trace Option Type-enabled flag. If p bit is set (1), the router is capable of IOAM Pre-allocated Trace <xref target="I-D.ietf-ippm-ioam-data"/>.</t>

        <t>i-Flag: IOAM Incremental Trace Option Type-enabled flag. If i bit is set (1), the router is capable of IOAM Incremental Tracing <xref target="I-D.ietf-ippm-ioam-data"/>.</t>

        <t>d-Flag: IOAM DEX Option Type-enabled flag. If d bit is set (1), the router is capable of IOAM DEX <xref
        target="I-D.ioamteam-ippm-ioam-direct-export"/>.</t>

        <t>e-Flag: IOAM E2E Option Type-enabled flag. If e bit is set (1), the router is capable of IOAM E2E processing <xref
        target="I-D.ietf-ippm-ioam-data"/>. </t>

        <t>m-Flag: Enhanced Alternative Marking enabled flag. If m bit is set (1), then the router is capable of processing Enhanced Alternative Marking packets <xref target="I-D.zhou-ippm-enhanced-alternate-marking"/>.</t>
		
		<t>Reserved: Must be set to zero upon transmission and ignored upon receipt.</t>

		<t>An IFIT node SHALL be capable of more than one IFIT option types. So in this case, IFIT Option Type-enabled Flag bitmap SHOULD has more than one bit being set.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t/>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>

      <section title="TLV Code Point of the new IFIT Node Capability TLV within Node NLRIs">
        <t>This document makes the following registrations for a Node Attribute TLV code point for the IFIT Node Capability TLV included with Node NLRIs.</t>

        <t/>

        <texttable align="center">
          <ttcol>Code Point</ttcol>

          <ttcol>Description</ttcol>		

          <c>TBD</c>

          <c>IFIT Node Capability</c>
		  		 
        </texttable>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document introduces new Node Attribute TLVs for the existing Node NLRIs. It does not introduce any new security risks to BGP-LS.
      </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <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>

    </references>

    <references title="Informative References">
      <reference anchor="I-D.song-opsawg-ifit-framework"
                 target="https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/">
        <front>
          <title>In-situ Flow Information Telemetry Framework</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="I-D.ietf-ippm-ioam-data">
        <front>
          <title>Data Fields for In-situ OAM</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="I-D.song-ippm-postcard-based-telemetry"
                 target="https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/">
        <front>
          <title>Postcard-based On-Path Flow Data Telemetry</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="I-D.ioamteam-ippm-ioam-direct-export"
                 target="https://datatracker.ietf.org/doc/draft-ioamteam-ippm-ioam-direct-export/">
        <front>
          <title>In-situ OAM Direct Exporting</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="I-D.zhou-ippm-enhanced-alternate-marking"
                 target="https://datatracker.ietf.org/doc/draft-zhou-ippm-enhanced-alternate-marking/">
        <front>
          <title>Enhanced Alternate Marking Method</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
