Internet-Draft IGP Active Measurement Group September 2026
Jethanandani, et al. Expires 15 March 2027 [Page]
Workgroup:
Link State Routing
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Jethanandani, Ed.
Arrcus, Inc
D. Yeung, Ed.
Arrcus, Inc
A. Lindem, Ed.
Arrcus, Inc
R. Rahman, Ed.
Equinix, Inc
N. Strina
Individual

Advertising IGP Active Measurement Groups in Router Capabilities

Abstract

This document defines IGP capability advertisements for measurement group membership for Active Measurement Protocols (AMPs) such as TWAMP and STAMP. An IS-IS capability sub-TLV is defined for IS-IS and an OSPF Router Information (RI) LSA TLV is defined for OSPFv2 and OSPFv3. The mechanism allows IGP routers to discover other routers participating in different measurement groups, enabling automatic discovery of measurement endpoints throughout an IS-IS or OSPF routing domain. The solution uses a Group ID to identify measurement group membership, where the same interface address (IPv4 or IPv6) may be used for multiple measurement groups. A corresponding BGP - Link State (BGP-LS) node-level attribute is defined to distribute measurement group membership beyond a single IGP domain.

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 15 March 2027.

▲

Table of Contents

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) [RFC5357], another for STAMP (Simple Two-Way Active Measurement Protocol) [RFC8762], 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 or not the participating routers are in the same IS-IS level or OSPF area, which implies that the membership information must be flooded domain-wide.

This document defines an IS-IS capability sub-TLV and an OSPF Router Information (RI) LSA [RFC7770] TLV, similar to the seamless BFD discriminator mechanisms defined in [RFC7883] and [RFC7884], that allow routers to advertise their measurement group membership. The OSPF encoding is applicable to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. The mechanism uses Group ID to identify measurement group membership, where the interface address (IPv4 or IPv6) 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.

1.2. Terminology

This document uses the following terms:

Active Measurement Protocol (AMP):
A protocol used to actively measure performance between two IP endpoints, for example TWAMP [RFC5357] or STAMP [RFC8762].
Active Measurement Group (AMG):
A set of IP endpoints that are configured to perform active measurement with one another using a single AMP, a single IP address family, and, optionally, a set of non-default AMP parameters. An AMG is identified by a Group ID and is configured within a single administrative domain. Separate AMGs are used for different AMPs and for different address families.
Group ID:
The 2-octet identifier of an AMG, in the range 1 through 65534. A distinct Group ID is required for each AMG within the administrative domain in which the AMGs are configured.
IP endpoint (endpoint):
An IPv4 or IPv6 interface address, associated with either a physical interface or a loopback interface, through which a router participates in one or more AMGs.
AMP session:
A measurement session established between two IP endpoints of a given AMG, using the AMP associated with that AMG. An AMP session is identified by the AMG and the pair of IP endpoints.
Administrative domain:
The scope within which AMGs and their Group IDs are configured consistently. This is normally a single IGP domain; see Section 3.

The IS-IS Router CAPABILITY TLV, its S and D flags, and the associated elements of procedure are as specified in [RFC7981]. The OSPF Router Information (RI) LSA, its flooding scopes, its multiple instances, and the associated elements of procedure are as specified in [RFC7770].

In this document, "IGP" is used when the text applies to IS-IS, OSPFv2, and OSPFv3. "OSPF" is used when the text applies to both OSPFv2 and OSPFv3; OSPFv2 or OSPFv3 is used when the text is specific to one of the two protocols.

2. Use Case

At a high level, different IGP routers participate in different measurement groups. For example, measurement group 1 may be used for TWAMP, measurement group 2 for STAMP, and measurement group 3 for another purpose.

The requirements for measurement group discovery are:

3. Active Measurement Groups

Each AMG supported by an IGP router is identified by a Group ID. Each AMG has an associated IP endpoint, AMP, and IP address family. IGP routers will discover measurement partners in common AMGs identified by Group ID and attempt to establish AMP sessions in the AMG. Additionally, unique non-default parameters may be associated with an AMP. For example, the UDP ports supported by STAMP may be associated with an AMG.

