



Internet Engineering Task Force                     M. Jethanandani, Ed.
Internet-Draft                                             D. Yeung, Ed.
Intended status: Standards Track                          A. Lindem, Ed.
Expires: 7 August 2026                                       Arrcus, Inc
                                                          R. Rahman, Ed.
                                                               N. Strina
                                                            Equinix, Inc
                                                         3 February 2026


              Advertising IGP Measurement Group using TLV
                draft-admnr-lsr-igp-measurement-group-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Jethanandani, et al.      Expires 7 August 2026                 [Page 1]

Internet-Draft            IGP Measurement Group            February 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IS-IS Active Measurement Protocol Measurement Group
           Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Protocol Flags  . . . . . . . . . . . . . . . . . . . . .   5
   4.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  IS-IS Router Capability TLV Sub-TLVs  . . . . . . . . . .   6
     5.2.  AMP Measurement Group Protocol Flags Registry . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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 measurement or operational
   purposes.

   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.

   This document defines an IS-IS capability sub-TLV, similar to the
   seamless BFD discriminators mechanism defined in [RFC7883], that
   allows routers to advertise their measurement group membership.  The
   mechanism uses interface addresses (IPv4 or IPv6) to identify



Jethanandani, et al.      Expires 7 August 2026                 [Page 2]

Internet-Draft            IGP Measurement Group            February 2026


   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.

1.1.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Use Case

   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.

   The requirements for measurement group discovery are:

   *  IGP routers MUST be able to discover which routers are
      participating in which measurement groups.

   *  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.

   *  An interface address (IPv4 or IPv6) is used to identify the
      membership of a particular measurement group.

   *  The interface address MAY be associated with either a physical
      interface or a loopback interface.

   *  The same interface address MAY be used for multiple measurement
      groups.

   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 [RFC7883].  This approach allows the
   advertisement of measurement group membership information in the
   Router Capability TLV, which is propagated across area boundaries.







Jethanandani, et al.      Expires 7 August 2026                 [Page 3]

Internet-Draft            IGP Measurement Group            February 2026


3.  IS-IS Active Measurement Protocol Measurement Group Sub-TLV

   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 [RFC7981].

   The Active Measurement Protocol Measurement Group sub-TLV has the
   following format:

    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     | Protocol Flags|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |              IPv4 or IPv6 Host Address (4 or 16 octets)      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: AMP Measurement Group Sub-TLV Format

   Fields:

   Type:
      TBD (to be assigned by IANA)

   Length:
      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.

   Protocol Flags:
      1 octet.  A bit field indicating which Active Measurement
      Protocols are supported on this endpoint.  Bit definitions are
      specified in Section 3.1.

   Reserved:
      1 octet.  MUST be set to zero on transmission and MUST be ignored
      on receipt.

   IPv4 or IPv6 Host Address:
      4 octets for IPv4 or 16 octets for IPv6.  The interface address
      (IPv4 or IPv6) that identifies this endpoint's membership in the
      measurement groups indicated by the Protocol Flags field.  This
      address MAY be associated with a physical interface or a loopback
      interface.




Jethanandani, et al.      Expires 7 August 2026                 [Page 4]

Internet-Draft            IGP Measurement Group            February 2026


   Multiple instances of this sub-TLV MAY be included in the Router
   Capability TLV to advertise multiple endpoints, each potentially
   supporting different combinations of Active Measurement Protocols.

3.1.  Protocol Flags

   The Protocol Flags field is an 8-bit field where each bit indicates
   support for a specific Active Measurement Protocol.  The bit
   assignments are as follows:

            +=====+==========+===============================+
            | Bit | Protocol | Reference                     |
            +=====+==========+===============================+
            | 0   | TWAMP    | [RFC5357]                     |
            +-----+----------+-------------------------------+
            | 1   | STAMP    | [RFC8762]                     |
            +-----+----------+-------------------------------+
            | 2-7 | Reserved | For future assignment by IANA |
            +-----+----------+-------------------------------+

                                 Table 1

   Bits are numbered from 0 (most significant bit) to 7 (least
   significant bit).  A bit value of 1 indicates that the endpoint
   supports the corresponding protocol for the measurement group
   identified by the Host Address.  A bit value of 0 indicates that the
   endpoint does not support that protocol.

   Multiple bits MAY be set to indicate that the endpoint supports
   multiple protocols, meaning the same interface address is used for
   multiple measurement groups.

