<?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-bgpls-extensions-ifit-00"
     ipr="trust200902">
  <front>
    <title abbrev="draft-wang-idr-bgpls-extensions-ifit-00"> 
	BGP-LS Extensions for In-situ Flow Information Telemetry (IFIT) Capability Advertisement</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="Min Liu" initials="M." surname="Liu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd., Haidian District</street>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>lucy.liumin@huawei.com</email>

        <uri/>
      </address>
    </author>
	
	<author fullname="Ran Pang" initials="R." 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.cn</email>

        <uri/>
      </address>
    </author>
	
	<author fullname="Huanan Chen" initials="H." surname="Chen">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>109 West Zhongshan Ave.</street>

          <city>Guangzhou, Guangdong</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>chenhuan6@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>

    <date day="13" month="July" year="2020"/>

    <workgroup>Inter-Domain Routing Working Group</workgroup>

    <abstract>
		<t>This document extends Node and Link Attribute TLVs to Border Gateway Protocol-Link State (BGP-LS) to advertise supported In-situ Flow Information Telemetry (IFIT) capabilities at node and/or link granularity. An ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In addition, such advertisements would be useful for entities (e.g. Path Computation Element (PCE)) to gather each router's IFIT capability for achieving the computation of end-to-end Traffic Engineering (TE) paths that be able to fulfill the visibility of on-path OAM data.</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 high-level framework and a reflection-loop solution for on-path telemetry <xref target="I-D.song-opsawg-ifit-framework"/>. At present, there is a family of emerging on-path telemetry techniques, including In-situ OAM (IOAM) <xref target="I-D.ietf-ippm-ioam-data"/>, IOAM Direct Export (DEX) <xref target="I-D.ietf-ippm-ioam-direct-export"/>, Enhanced Alternate Marking (EAM) <xref target="I-D.ietf-6man-ipv6-alt-mark"/>, etc.</t>
	  
		<t>IFIT is a solution focusing on network domains. The "network domain" consists of a set of network devices or entities within a single Autonomous System (AS). The part of the network which employs IFIT is referred to as the IFIT domain. One network domain may consist of multiple IFIT domains. An IFIT domain may cross multiple network domains. The family of emerging on-path telemetry techniques may be partially enabled in different vendors' devices as an emerging feature for various use cases of application-aware network operations. So that in order to dynamically enable IFIT functionality in a network domain, it is necessary to advertise the information of IFIT option types supported in each device.</t>
		
		<t>An ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In addition, such advertisements would be useful for entities (e.g. Path Computation Element (PCE)) to gather each router's IFIT capability for achieving the computation of end-to-end TE paths that be able to fulfill the visibility of on-path OAM data.</t>
	  
		<t><xref target="RFC7752"/> describes a mechanism by which link-state and TE information can be collected from the network outside one Interior Gateway Protocols (IGP) area or Autonomous System (AS). This document extends Node and Link Attribute TLVs to BGP-LS to advertise supported IFIT capabilities at node and/or link granularity.</t>
    </section>
	
	<section title="Terminology">
	  <t>Following are abbreviations used in this document:</t>
		<t><list style="symbols">
		<t>BGP-LS: Border Gateway Protocol - Link State</t>
		<t>IFIT: In-situ Flow Information Telemetry</t>
		<t>TE: Traffic Engineering</t>
		<t>IOAM: In-situ OAM</t>
		<t>PBT: Postcard-Based Telemetry</t>
		<t>DEX: IOAM Direct Export</t>
		<t>EAM: Enhanced Alternate Marking</t>
		<t>IGP: Interior Gateway Protocols</t>
		<t>AS: Autonomous System</t>
		<t>E2E: Edge-to-Edge</t>
		<t>NLRI: Network Layer Reachability Information</t>
		</list></t>
	</section>

	<section title="IFIT Capability">
		<t>Each IFIT-capable 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.ietf-ippm-ioam-direct-export"/> and EAM Option-Type <xref target="I-D.ietf-6man-ipv6-alt-mark"/>. A subset or all the IFIT-Option-Types and their corresponding IFIT-Data-Fields can be associated to an IFIT-Namespace. Namespace identifiers allow a device which is IFIT-capable to determine whether IFIT-Option-Types need to be processed. So that IFIT-Option-Types and Namespace-IDs SHOULD be included in IFIT capability information.</t>
		
		<t>This document defines the IFIT Capability information formed of one or more pairs of a 2-octet Namespace-ID and 16-bit Option-Type Flag.</t>
			
		<t><figure align="center"
		title="Fig. 1 IFIT Capability 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