AMGs and their Group IDs are configured within a single administrative domain. This is normally a single IGP domain unless inter-domain discovery is required (refer to Section 7). Each AMG will have an associated AMP and optionally non-default parameters associated with the AMG. The AMP and non-default parameters are not advertised in the IGPs as the protocol extensions specified herein are solely to discover the IP endpoints participating in the AMG. Assuring consistent configuration of the AMP and associated non-default AMP parameters is beyond the scope of this specification. Distinct AMGs are required for distinct AMPs and for distinct IP address families. It is understood that unique AMGs will also be required for unique permutations of asymmetric non-default parameters (e.g., different UDP ports for STAMP endpoints). However, this is not seen as the predominant use case.

4. IS-IS AMP Measurement Group Sub-TLV

Since loopback support is required, and there is no adjacency created over loopback interfaces to carry Application Specific Link Attribute (ASLA) information, the solution defines 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 flooded domain-wide.

This document defines a new IS-IS capability sub-TLV for advertising AMP measurement group membership. The sub-TLV is carried in the IS-IS Router CAPABILITY TLV (TLV 242) as defined in [RFC7981].

The AMP 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              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv4/IPv6 Endpoint Address (4 or 16 octets)          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: AMP Measurement Group sub-TLV Format

Fields:

Type:
TBD1 (to be assigned by IANA, see Section 8)
Length:
1 octet. The length of the value field in octets. The address family will be inferred from the length of the sub-TLV. For IPv4 addresses, the length MUST be 6. For IPv6 addresses, the length MUST be 18. A sub-TLV with a length other than 6 or 18 MUST be considered malformed. Consistent with the handling of unsupported sub-TLVs in Section 4 of [RFC7981], a receiving router MUST silently ignore such a sub-TLV and MUST continue processing the other sub-TLVs carried in the Router CAPABILITY TLV.
Group ID:
2 octets. Group ID used to associate the endpoint's membership with other routers in the AMG. An IS-IS router can advertise multiple AMP Measurement Group sub-TLVs with different Group IDs. Each AMG is associated with a single AMP and a single IP address family, so a distinct Group ID is required for each AMG within the administrative domain. The Group ID values 0 and 65535 are reserved and MUST NOT be used to identify an AMG; the range of Group IDs available to identify an AMG is 1 through 65534. A router MUST ignore an AMP Measurement Group sub-TLV advertising a reserved Group ID. These values are reserved for possible future definition of well-known Group IDs; no such Group IDs are defined by this document.
IPv4/IPv6 Endpoint Address:
4 octets for IPv4 or 16 octets for IPv6. The interface address (IPv4 or IPv6) that identifies this endpoint's usage in the measurement group indicated by the Group ID. 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, each advertising the membership of one IP endpoint in one AMG. The AMP associated with an AMG is not carried in the sub-TLV; it is determined from the local configuration of the AMG identified by the Group ID, as described in Section 3. Since an AMG is associated with a single IP address family, all AMP Measurement Group sub-TLVs advertising a given Group ID MUST carry an endpoint address of that AMG's address family; a sub-TLV whose endpoint address family does not match that of the AMG identified by the Group ID MUST be ignored. Within a single Router CAPABILITY TLV, if multiple sub-TLVs have the same Group ID and IP endpoint, only the first is used. Since two such sub-TLVs convey identical membership information, this has no effect on the resulting measurement group membership. Section 3 of [RFC7981] leaves the choice undefined when a receiving system holds two copies of a Router CAPABILITY TLV from the same system with conflicting information for a given sub-TLV; no additional procedure is defined here.

The AMP Measurement Group sub-TLV MUST be advertised in an IS-IS Router CAPABILITY TLV with the S flag set, so that the TLV is flooded across the entire routing domain as specified in Section 2 of [RFC7981]. As specified in Section 3 of [RFC7981], a router advertising capabilities with different flooding scopes originates a separate Router CAPABILITY TLV for each scope; consequently, the AMP Measurement Group sub-TLV MUST NOT be advertised in a Router CAPABILITY TLV with the S flag clear. A receiving router processes the sub-TLV as described in Section 6, subject to the elements of procedure in Section 3 of [RFC7981].