4.  Operations

   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 measurement groups, the router MUST include one
   instance of the sub-TLV with the appropriate Protocol Flags bits set.

   If an endpoint supports multiple protocols (e.g., both TWAMP and
   STAMP), the router MAY either:

   *  Include a single sub-TLV instance with multiple Protocol Flags
      bits set, or

   *  Include multiple sub-TLV instances, each with a single Protocol
      Flags bit set.



Jethanandani, et al.      Expires 7 August 2026                 [Page 5]

Internet-Draft            IGP Measurement Group            February 2026


   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.

   The Router Capability TLV, and thus the AMP Measurement Group sub-
   TLV, is propagated across IS-IS area boundaries when area leaking is
   configured, satisfying the requirement for cross-area discovery.

   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.

5.  IANA Considerations

5.1.  IS-IS Router Capability TLV Sub-TLVs

   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.

5.2.  AMP Measurement Group Protocol Flags Registry

   IANA is requested to create a new registry called "AMP Measurement
   Group Protocol Flags" under the "Interior Gateway Protocol (IGP)
   Parameters" registry group.  The registry should track bit
   assignments for Active Measurement Protocols in the Protocol Flags
   field of the AMP Measurement Group sub-TLV.

   The initial assignments are:

              +=====+============+==========================+
              | Bit | Protocol   | Reference                |
              +=====+============+==========================+
              | 0   | TWAMP      | [RFC5357], this document |
              +-----+------------+--------------------------+
              | 1   | STAMP      | [RFC8762], this document |
              +-----+------------+--------------------------+
              | 2-7 | Unassigned |                          |
              +-----+------------+--------------------------+

                                  Table 2

   Future assignments are to be made through IETF Review [RFC8126].





Jethanandani, et al.      Expires 7 August 2026                 [Page 6]

Internet-Draft            IGP Measurement Group            February 2026


6.  Security Considerations

   This document defines a mechanism for advertising measurement group
   membership in IS-IS.  The security considerations for IS-IS as
   specified in [RFC1195] and [RFC5304] apply.

   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:

   *  Failed measurement sessions

   *  Misconfiguration of measurement infrastructure

   *  Resource exhaustion if many false endpoints are advertised

   To mitigate these risks, implementations SHOULD authenticate IS-IS
   protocol exchanges using the mechanisms defined in [RFC5304] for IS-
   IS authentication.  Additionally, operators SHOULD configure
   appropriate access controls and monitoring to detect and prevent
   unauthorized advertisements.

   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.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7883]  Ginsberg, L., Akiya, N., and M. Chen, "Advertising
              Seamless Bidirectional Forwarding Detection (S-BFD)
              Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883,
              July 2016, <https://www.rfc-editor.org/info/rfc7883>.

   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,
              <https://www.rfc-editor.org/info/rfc7981>.




Jethanandani, et al.      Expires 7 August 2026                 [Page 7]

Internet-Draft            IGP Measurement Group            February 2026


   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <https://www.rfc-editor.org/info/rfc1195>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <https://www.rfc-editor.org/info/rfc5304>.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, DOI 10.17487/RFC5357, October 2008,
              <https://www.rfc-editor.org/info/rfc5357>.

   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-Way Active Measurement Protocol", RFC 8762,
              DOI 10.17487/RFC8762, March 2020,
              <https://www.rfc-editor.org/info/rfc8762>.

Acknowledgements

   The authors would like to thank the participants in the IETF
   discussions that led to this document.

Authors' Addresses

   Mahesh Jethanandani (editor)
   Arrcus, Inc
   Street
   City, Region Postal code
   United States of America
   Phone: Phone
   Email: mjethanandani@gmail.com
   URI:   URI







Jethanandani, et al.      Expires 7 August 2026                 [Page 8]

Internet-Draft            IGP Measurement Group            February 2026


   Derek Yeung (editor)
   Arrcus, Inc
   Street
   City, Region Postal code
   United States of America
   Phone: Phone
   Email: derek@arrcus.com
   URI:   URI


   Acee Lindem (editor)
   Arrcus, Inc
   Street
   City, Region Postal code
   United States of America
   Phone: Phone
   Email: acee.ietf@gmail.com
   URI:   URI


   Reshad Rahman (editor)
   Equinix, Inc
   Street
   City Region Postal code
   Canada
   Phone: Phone
   Email: reshad@yahoo.com
   URI:   URI


   Nico Strina
   Equinix, Inc
   Street
   City, Region Postal code
   United States of America
   Phone: Phone
   Email: nstrina@equinix.com
   URI:   URI













Jethanandani, et al.      Expires 7 August 2026                 [Page 9]