+---------------------------------------------------------------+
|          Namespace-ID_1       |       Option-Type Flag_1      |
+---------------------------------------------------------------+
|          Namespace-ID_2       |       Option-Type Flag_2      |
+---------------------------------------------------------------+
|              ...              |              ...              |
+---------------------------------------------------------------+
]]></artwork>
			</figure>Where:</t>
			<t><list style="symbols">
			<t>Namespace-ID: A 2-octet identifier, which must be present and populated in all IFIT-Option-Types. The definition is the same as described in <xref target="I-D.ietf-ippm-ioam-data"/>.</t>
		
			<t>Option-Type Flag: A 16-bit bitmap, which is defined as:</t>
		
			</list></t>
			<t><figure align="center">
			<artwork><![CDATA[
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
     +-------------------------------+
     |p|i|d|e|m|       Reserved      |
     +-------------------------------+
]]></artwork>
		</figure>Where:</t>
		<t><list style="symbols">
			<t>p-Flag: IOAM Pre-allocated Trace Option Type flag. When set, this indicates that 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 flag. When set, this indicates that the router is capable of IOAM Incremental Tracing <xref target="I-D.ietf-ippm-ioam-data"/>.</t>

			<t>d-Flag: IOAM DEX Option Type flag. When set, this indicates that the router is capable of IOAM DEX <xref target="I-D.ietf-ippm-ioam-direct-export"/>.</t>

			<t>e-Flag: IOAM E2E Option Type flag. When set, this indicates that the router is capable of IOAM E2E processing <xref target="I-D.ietf-ippm-ioam-data"/>.</t>

			<t>m-Flag: EAM flag. When set, this indicates that the router is capable of processing Enhanced Alternative Marking packets <xref target="I-D.ietf-6man-ipv6-alt-mark"/>.</t>
		
			<t>Reserved: Must be set to zero upon transmission and ignored upon receipt.</t>
			</list></t>
			
			<t>An IFIT node MAY be capable of more than one IFIT option types. In this case, Option-Type Flag can has more than one bit being set.</t>
		
			<t>In this document, Link IFIT Capability is defined as the supported IFIT-Option-Types of the interface associated with the link. When all interfaces associated with links support the same IFIT-Option-Type, the Node IFIT Capability SHOULD represent the Link IFIT Capability. Both of Node and Link IFIT Capability information are formed of one or more pairs of Namespace-ID and Option-Type Flag.</t>
		
			<t>When both of Node and Link IFIT Capability are advertised, the Link IFIT Capability information MUST take precedence over the Node IFIT Capability. Besides, when a Link IFIT Capability is not signaled, then the Node IFIT Capability SHOULD be considered to be the IFIT Capability for this link.</t>
	</section>


	<section title="Signaling IFIT Capability Using BGP-LS">
		<section title="Node IFIT TLV">
			<t>The Node IFIT TLV is an optional extension to Node Attribute TLVs that may be encoded in the BGP-LS Attribute associated with a Node NLRI <xref target="RFC7752"/>. The following format is used:</t>
		
			<t><figure align="center"
			title="Fig. 7 BGP-LS Node IFIT 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-IFIT-Capability                     |
~                                                               ~
+---------------------------------------------------------------+

]]></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. </t>

			<t>Node-IFIT-Capability: A multiple of 4-octet field, which is as defined in Section 3.</t> 
			</list></t>
		</section>
	
		<section title="Link IFIT TLV">
			<t>The Link IFIT TLV is an optional extension to Link Attribute TLVs that may be encoded in the BGP-LS Attribute associated with a Link NLRI <xref target="RFC7752"/>. The following format is used:</t>
		
			<t><figure align="center"
			title="Fig. 8 BGP-LS Link IFIT 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-IFIT-Capability                     |
~                                                               ~
+---------------------------------------------------------------+

]]></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. </t>

			<t>Link-IFIT-Capability: A multiple of 4-octet field, which is as defined in Section 3.</t> 
			</list></t>
		</section>
	</section>
	
	<section title="Application">
		<t>As any packet with IFIT-Data-Fields must not leak out from the IFIT domain, the IFIT decapsulating node must be able to capture packets with IFIT-specific header and metadata and recover their format before forwarding them out of the IFIT domain. Thus, an ingress router cannot insert IFIT-Data-Fields for packets going into a path unless an egress router has indicated via signaling that it has the capability to process IFIT-Data-Fields. In this case, such advertisements are helpful for avoiding the leak of IFIT-specific header and metadata.</t>
		
		<t>In addition, such advertisements would be useful for entities (e.g. Path Computation Element (PCE)) to gather each router's IFIT capability for achieving the computation of end-to-end TE paths that be able to fulfill the visibility of on-path OAM data. For example, for achieving the computation of low-latency SR-TE path, latency is expected to be collected at every node that a packet traverses to ensure performance visibility into the entire path. IOAM Trace Option-Types is a desired option to have a hop-by-hop latency measurement. If not all nodes on this path are IOAM Trace Option-Type capable, an incomplete measurement can have negative impacts on SR-TE path computation and adjustment for low-latency assurance.</t>
	</section>

    <section anchor="IANA" title="IANA Considerations">
        <t>IANA is requested to allocate values for the following TLV Type from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry.</t>

        <texttable align="center">
          <ttcol>Code Point</ttcol>

          <ttcol>Description</ttcol>	

		  <ttcol>Reference</ttcol>

          <c>TBA1</c>

          <c>Node IFIT</c>
		  
		  <c>This document</c>
		  
		  <c>TBA2</c>

          <c>Link IFIT</c>
		  
		  <c>This document</c>
        </texttable>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document introduces new BGP-LS Node and Link Attribute TLVs for the IFIT Capability advertisements at node and/or link granularity. It does not introduce any new security risks to BGP-LS.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff Tantsura, Rakesh Gandhi and Greg Mirsky for the comments and advices.</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.ietf-ippm-ioam-direct-export"
                 target="https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/">
        <front>
          <title>In-situ OAM Direct Exporting</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <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>
	  
    </references>
  </back>
</rfc>