Leaking of the Router CAPABILITY TLV between IS-IS levels, including the setting of the D bit when the TLV is leaked from Level 2 to Level 1 and the prohibition on leaking a TLV with the D bit set from Level 1 to Level 2, is performed as specified in Sections 2 and 3 of [RFC7981]. This document defines no additional leaking procedures. As specified in Section 4 of [RFC7981], a router performing the leaking leaks the entire Router CAPABILITY TLV without change even if it does not support the AMP Measurement Group sub-TLV; a leaking router therefore MUST NOT remove AMP Measurement Group sub-TLVs from a TLV it leaks.

As specified in Section 2 of [RFC7981], a single IS-IS Router CAPABILITY TLV carries at most 250 octets of sub-TLVs, and more than one Router CAPABILITY TLV from the same source may be present. A router with more measurement group memberships than will fit in one TLV MUST advertise additional instances of the Router CAPABILITY TLV, each with the S flag set. A receiving router MUST process the AMP Measurement Group sub-TLVs carried in all such instances as a single set of advertisements. See [RFC9885] for the multi-part TLV semantics corresponding to the MP value registered in Section 8.

5. OSPF AMP Measurement Group TLV

For the same reasons described in Section 4, i.e., an endpoint address may be a loopback address over which no adjacency, and consequently no Application Specific Link Attribute (ASLA) advertisement, exists, the OSPF solution advertises measurement group membership in the OSPF Router Information (RI) LSA [RFC7770]. This is analogous to the advertisement of S-BFD discriminators in OSPF [RFC7884].

This document defines a new OSPF RI LSA TLV, the AMP Measurement Group TLV, for advertising AMP measurement group membership. The TLV is applicable to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. It is carried in the OSPFv2 RI Opaque LSA (Opaque type 4) or the OSPFv3 RI LSA (LSA function code 12) as specified in [RFC7770], and its format follows the OSPF RI LSA TLV format specified in Section 2.3 of [RFC7770].

The AMP Measurement Group 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            |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv4/IPv6 Endpoint Address (4 or 16 octets)          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AMP Measurement Group TLV Format

Fields:

Type:
2 octets. TBD2 (to be assigned by IANA, see Section 8)
Length:
2 octets. The length of the value field in octets. The address family is inferred from the length of the TLV. For IPv4 endpoint addresses, the length MUST be 8. For IPv6 endpoint addresses, the length MUST be 20. Since both lengths are a multiple of 4 octets, no TLV padding is required. A TLV with a length other than 8 or 20 MUST be considered malformed. A receiving router MUST ignore such a TLV and MUST continue processing the other TLVs carried in the RI LSA, consistent with the handling of unrecognized TLVs in Section 2.3 of [RFC7770].
Group ID:
2 octets. Group ID used to associate the endpoint's membership with other routers in the AMG. The semantics, reserved values, and range of the Group ID are as specified for the IS-IS AMP Measurement Group sub-TLV in Section 4. An OSPF router can advertise multiple AMP Measurement Group TLVs with different Group IDs. A router MUST ignore an AMP Measurement Group TLV advertising a reserved Group ID.
Reserved:
2 octets. This field MUST be set to zero on transmission and MUST be ignored on receipt. It is present so that the endpoint address is 4-octet aligned within the TLV.
IPv4/IPv6 Endpoint Address:
4 octets for IPv4 or 16 octets for IPv6. The interface address (IPv4 or IPv6) that identifies this endpoint's usage in the measurement group indicated by the Group ID. This address MAY be associated with a physical interface or a loopback interface. An IPv4 endpoint address MAY be advertised by an OSPFv3 router and an IPv6 endpoint address MAY be advertised by an OSPFv2 router since the endpoint address identifies an AMP endpoint and is independent of the address family of the advertising OSPF instance.

