Advertising IGP Measurement Group using TLV
draft-admnr-lsr-igp-measurement-group-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mahesh Jethanandani , Derek M. Yeung , Acee Lindem , Reshad Rahman , Nico Strina | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-admnr-lsr-igp-measurement-group-02
Internet Engineering Task Force M. Jethanandani, Ed.
Internet-Draft D. Yeung, Ed.
Intended status: Standards Track A. Lindem, Ed.
Expires: 7 January 2027 Arrcus, Inc
R. Rahman, Ed.
N. Strina
Equinix, Inc
6 July 2026
Advertising IGP Measurement Group using TLV
draft-admnr-lsr-igp-measurement-group-02
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 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jethanandani, et al. Expires 7 January 2027 [Page 1]
Internet-Draft IGP Measurement Group July 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. AMP Protocol Values . . . . . . . . . . . . . . . . . . . 5
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. IS-IS Router Capability TLV Sub-TLVs . . . . . . . . . . 7
5.2. AMP Active Protocol Registry . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 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
Jethanandani, et al. Expires 7 January 2027 [Page 2]
Internet-Draft IGP Measurement Group July 2026
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 January 2027 [Page 3]
Internet-Draft IGP Measurement Group July 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 | Group ID | AMP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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.
Group ID:
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.
AMP Protocol:
1 octet. An identifier of the single Active Measurement Protocol
supported on this Group ID and IPv4/IPv6 Endpoint. Value
assignments are specified in Section 3.1.
Jethanandani, et al. Expires 7 January 2027 [Page 4]
Internet-Draft IGP Measurement Group July 2026
IPv4/IPv6 Endpoint 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 group indicated by the AMP Protocol field. This
address MAY be associated with a physical interface or a loopback
interface.
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.
3.1. AMP Protocol Values
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 |
+-------+------------+-------------------------------+
Table 1
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.
Jethanandani, et al. Expires 7 January 2027 [Page 5]
Internet-Draft IGP Measurement Group July 2026
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.
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 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.
Jethanandani, et al. Expires 7 January 2027 [Page 6]
Internet-Draft IGP Measurement Group July 2026
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 Active Protocol Registry
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 | |
+-------+------------+--------------------------+
Table 2
Future assignments are to be made through IETF Review [RFC8126].
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:
Jethanandani, et al. Expires 7 January 2027 [Page 7]
Internet-Draft IGP Measurement Group July 2026
* 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>.
[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>.
[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>.
[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>.
Jethanandani, et al. Expires 7 January 2027 [Page 8]
Internet-Draft IGP Measurement Group July 2026
[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>.
[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
2077 Gateway Place, Suite 400
San Jose, CA 95110
United States of America
Email: mjethanandani@gmail.com
URI: URI
Derek Yeung (editor)
Arrcus, Inc
2077 Gateway Place, Suite 400
San Jose, CA 95110
United States of America
Email: derek@arrcus.com
URI: URI
Jethanandani, et al. Expires 7 January 2027 [Page 9]
Internet-Draft IGP Measurement Group July 2026
Acee Lindem (editor)
Arrcus, Inc
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com
URI: URI
Reshad Rahman (editor)
Equinix, Inc
Canada
Phone: Phone
Email: reshad@yahoo.com
URI: URI
Nico Strina
Equinix, Inc
United States of America
Phone: Phone
Email: nstrina@equinix.com
URI: URI
Jethanandani, et al. Expires 7 January 2027 [Page 10]