<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
    most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-grow-bmp-bgp-rib-stats-01"
ipr="trust200902" updates="7854" consensus="true">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: full3667, noModification3667, noDerivatives3667
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="BMP New Statistics">
    Definition For New BMP  Statistics Type</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Mukul Srivastava" initials="M."
            surname="Srivastava">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>10 Technology Park Dr</street>

          <!-- Reorder these if your country does things differently -->

          <city>Westford</city>

          <region>MA</region>

          <code>01886</code>

          <country>USA</country>
        </postal>

        <email>msri@juniper.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2024" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>GROW</workgroup>

    <keyword>IDR</keyword>
    <keyword>GROW</keyword>
    <keyword>BGP</keyword>
    <keyword>BMP</keyword>

<abstract>
<t>
	RFC 7854 defined different BMP statistics messages types to observe interesting events that occur on the router.
	This document updates RFC 7854 by adding new statistics type.
</t>

</abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
	<xref target="RFC7854"/> defines a number of different BMP statistics types to observe interesting events that occur on the router.
	Stats are either counters or gauges. A 32-bit Counter is a non-negative integer that monotonically increases
   until it reaches a maximum value, when it wraps around and starts increasing again from 0.
   A 64-bit Gauge is a non-negative integer that may increase or decrease, but shall never exceed a maximum value, nor fall below a minimum one.
</t>
<t>
   This document defines new gauges for BMP statistics message. The format of the BMP statistics message remains same as defined in <xref target="RFC7854"/>
</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in BCP 14 <xref target="RFC2119"/> <xref
        target="RFC8174"/> when, and only when, they appear in all
        capitals, as shown here.</t>
      </section>

</section>

<section anchor="Stats" title="Statistics Definition">
<t>
    This section defines different statistics type for RIB-IN and RIB-OUT monitoring type.
</t>
<section anchor="rib-in-stats" title="RIB-IN Statistics Definition">
<t>
	<list style="symbols">
  <t>
		Type = TBD1: (64-bit Gauge) Current number of routes in Adj-RIBs-In-Pre-Policy. 
		The value can increase or decrease base on ongoing configuration change.
		
		Note that this counter updates stats type 7 defined in <xref target="RFC7854"/> and makes it a explicit for Adj-RIBs-In-Pre-Policy. 
	</t>

	<t>
		Type = TBD2: (64-bit Gauge) Current number of routes in per-AFI/SAFI Adj-RIBs-In-Pre-Policy. 
		The value can increase or decrease base on ongoing configuration change.
		
		Note that this counter is similar from stats type 9 defined in <xref target="RFC7854"/> and makes it a explicit for Adj-RIBs-In-Pre-Policy. 
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
	</t>

	<t>
		Type = TBD3: (64-bit Gauge) Current number of routes in Adj-RIBs-In-Post-Policy. 
		The value can increase or decrease base on ongoing configuration change.
	</t>

	<t>
		Type = TBD4: (64-bit Gauge) Current number of routes in per-AFI/SAFI Adj-RIBs-In-Post-Policy. 
		The value can increase or decrease base on ongoing configuration change.
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
	</t>

	<t>
		Type = TBD5: (64-bit Gauge) Current number of routes in per-AFI/SAFI rejected by inbound policy. 
		The value can increase or decrease base on ongoing configuration change.
		
		Note that this counter is different from stats type 0 defined in <xref target="RFC7854"/>. 
		The stats type 0 in <xref target="RFC7854"/> is the a 32 counter which is monotonically increasing number and 
		doesn't represents the current number of routes rejected by inbound policy due to ongoing configuration changes.
    
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.

	</t>

	<t>
		Type = TBD6: (64-bit Gauge) Number of routes in per-AFI/SAFI accepted by inbound policy.
		The value can increase or decrease base on ongoing configuration change or network events.
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
    Some implementations, or configurations in implementations, may discard routes that do not match policy and 
    thus the accepted count and the rib-in counts will be identical in such cases. 

	</t>

	<t>
		Type = TBD7: (64-bit Gauge) Number of routes in per-AFI/SAFI selected as active route. 
		The value can increase or decrease base on ongoing configuration change or network events.
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
	</t>

	<t>
		Type = TBD8: (64-bit Gauge) Number of routes in per-AFI/SAFI damped by configured route damping policy. 
		The value can increase or decrease base on configuration change or network events.
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
	</t>

	<t>
		Type = TBD9: (64-bit Gauge) Number of routes in per-AFI/SAFI marked as stale by any configuration.
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
    This is the route that are marked stale as part of GR <xref target="RFC4784"/> process.
	</t>

	<t>
		Type = TBD10: (64-bit Gauge) Number of routes in per-AFI/SAFI marked as stale by LLGR. 
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
    This is the route that are marked stale as part of LLGR process.
	</t>

	</list>
</t>
</section>

<section anchor="rib-out-stats" title="RIB-OUT Statistics Definition">
<t>
	<list style="symbols">

	<t>
		Type = TBD11: (64-bit Gauge) Current number of routes in per-AFI/SAFI rejected by outbound policy. 
    These routes are active routes which should otherwise would have been advertised in absense of outbound policy which rejected them.
    The value can increase or decrease base on ongoing configuration change.
    The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.
    This counter only considers routes distributed from loc-rib into the adj-ribs-out and does not include cases like BGP add-paths <xref target="RFC7911"/>. 
	</t>

	</list>
</t>
</section>


</section>


<section anchor="IANA" title="IANA Considerations">
<t>
	This document requests that IANA assign the following new parameters
	to the <eref
				target="https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml">
	BMP parameters name space</eref>.
</t>


</section>

<section anchor="Security" title="Security Considerations">
<t>

  The considerations in <xref target="RFC7854" sectionFormat="of" section="11" format="default" 
  derivedLink="https://rfc-editor.org/rfc/rfc7854#section-11" derivedContent="RFC7854"/> apply to this document.
  It is also believed that this document does not add any additional security considerations.


</t>
</section>

<section anchor="Acknowledgements" title="Acknowledgements">
<t>
	The author would like to thank Jeff Haas for his valuable input.
</t>
</section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <!--?rfc include=
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <?rfc include="reference.RFC.2119.xml"?>
	  <?rfc include="reference.RFC.7854.xml"?>
	  <?rfc include="reference.RFC.8671.xml"?>
	  <?rfc include="reference.RFC.9069.xml"?>
	  <?rfc include="reference.RFC.8174.xml"?>
    <?rfc include="reference.RFC.7911.xml"?>
    <?rfc include="reference.RFC.4784.xml"?>
<!--	  <?rfc include="reference.RFC.8126.xml"?> -->
    </references>
    
  </back>
</rfc>