Multiple instances of this TLV MAY be included in the RI LSA, each advertising the membership of one IP endpoint in one AMG. The AMP associated with an AMG is not carried in the TLV; it is determined from the local configuration of the AMG identified by the Group ID, as described in Section 3. Since an AMG is associated with a single IP address family, all AMP Measurement Group TLVs advertising a given Group ID MUST carry an endpoint address of that AMG's address family; a TLV whose endpoint address family does not match that of the AMG identified by the Group ID MUST be ignored. If multiple TLVs advertised by the same OSPF router have the same Group ID and IP endpoint, only the first is used. Since two such TLVs convey identical membership information, this has no effect on the resulting measurement group membership.

As specified in Section 2.7 of [RFC7770], the flooding scope rules for an RI LSA TLV are specified on a per-TLV basis. Since the membership information must be flooded domain-wide, the AMP Measurement Group TLV MUST be advertised in an AS-scoped RI LSA, i.e., an OSPFv2 Opaque LSA of type 11 or an OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. AS-scoped LSAs are not flooded into stub areas or Not-So-Stubby Areas (NSSAs). Consequently, and as described in Section 2.7 of [RFC7770], a router attached to one or more stub areas or NSSAs SHOULD additionally advertise the same AMP Measurement Group TLVs in an area-scoped RI LSA, i.e., an OSPFv2 Opaque LSA of type 10 or an OSPFv3 RI LSA with the S1 bit set and the S2 bit clear, in each such area. The AMP Measurement Group TLV MUST NOT be advertised in a link-scoped RI LSA.

Section 3 of [RFC7770] requires that the processing of a TLV advertised in multiple RI LSA instances be specified in the document defining that TLV. A router with more measurement group memberships than will fit in a single RI LSA MUST advertise additional RI LSA instances, as specified in [RFC7770], with the same flooding scope. The AMP Measurement Group TLVs advertised by an OSPF router for a given flooding scope are the union of the AMP Measurement Group TLVs in all the non-MaxAge RI LSA instances advertised by that router with that flooding scope, and a receiving router MUST process them as a single set of advertisements.

A change in the information advertised in the AMP Measurement Group TLV MUST NOT trigger an SPF computation at a receiving router.

6. Operations

A router that participates in one or more AMGs MUST advertise its AMG membership. An IS-IS router MUST advertise the AMP Measurement Group sub-TLV in its Router CAPABILITY TLV as specified in Section 4, and an OSPF router MUST advertise the AMP Measurement Group TLV in its RI LSA as specified in Section 5. For each IP endpoint that participates in an AMG, the router MUST include an instance of the sub-TLV or TLV with the Group ID corresponding to that AMG.

If an endpoint participates in AMGs associated with different AMPs (e.g., one AMG for TWAMP and another for STAMP), the router advertises one sub-TLV or TLV instance per AMG, each with the corresponding Group ID. The protocols themselves are not advertised.

An AMP session is identified by the AMG and the pair of IP endpoints between which it is established. A router MUST NOT establish more than one AMP session for a given AMG between the same pair of IP endpoints. Where two routers have IP endpoints in more than one common AMG, a separate AMP session is established for each such AMG, since distinct AMGs may be associated with distinct AMPs or with distinct non-default AMP parameters.

A router MUST NOT use an AMP Measurement Group sub-TLV carried in a Router CAPABILITY TLV that, per Section 3 of [RFC7981], is not to be used: that is, one present in an LSP of a system that is not currently reachable via Level x paths, where "x" is the level in which the sending system advertised the TLV, or one whose Router ID is 0.0.0.0 with no IPv6 TE Router ID sub-TLV present. Where an AMP session has already been established as a result of such an advertisement, the receiving router SHOULD tear the session down.

Similarly, an OSPF router MUST NOT use an AMP Measurement Group TLV advertised in an RI LSA when the router that originated the LSA is not reachable via OSPF-calculated paths. For an area-scoped RI LSA, the originating router must be reachable in the area in which the LSA was received. For an AS-scoped RI LSA originated by a router in a remote area, the reachability determination described in Section 5 of [RFC5250] is used. Where an AMP session has already been established as a result of such an advertisement, the receiving router SHOULD tear the session down.

