<?xml version="1.0" encoding="utf-8"?>
<!--
     draft-rfcxml-general-template-annotated-00

     This template includes examples of most of the features of RFCXML
     with comments explaining how to customise them, and examples of how
     to achieve specific formatting.

     Documentation is at
     https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>
<!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations
     in XML processors, including most browsers -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be
     added to the DOCTYPE above. Use of an external entity file is
     not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-admnr-lsr-igp-measurement-group-02"
  ipr="trust200902"
  obsoletes=""
  updates=""
  consensus="true"
  submissionType="IETF"
  xml:lang="en"
  version="3">
  <?rfc toc="yes"?>
<!--
    * docName should be the name of your draft * category should be
    one of std, bcp, info, exp, historic * ipr should be one of
    trust200902, noModificationTrust200902, noDerivativesTrust200902,
    pre5378Trust200902 * updates can be an RFC number as NNNN *
    obsoletes can be an RFC number as NNNN
-->

  <front>
    <title abbrev="IGP Measurement Group">Advertising IGP Measurement Group using TLV</title>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#title-4 -->
    <!--  The abbreviated title is required if the full title is longer
          than 39 characters -->

    <seriesInfo name="Internet-Draft" value="draft-admnr-lsr-igp-measurement-group-02"/>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#seriesinfo -->
    <!-- Set value to the name of the draft  -->

    <author fullname="Mahesh Jethanandani" initials="M" role="editor" surname="Jethanandani">
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#author -->
    <!-- initials should not include an initial for the surname -->
    <!-- role="editor" is optional -->
    <!-- Can have more than one author -->

    <!-- all of the following elements are optional -->
    <organization>Arrcus, Inc</organization>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
    <address>
      <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
      <postal>
        <!-- Reorder these if your country does things differently -->
        <street>2077 Gateway Place, Suite 400</street>
        <city>San Jose</city>
        <region>CA</region>
        <code>95110</code>
        <country>US</country>
          <!-- Can use two letter country code -->
      </postal>
      <email>mjethanandani@gmail.com</email>
      <!-- Can have more than one <email> element -->
      <uri>URI</uri>
    </address>
    </author>

   <author fullname="Derek Yeung" initials="D" role="editor" surname="Yeung">
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#author -->
    <!-- initials should not include an initial for the surname -->
    <!-- role="editor" is optional -->
    <!-- Can have more than one author -->

    <!-- all of the following elements are optional -->
    <organization>Arrcus, Inc</organization>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
    <address>
      <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
      <postal>
        <!-- Reorder these if your country does things differently -->
        <street>2077 Gateway Place, Suite 400</street>
        <city>San Jose</city>
        <region>CA</region>
        <code>95110</code>
        <country>US</country>
          <!-- Can use two letter country code -->
      </postal>
      <email>derek@arrcus.com</email>
      <!-- Can have more than one <email> element -->
      <uri>URI</uri>
    </address>
    </author>

    <author fullname="Acee Lindem" initials="A" role="editor" surname="Lindem">
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#author -->
    <!-- initials should not include an initial for the surname -->
    <!-- role="editor" is optional -->
    <!-- Can have more than one author -->

    <!-- all of the following elements are optional -->
    <organization>Arrcus, Inc</organization>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
    <address>
      <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
      <postal>
        <!-- Reorder these if your country does things differently -->
        <street>301 Midenhall Way</street>
        <city>Cary</city>
        <region>NC</region>
        <code>27513</code>
        <country>US</country>
          <!-- Can use two letter country code -->
        </postal>
        <email>acee.ietf@gmail.com</email>
        <!-- Can have more than one <email> element -->
        <uri>URI</uri>
      </address>
    </author>

    <author fullname="Reshad Rahman" initials="R" role="editor" surname="Rahman">
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#author -->
    <!-- initials should not include an initial for the surname -->
    <!-- role="editor" is optional -->
    <!-- Can have more than one author -->

    <!-- all of the following elements are optional -->
    <organization>Equinix, Inc</organization>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
    <address>
      <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
      <postal>
        <!-- Reorder these if your country does things differently -->
        <country>CA</country>
          <!-- Can use two letter country code -->
        </postal>
        <phone>Phone</phone>
        <email>reshad@yahoo.com</email>
        <!-- Can have more than one <email> element -->
        <uri>URI</uri>
      </address>
    </author>

    <author fullname="Nico Strina" initials="N" surname="Strina">
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#author -->
    <!-- initials should not include an initial for the surname -->
    <!-- role="editor" is optional -->
    <!-- Can have more than one author -->

    <!-- all of the following elements are optional -->
    <organization>Equinix, Inc</organization>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#organization -->
    <address>
      <!-- https://authors.ietf.org/en/rfcxml-vocabulary#address -->
      <postal>
        <!-- Reorder these if your country does things differently -->
        <country>US</country>
          <!-- Can use two letter country code -->
        </postal>
        <phone>Phone</phone>
        <email>nstrina@equinix.com</email>
        <!-- Can have more than one <email> element -->
        <uri>URI</uri>
      </address>
    </author>

    <date/>
    <!-- https://authors.ietf.org/en/rfcxml-vocabulary#date -->
    <!-- On draft submission:
         * If only the current year is specified, the current day and
           month will be used.
         * If the month and year are both specified and are the current
           ones, the current day will
           be used
         * If the year is not the current one, it is necessary to
           specify at least a month and day="1" will be used.
    -->

    <area>Routing</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual
          submissions.  If this element is
          not present, the default is "Network Working Group", which
          is used by the RFC Editor as
          a nod to the history of the RFC Series. -->
    <keyword>IGP</keyword>
    <keyword>IS-IS</keyword>
    <keyword>TWAMP</keyword>
    <keyword>STAMP</keyword>
    <keyword>measurement</keyword>
    <keyword>discovery</keyword>
    <!-- Multiple keywords are allowed.  Keywords are incorporated
         into HTML output files for use by search engines. -->

    <abstract>
      <t>
        This document defines an IS-IS capability sub-TLV for advertising
        measurement group membership for Active Measurement Protocols (AMPs) such as
        TWAMP and STAMP. The mechanism allows IGP routers to discover other
        routers participating in different measurement groups, enabling automatic
        discovery of measurement endpoints across IGP areas. The solution uses
        interface addresses (IPv4 or IPv6) to identify measurement group membership,
        where the same interface address may be used for multiple measurement groups.
      </t>
    </abstract>

  </front>

  <middle>

    <section>
    <!-- The default attributes for <section> are numbered="true" and toc="default" -->
      <name>Introduction</name>
      <t>
        In network deployments, different IGP routers may participate in
        different measurement groups for various purposes. For example, one measurement group
        may be used for TWAMP (Two-Way Active Measurement Protocol), another
        for STAMP (Simple Two-Way Active Measurement Protocol), and yet another
        for other operational purposes.
      </t>

      <t>
        To enable automatic discovery and configuration of these measurement groups,
        there is a need for IGP routers to discover which other routers are
        participating in which measurement groups. This discovery mechanism must work
        whether the participating routers are in the same IGP area or not,
        which implies that the information must be leakable across area
        boundaries.
      </t>

      <t>
        This document defines an IS-IS capability sub-TLV, similar to the
        seamless BFD discriminators mechanism defined in <xref target="RFC7883"/>,
        that allows routers to advertise their measurement group membership. The
        mechanism uses interface addresses (IPv4 or IPv6) to identify measurement group
        membership, where the interface address may be associated with either a
        physical interface or a loopback interface. The same interface address
        may be used to indicate membership in multiple measurement groups.
      </t>

      <section anchor="requirements">
      <!-- anchor is an optional attribute -->
        <name>Requirements Language</name>
        <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>
      <name>Use Case</name>
      <t>
	At a high level, different IGP routers participate in
	different measurement groups. For example, measurement group A
	may be used for TWAMP, measurement group B for STAMP, and
	measurement group C for another purpose.
      </t>

      <t>The requirements for measurement group discovery are:</t>
      <ul spacing="normal">
        <li>
          IGP routers MUST be able to discover which routers are
          participating in which measurement groups.
        </li>
        <li>
          Discovery MUST work whether participating routers are in the same
          IGP area or not, which implies that the information MUST be leakable
          across area boundaries.
        </li>
        <li>
          An interface address (IPv4 or IPv6) is used to identify the
          membership of a particular measurement group.
        </li>
        <li>
          The interface address MAY be associated with either a physical
          interface or a loopback interface.
        </li>
        <li>
          The same interface address MAY be used for multiple measurement groups.
        </li>
      </ul>

      <t>
        Since loopback support is required, and there is no adjacency
        created over loopback interfaces to carry Adjacency Segment Identifier
        (ASLA) information, the solution uses an IS-IS capability sub-TLV
        similar to seamless BFD discriminators <xref target="RFC7883"/>. This
        approach allows the advertisement of measurement group membership information
        in the Router Capability TLV, which is propagated across area
        boundaries.
      </t>
    </section>

    <section>
      <name>IS-IS Active Measurement Protocol Measurement Group Sub-TLV</name>
      <t>
        This document defines a new IS-IS capability sub-TLV for advertising
        Active Measurement Protocol (AMP) measurement group membership. The sub-TLV is
        carried in the IS-IS Router Capability TLV (TLV 242) as defined in
        <xref target="RFC7981"/>.
      </t>

      <t>The Active Measurement Protocol Measurement Group sub-TLV has the following
      format:</t>

      <figure>
        <name>AMP Measurement Group Sub-TLV Format</name>
        <artwork type="ascii-art" name="amp-mesh-tlv.txt">
          <![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     |   Group ID    | AMP Protocol  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|              IPv4 or IPv6 Host Address (4 or 16 octets)       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]>
        </artwork>
      </figure>

      <t>Fields:</t>
      <dl newline="true" spacing="normal">
        <dt>Type:</dt>
        <dd>
          TBD (to be assigned by IANA)
        </dd>

        <dt>Length:</dt>
        <dd>
          1 octet. The length of the value field in octets. For IPv4
          addresses, the length MUST be 6. For IPv6 addresses, the length
          MUST be 18.
        </dd>

        <dt>Group ID:</dt>
        <dd>
          Group ID used to associate the endpoint's membership with
          other routers in the same group. An IS-IS router can advertise multiple
          AMP Measurement Group sub-TLVs with different Group IDs. This will allow
          Active Measurements sessions amongst multiple groups of IS-IS routers.
        </dd>

        <dt>AMP Protocol:</dt>
        <dd>
          1 octet. An identifier of the single Active Measurement Protocol
          supported on this Group ID and IPv4/IPv6 Endpoint. Value
          assignments are specified in <xref target="amp-protocol-values"/>.
        </dd>

        <dt>IPv4/IPv6 Endpoint Address:</dt>
        <dd>
          4 octets for IPv4 or 16 octets for IPv6. The interface address
          (IPv4 or IPv6) that identifies this endpoint's membership in the
          measurement group indicated by the AMP Protocol field. This address MAY
          be associated with a physical interface or a loopback interface.
        </dd>
      </dl>

      <t>
        Multiple instances of this sub-TLV MAY be included in the Router
        Capability TLV to advertise multiple endpoints, each potentially
        supporting different Group IDs, IP Endpoint Addresses, and Active
        Measurement Protocols. Each sub-TLV instance carries a single AMP
        Protocol value and is uniquely identified by the combination of
        Group ID, IP Endpoint Address, and AMP Protocol value. A router that
        supports multiple Active Measurement Protocols on the same Group ID
        and IP Endpoint Address MUST advertise a separate sub-TLV instance
        for each protocol. If multiple sub-TLVs have the same Group ID, IP
        Endpoint Address, and AMP Protocol value, only the first will be
        used.
      </t>

      <section anchor="amp-protocol-values">
        <name>AMP Protocol Values</name>
        <t>
          The AMP Protocol field is a single-octet value identifying the
          Active Measurement Protocol supported for the Group ID and IP
          Endpoint Address carried in this sub-TLV instance. The value
          assignments are as follows:
        </t>

        <table>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Protocol</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left"></td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">TWAMP</td>
              <td align="left"><xref target="RFC5357"/></td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">STAMP</td>
              <td align="left"><xref target="RFC8762"/></td>
            </tr>
            <tr>
              <td align="left">3-255</td>
              <td align="left">Unassigned</td>
              <td align="left">For future assignment by IANA</td>
            </tr>
          </tbody>
        </table>

        <t>
          A sub-TLV instance carries exactly one AMP Protocol value,
          identifying the single protocol supported for the Group ID and
          IP Endpoint Address advertised in that instance.
        </t>

        <t>
          If an endpoint supports multiple protocols, the router advertises
          this by including multiple sub-TLV instances that share the same
          Group ID and IP Endpoint Address, each with a different AMP
          Protocol value, meaning the same interface address is used for
          multiple measurement groups.
        </t>
      </section>
   </section>

    <section>
      <name>Operations</name>
      <t>
        A router that participates in one or more Active Measurement
        Protocol measurement groups MUST advertise the AMP Measurement Group sub-TLV in its
        Router Capability TLV. For each endpoint (interface address) that
        participates in a measurement group, the router MUST include an instance of
        the sub-TLV with the appropriate AMP Protocol value set.
      </t>

      <t>
        If an endpoint supports multiple protocols (e.g., both TWAMP and
        STAMP), the router advertises this by including multiple sub-TLV
        instances that share the same Group ID and IP Endpoint Address,
        each with a different AMP Protocol value.
      </t>

      <t>
        Routers receiving the AMP Measurement Group sub-TLV MUST process the
        information to build their measurement group membership database. This
        information is used to discover other routers participating in the
        same measurement groups, enabling automatic configuration of measurement
        sessions.
      </t>

      <t>
        Given that an IP endpoint may be used for multiple measurement groups
        and AMP protocols, a router should only establish a single session of
        a given protocol type between the same two pairs of IP endpoints (independent
        of how many groups the endpoint participates in). If two routers share
        more than one AMP protocol, whether or not a session is establish for
        multiple AMP protocols is a local policy decision.
      </t>

      <t>
        When a router receives the Router Capability TLV, it will check to see
        if it supports the advertised IP endpoint address family, AMP protocol(s),
        and group ID. If it does and there isn't already AMP session(s) with
        the router, it will attempt to establish AMP session(s) with the
        advertising IGP router. When both IP endpoints attempt to establish
        a session for the same AMP protocol, the IP endpoint with the
        lexicographically greater IP address's session take precedence.
      </t>

      <t>
        The Router Capability TLV, and thus the AMP Measurement Group sub-TLV, is
        propagated across IS-IS area boundaries when area leaking is
        configured as specified in <xref target="RFC7981"/>, satisfying
        the requirement for cross-area discovery.
      </t>

      <t>
	If a router's measurement group membership changes, it MUST
	update its Router Capability TLV advertisement
	accordingly. Routers receiving updated information MUST
	process the changes and update their measurement group
	membership database.
      </t>
    </section>

    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>

      <section>
        <name>IS-IS Router Capability TLV Sub-TLVs</name>
        <t>IANA is requested to assign a new sub-TLV type from the "IS-IS
        Router Capability TLV sub-TLVs" registry for the Active Measurement
        Protocol Measurement Group sub-TLV defined in this document.</t>
      </section>

      <section>
        <name>AMP Active Protocol Registry</name>
        <t>IANA is requested to create a new registry called "AMP Active
        Protocol Registry" under the "Interior Gateway Protocol (IGP)
        Parameters" registry group. The registry should track value
        assignments for Active Measurement Protocols in the AMP Protocol field of the
        AMP Measurement Group sub-TLV.</t>

        <t>The initial assignments are:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Protocol</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left">this document</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">TWAMP</td>
              <td align="left"><xref target="RFC5357"/>, this document</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">STAMP</td>
              <td align="left"><xref target="RFC8762"/>, this document</td>
            </tr>
            <tr>
              <td align="left">3-255</td>
              <td align="left">Unassigned</td>
              <td align="left"></td>
            </tr>
          </tbody>
        </table>

        <t>Future assignments are to be made through IETF Review <xref target="RFC8126"/>.</t>
      </section>
    </section>

    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>
        This document defines a mechanism for advertising measurement group
        membership in IS-IS. The security considerations for IS-IS as
        specified in <xref target="RFC1195"/> and <xref target="RFC5304"/>
        apply.
      </t>

      <t>
        An attacker that can inject false AMP Measurement Group sub-TLVs could
        cause routers to attempt to establish measurement sessions with
        incorrect endpoints, potentially leading to:
      </t>
      <ul spacing="normal">
        <li>Failed measurement sessions</li>
        <li>Misconfiguration of measurement infrastructure</li>
        <li>Resource exhaustion if many false endpoints are advertised</li>
      </ul>

      <t>
        To mitigate these risks, implementations SHOULD authenticate IS-IS
        protocol exchanges using the mechanisms defined in <xref target="RFC5304"/>
        for IS-IS authentication. Additionally, operators SHOULD configure
        appropriate access controls and monitoring to detect and prevent
        unauthorized advertisements.
      </t>

      <t>
        The information advertised in the AMP Measurement Group sub-TLV reveals
        which routers are participating in measurement groups and which
        interface addresses are used for measurement purposes. This information
        may be considered sensitive in some deployments. Operators should
        consider the implications of this information disclosure when deploying
        this mechanism.
      </t>
    </section>

    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7883.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7981.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>

      <references>
        <name>Informative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/>

      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false">
      <!-- an Acknowledgements section is optional -->
      <name>Acknowledgements</name>
      <t>The authors would like to thank the participants in the IETF
      discussions that led to this document.</t>
    </section>

 </back>
</rfc>
