| Internet-Draft | IGP Measurement Group | July 2026 |
| Jethanandani, et al. | Expires 7 January 2027 | [Page] |
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.¶
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 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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 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.¶
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.¶
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:¶
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.¶
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 | Group ID | AMP Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv4 or IPv6 Host Address (4 or 16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:¶
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.¶
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:¶
| Value | Protocol | Reference |
|---|---|---|
| 0 | Reserved | |
| 1 | TWAMP | [RFC5357] |
| 2 | STAMP | [RFC8762] |
| 3-255 | Unassigned | For future assignment by IANA |
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 [RFC7981], 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.¶
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.¶
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.¶
The initial assignments are:¶
| Value | Protocol | Reference |
|---|---|---|
| 0 | Reserved | this document |
| 1 | TWAMP | [RFC5357], this document |
| 2 | STAMP | [RFC8762], this document |
| 3-255 | Unassigned |
Future assignments are to be made through IETF Review [RFC8126].¶
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:¶
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.¶
The authors would like to thank the participants in the IETF discussions that led to this document.¶