When a router receives a usable AMP Measurement Group sub-TLV, it MUST determine whether it has an IP endpoint configured as a member of the AMG identified by the Group ID, and whether the advertised endpoint address is of that AMG's address family. If either is not the case, the sub-TLV MUST be ignored. Otherwise, if no AMP session for that AMG has already been established between the two IP endpoints, the receiving router attempts to establish one. When both IP endpoints attempt to establish a session for the same AMG, the session initiated by the endpoint with the greater IP address takes precedence, where the two addresses are compared as unsigned octet strings. Since both endpoints belong to the same AMG, they are of the same address family and the comparison is therefore always between addresses of equal length.

Because the AMP Measurement Group sub-TLV is advertised in a Router CAPABILITY TLV with the S flag set, it is flooded across the entire routing domain and is leaked between levels by L1/L2 routers as specified in [RFC7981]. This satisfies the requirement for discovery of measurement group members that are not in the same IS-IS level as the advertising router. As noted in Section 4 of [RFC7981], at least one L1/L2 router in every area of the domain must support the Router CAPABILITY TLV for domain-wide flooding of TLVs originated by L1 routers to work.

Correspondingly, the AMP Measurement Group TLV is advertised in an AS-scoped OSPF RI LSA and is therefore flooded throughout the OSPF routing domain. This satisfies the requirement for discovery of measurement group members that are not in the same OSPF area as the advertising router. See Section 5 for the flooding scope rules, including the additional area-scoped advertisement required for stub areas and NSSAs.

If a router's measurement group membership changes, it MUST update its Router CAPABILITY TLV or RI LSA advertisement accordingly. An OSPF router that no longer participates in any AMG MUST originate a new RI LSA that no longer includes any AMP Measurement Group TLV; if no other TLVs remain in the LSA, it MUST either advertise an empty RI LSA or purge the LSA by prematurely aging it. Routers receiving updated information MUST process the changes and update their record of measurement group membership.

7. Inter-IGP Domain Discovery of Active Measurement Groups

With networks being divided into multiple IGP domains for scaling and operational reasons, the IP endpoints that are members of a common AMG often span IGP domains. BGP-LS [RFC9552] enables the collection and distribution of IGP link-state topology information via BGP sessions across IGP areas/levels and domains. The AMG membership of a node can thus be distributed along with the topology information across IGP domains and even across multiple Autonomous Systems (ASes) within a single administrative domain, as has been done for Segment Routing [RFC9085] and for S-BFD discriminators [RFC9247].

BGP-LS [RFC9552] specifies the Node Network Layer Reachability Information (NLRI) for the advertisement of nodes and their attributes using the BGP-LS Attribute. The AMG memberships of a node are considered a node-level attribute and are advertised as such.

This document defines a new BGP-LS Attribute TLV, the AMP Measurement Group TLV, with 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            |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|          IPv4/IPv6 Endpoint Address (4 or 16 octets)          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: BGP-LS AMP Measurement Group TLV Format

Fields:

Type:
2 octets. TBD3 (to be assigned by IANA, see Section 8)
Length:
2 octets. The length of the value field in octets. The address family is inferred from the length of the TLV. The length MUST be 8 when an IPv4 endpoint address is carried and 20 when an IPv6 endpoint address is carried. A TLV with any other length is malformed and is handled as specified for the BGP-LS Attribute in [RFC9552].
Group ID:
2 octets. The Group ID of the AMG in which the node's endpoint participates, as advertised by the originating node in the underlying IGP. The semantics, reserved values, and range of the Group ID are as specified in Section 4.
Reserved:
2 octets. This field MUST be set to zero on transmission and MUST be ignored on receipt.
IPv4/IPv6 Endpoint Address:
4 octets for IPv4 or 16 octets for IPv6. The IP endpoint through which the node participates in the AMG identified by the Group ID.

The AMP Measurement Group TLV can be added to the BGP-LS Attribute associated with the Node NLRI that originates the corresponding underlying IGP sub-TLV or TLV. This information is derived from the protocol-specific advertisements as follows:

A node may participate in multiple AMGs and may use multiple IP endpoints. Consequently, the BGP-LS Attribute associated with a Node NLRI MAY include more than one AMP Measurement Group TLV: one for each combination of Group ID and IP endpoint advertised by that node in the underlying IGP. The set of AMP Measurement Group TLVs associated with a Node NLRI reflects the set of AMG memberships advertised by that node.

The AMP and any non-default AMP parameters associated with an AMG are not carried in the BGP-LS Attribute TLV, consistent with the IGP advertisements from which it is derived. As specified in Section 3, Group IDs are configured consistently within a single administrative domain; where BGP-LS is used for inter-IGP domain discovery, that administrative domain encompasses all of the IGP domains from which the AMG membership information is collected.

The protocol extensions introduced in this section augment the existing IGP topology information that is distributed via BGP-LS [RFC9552]. The procedures and protocol extensions defined in this document do not affect BGP protocol operations and management other than as discussed in the Manageability Considerations of [RFC9552]. Specifically, the malformed NLRI attribute tests in the Fault Management considerations of [RFC9552] now encompass the new TLV defined in this section.

8. IANA Considerations

8.1. IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV

IANA is requested to assign a new sub-TLV type from the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry in the "IS-IS TLV Codepoints" registry group for the AMP Measurement Group sub-TLV defined in Section 4 of this document. The registration procedure for this registry is Expert Review [RFC8126]; guidance for the IESG-designated experts is provided in [RFC7370]. The requested value is from the unassigned range 31-160.

Table 1: AMP Measurement Group Sub-TLV Registration
Value Description MP Reference
TBD1 AMP Measurement Group y This document

The MP column is set to "y" since the AMP Measurement Group sub-TLVs advertised by a router may be distributed across multiple instances of the IS-IS Router CAPABILITY TLV as specified in [RFC9885] and Section 4 of this document.

Early allocation of this codepoint in accordance with [RFC7120] is requested.

[RFC Editor: please replace TBD1 with the value assigned by IANA, both in Table 1 and in Section 4, and remove this note.]

8.2. OSPF Router Information (RI) TLVs

IANA is requested to assign a new TLV type from the "OSPF Router Information (RI) TLVs" registry in the "Open Shortest Path First (OSPF) Parameters" registry group for the AMP Measurement Group TLV defined in Section 5 of this document. The registration procedure for the 1-32767 range of this registry is IETF Review [RFC8126], as specified in Section 5.3 of [RFC7770]. The requested value is from the unassigned portion of that range.

Table 2: AMP Measurement Group TLV Registration
Value TLV Name Reference
TBD2 AMP Measurement Group This document

Early allocation of this codepoint in accordance with [RFC7120] is requested.

[RFC Editor: please replace TBD2 with the value assigned by IANA, both in Table 2 and in Section 5, and remove this note.]

IANA is requested to allocate a new code point from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group for the AMP Measurement Group TLV defined in Section 7 of this document. The column "IS-IS TLV/Sub-TLV" defined in the registry does not require any value and should be left empty.

Table 3: BGP-LS AMP Measurement Group TLV Code Point Allocation
TLV Code Point Description Reference
TBD3 AMP Measurement Group This document

Early allocation of this codepoint in accordance with [RFC7120] is requested.

[RFC Editor: please replace TBD3 with the value assigned by IANA, both in Table 3 and in Section 7, and remove this note.]

9. Security Considerations

This document defines mechanisms for advertising measurement group membership in IS-IS and OSPF. The security considerations for IS-IS as specified in [ISO10589] and [RFC1195] apply, as do the security considerations for OSPFv2 [RFC2328], OSPFv3 [RFC5340], the OSPF Opaque LSA option [RFC5250], and the OSPF RI LSA [RFC7770].

An attacker that can inject false AMP Measurement Group sub-TLVs or TLVs could cause routers to attempt to establish measurement sessions with incorrect endpoints, potentially leading to:

To mitigate these risks, and as recommended in Section 5 of [RFC7981] for information carried in the Router CAPABILITY TLV, an integrity mechanism such as those specified in [RFC5304] or [RFC5310] SHOULD be applied to IS-IS protocol exchanges. Correspondingly, an authentication mechanism such as those specified in [RFC5709] for OSPFv2 or in [RFC4552] or [RFC7166] for OSPFv3 SHOULD be applied to OSPF protocol exchanges. 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 and 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. Since the IS-IS sub-TLV is advertised with the S flag set and the OSPF TLV is advertised in an AS-scoped RI LSA, this information is flooded throughout the routing domain rather than being confined to the level or area in which it originates, which widens the set of routers to which it is disclosed. Operators should consider the implications of this information disclosure when deploying this mechanism.

The BGP-LS extension defined in Section 7 augments the existing IGP topology information that can be distributed via BGP-LS [RFC9552]. It does not affect the BGP security model other than as discussed in the Security Considerations of [RFC9552], i.e., the aspects related to limiting the nodes and consumers with which the topology information is shared via BGP-LS to trusted entities within an administrative domain. The IGP instances originating this information are assumed to support the security and authentication mechanisms described above. Additionally, since this information identifies the IP endpoints used for active measurement, distributing it via BGP-LS widens the scope of the information disclosure discussed in the preceding paragraph beyond a single IGP domain, and makes it possible for an attacker with access to the BGP-LS information to attempt to establish AMP sessions with the advertised endpoints.

10. References

10.1. Normative References

[ISO10589]
International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, .
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328]
Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, , <https://www.rfc-editor.org/info/rfc2328>.
[RFC4552]
Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, , <https://www.rfc-editor.org/info/rfc4552>.
[RFC5250]
Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, , <https://www.rfc-editor.org/info/rfc5250>.
[RFC5304]
Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, , <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310]
Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, , <https://www.rfc-editor.org/info/rfc5310>.
[RFC5340]
Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, , <https://www.rfc-editor.org/info/rfc5340>.
[RFC5709]
Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, , <https://www.rfc-editor.org/info/rfc5709>.
[RFC7166]
Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, , <https://www.rfc-editor.org/info/rfc7166>.
[RFC7770]
Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, , <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981]
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, , <https://www.rfc-editor.org/info/rfc7981>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9552]
Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, , <https://www.rfc-editor.org/info/rfc9552>.
[RFC9885]
Kaneriya, P., Li, T., Przygienda, A., Hegde, S., and L. Ginsberg, "Multi-Part TLVs in IS-IS", RFC 9885, DOI 10.17487/RFC9885, , <https://www.rfc-editor.org/info/rfc9885>.

10.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, , <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, , <https://www.rfc-editor.org/info/rfc5357>.
[RFC7120]
Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, , <https://www.rfc-editor.org/info/rfc7120>.
[RFC7370]
Ginsberg, L., "Updates to the IS-IS TLV Codepoints Registry", RFC 7370, DOI 10.17487/RFC7370, , <https://www.rfc-editor.org/info/rfc7370>.
[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, , <https://www.rfc-editor.org/info/rfc7883>.
[RFC7884]
Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, "OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators", RFC 7884, DOI 10.17487/RFC7884, , <https://www.rfc-editor.org/info/rfc7884>.
[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, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8762]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <https://www.rfc-editor.org/info/rfc8762>.
[RFC9085]
Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, , <https://www.rfc-editor.org/info/rfc9085>.
[RFC9247]
Li, Z., Zhuang, S., Talaulikar, K., Ed., Aldrin, S., Tantsura, J., and G. Mirsky, "BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 9247, DOI 10.17487/RFC9247, , <https://www.rfc-editor.org/info/rfc9247>.

Acknowledgements

Thanks to Rakesh Gandhi for discussion of requirements.

Authors' Addresses

Mahesh Jethanandani (editor)
Arrcus, Inc
2077 Gateway Place, Suite 400
San Jose, CA 95110
United States of America
Derek Yeung (editor)
Arrcus, Inc
2077 Gateway Place, Suite 400
San Jose, CA 95110
United States of America
Acee Lindem (editor)
Arrcus, Inc
301 Midenhall Way
Cary, NC 27513
United States of America
Reshad Rahman (editor)
Equinix, Inc
Canada
Nico Strina
Individual
United States of America