| Internet-Draft | L2 Bundle Member Remote ID | August 2026 |
| Gong, et al. | Expires 23 February 2027 | [Page] |
In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) as defined in IEEE 802.1AX) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. For example, when performing topology management and bidirectional path computation for TE, it is essential to know the connectivity relationships among bundle members.¶
This document describes how OSPF and IS-IS would advertise the remote interface identifiers for Layer 2 bundle members. The corresponding extension of BGP Link State (BGP-LS) is also specified.¶
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 23 February 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.¶
BGP Link State (BGP-LS) [RFC9552] is widely used for collecting topology information from IGPs. In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) [IEEE802.1AX]) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. For example, when performing topology management and bidirectional path computation for TE (e.g., for a co-routed associated bidirectional path as defined in Section 2.2.2 of [RFC8537] or Section 3.3 of [RFC9059]), knowledge of the connectivity relationships among bundle members is required.¶
When advertising L2 bundles in OSPF [RFC9356] and IS-IS [RFC8668], a member link is described by its local interface identifier, also referred to as a link local identifier. If the remote interface identifier could be advertised for each member link, the pairing relationships between the local and remote interfaces would be clear.¶
This document describes the mechanism for advertising the remote interface identifier for Layer 2 bundle members in OSPF and IS-IS. The BGP-LS extension for advertising L2 bundle member interface remote identifier is also specified in this document.¶
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.¶
Figure 1 shows a network, in which an L2 bundle is deployed between R1 and R2. The controller collects the topology information from R3 via BGP-LS.¶
+----------+ BGP-LS
|Controller|<-------------------+
+----------+ |
|
|
|
+----+ L2-Bundle +----+ +-+--+
| | /-------member 1-------\ | | | |
| | / \ | | | |
| R1 +----------member 2----------+ R2 +---+ R3 |
| | \ / | | | |
| | \-------member 3-------/ | | | |
+----+ +----+ +----+
The network operator may want to control bidirectional traffic flows on the individual member links of the underlying Layer 2 bundle for TE purposes. The real-time bandwidth, delay, and link loss might be measured for each bundle member at both ends. Labels or Segment Identifiers (SIDs) might be allocated for each bundle member at both ends. So, there would be requirements for the controller to figure out the connectivity relationships between bundle members.¶
This document defines a mechanism for Interior Gateway Protocol (IGP) routers to advertise the remote interface identifiers for each L2 bundle member, along with the corresponding mechanism for the controller to collect such information via BGP-LS.¶
The routers at both ends of the LAG (e.g., R1 and R2 in Figure 1) independently advertise their local member interface information along with the corresponding remote interface identifiers.¶
The following subsections describe how the remote interface identifiers of L2 bundle members are advertised in OSPF, IS-IS, and BGP-LS, respectively. The L2 bundle member information is advertised in association with the parent L3 link (i.e., the logical link directly operated on by the Layer 3 protocol, as distinguished from the individual L2 bundle member links which are not directly visible to Layer 3).¶
The descriptions in this section are intended to be illustrative and are not meant to be normative. The normative definitions of the L2 Bundle Member Attributes TLV and its sub-TLVs are provided in [RFC9356] for OSPF, [RFC8668] for IS-IS, and [RFC9085] for BGP-LS. Note that the term "sub-TLV" is used throughout this document (consistent with the referenced RFCs) to refer to TLVs that are nested within a parent TLV.¶
In OSPF, the remote interface identifiers of L2 bundle members are advertised as follows.¶
OSPFv2 Extended Link TLV, or OSPFv3 Router-Link TLV, for the parent L3 link:¶
L2 Bundle Member Attributes TLV:
L2 Bundle Member Descriptor of Member #1
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 4)
L2 Bundle Member Attributes TLV:
L2 Bundle Member Descriptor of Member #2
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 4)
...
L2 Bundle Member Attributes TLV:
L2 Bundle Member Descriptor of Member #n
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 4)
¶
In IS-IS, the remote interface identifiers of L2 bundle members are advertised as follows. Note that IS-IS can advertise a set of members in a single L2 Bundle Member Attribute Descriptor, so the L2 Bundle Member Interface Remote Identifier sub-TLV MUST carry multiple remote interface identifiers, one for each of the bundle members advertised in the associated L2 Bundle Member Descriptor.¶
L2 Bundle Member Attributes TLV:
Parent L3 Neighbor Descriptor
Length of L2 Bundle Attribute Descriptor
Number of L2 Bundle Member Descriptors
L2 Bundle Member Link Local Identifiers of Member #1,#2,...,#n
sub-TLV(s)
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 5) for Member #1,#2,...,#n
¶
In BGP-LS, the remote interface identifiers of L2 bundle members are advertised as follows.¶
BGP-LS Link NLRI: Peer Adj Link for R1->R2 (as described in Section
5.2 of [RFC9086])
Link Attributes:
L2 Bundle Member Attributes TLV:
L2 Bundle Member Descriptor of Member #1
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 6)
L2 Bundle Member Attributes TLV:
L2 Bundle Member Descriptor of Member #2
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 6)
...
L2 Bundle Member Attributes TLV:
L2 Bundle Member Descriptor of Member #n
L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
as defined in Section 6)
¶
This document defines a new L2 Bundle Member Interface Remote Identifier sub-TLV in both OSPFv2 and OSPFv3. This sub-TLV is used to advertise the remote interface identifier for a L2 bundle member.¶
It can be carried as a sub-TLV of the OSPF L2 Bundle Member Attributes TLV [RFC9356]. It 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 (TBA) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
A remote interface ID with value of zero is not valid and MUST be ignored and handled as if the sub-TLV was not present.¶
The L2 Bundle Member Interface Remote Identifier sub-TLV MUST NOT appear more than once within the same L2 Bundle Member Attributes TLV. If multiple instances of this sub-TLV are received within the same L2 Bundle Member Attributes TLV, implementations MUST use the first occurrence and ignore subsequent occurrences.¶
This document defines a new L2 Bundle Member Interface Remote Identifier sub-TLV in IS-IS. This sub-TLV is used to advertise the remote interface identifiers for L2 bundle members.¶
It can be carried as a sub-TLV of the IS-IS L2 Bundle Member Attributes TLV [RFC8668]. It 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 (TBA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
There MUST be one Remote Interface ID for each of the L2 Bundle Members advertised under the associated L2 Bundle Member Attribute Descriptor. The Remote Interface IDs are ordered such that the first Remote Interface ID corresponds to the first bundle member listed in the L2 Bundle Member Descriptor, the second Remote Interface ID corresponds to the second bundle member, and so on. A remote interface ID with value of zero MUST be ignored and handled as if the value was unknown.¶
The L2 Bundle Member Interface Remote Identifier sub-TLV MUST NOT appear more than once within the same L2 Bundle Member Attributes TLV. If multiple instances of this sub-TLV are received within the same L2 Bundle Member Attributes TLV (e.g., during transient conditions), implementations MUST use the first occurrence in the lowest numbered Link State Protocol Data Unit (LSP) fragment and ignore subsequent occurrences.¶
MP-TLV [RFC9885] for the new IS-IS sub-TLV SHOULD be set to "N".¶
This document defines a new L2 Bundle Member Interface Remote Identifier sub-TLV in BGP-LS. This sub-TLV is derived from the Remote Interface Identifier sub-TLV of OSPF (Section 3) and IS-IS (Section 4).¶
It can be carried as a sub-TLV of the BGP-LS L2 Bundle Member Attributes TLV [RFC9085]. It 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 (TBA) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
A remote interface ID with value of zero is not valid and MUST be ignored and handled as if the sub-TLV was not present.¶
The L2 Bundle Member Interface Remote Identifier sub-TLV MUST NOT appear more than once within the same L2 Bundle Member Attributes TLV. If multiple instances of this sub-TLV are received within the same L2 Bundle Member Attributes TLV, implementations MUST use the first occurrence and ignore subsequent occurrences.¶
IGPs have no direct way to exchange L2 bundle member link identifiers since the Layer 3 protocol is not operating directly on the bundle members. The remote interface identifiers can be obtained via Layer 2 protocols as described below.¶
The remote interface identifier is the value of the interface identifier that is assigned by the router at the remote end of the link to its own local interface (i.e., the local interface identifier of the remote router for that bundle member). The interface identifier is defined in [RFC4202].¶
The RECOMMENDED method for acquiring remote interface identifiers is to use LLDP (Link Layer Discovery Protocol, [IEEE802.1AB]). When LLDP is enabled on bundle members, each router can learn the neighbor's port identifier from the Port ID TLV in LLDP frames. This port identifier SHOULD be used as the remote interface identifier in the advertisements described in this document.¶
Alternatively, the remote interface identifiers MAY be obtained through IEEE 802.1AX ([IEEE802.1AX]) Link Aggregation Control Protocol (LACP) negotiation, where the Actor and Partner Port Identifiers can be used to derive the remote interface identifiers.¶
To verify the correctness of the acquired remote interface identifiers, implementations SHOULD provide mechanisms to validate that the identifier pairs are consistent. For example, if R1 advertises remote ID X for its local member with ID A, then R2 (the neighbor) SHOULD advertise remote ID A for its local member with ID X. Mismatched pairs may indicate misconfiguration or incorrect discovery.¶
Implementations MUST NOT enable the advertisement of L2 bundle member Interface Remote Identifier sub-TLV by default and MUST provide a configuration option to enable their advertisement on specific links.¶
This document describes how OSPF, IS-IS and BGP-LS would advertise the remote interface identifiers for Layer 2 bundle members. There are no new security issues introduced by the extensions in this document. The security considerations of [RFC8668], [RFC9356], [RFC9552], [RFC9085] and [RFC9086] are applicable to this document.¶
If the IS-IS protocol is used in an environment where unauthorized access to the physical links on which IS-IS Protocol Data Units (PDUs) are sent occurs, then attacks are possible. The use of authentication as defined in [RFC5304] and [RFC5310] is recommended to prevent such attacks.¶
If the OSPF protocol is used in an environment where unauthorized access to the physical links on which OSPF packets are sent occurs, then attacks are possible. The use of authentication as defined in [RFC5709], [RFC7474], [RFC4552], and [RFC7166] is recommended for preventing such attacks.¶
The isolation of BGP-LS peering sessions is recommended to ensure that BGP-LS topology information (including the newly added remote interface identifiers information) is not advertised to an external BGP peering session outside the trusted domain [RFC8402].¶
This document adds the following new sub-TLV to the "OSPFv2 Extended Link TLV Sub-TLVs" registry.¶
+------+----------------------------------------------+----+ | Type | Designation |L2BM| +======+==============================================+====+ | TBA | L2 Bundle Member Interface Remote Identifier | Y | +------+----------------------------------------------+----+¶
This document adds the following new sub-TLV to the "OSPFv3 Extended-LSA Sub-TLVs" registry.¶
+------+----------------------------------------------+----+ | Type | Description |L2BM| +======+==============================================+====+ | TBA | L2 Bundle Member Interface Remote Identifier | Y | +------+----------------------------------------------+----+¶
This document adds the following new sub-TLV to the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry.¶
+------+-----------------------------+---+---+---+---+---+---+---+ | Type | Description | 22| 23| 25|141|222|223| MP| +======+=============================+===+===+===+===+===+===+===+ | TBA | L2 Bundle Member | n | n | y | n | n | n | n | | | Interface Remote Identifier | | | | | | | | +------+-----------------------------+---+---+---+---+---+---+---+¶
This document adds the following new sub-TLV to the "BGP-LS NLRI and Attribute TLVs" registry.¶
+------+----------------------------------------------+ | Type | Description | +======+==============================================+ | TBA | L2 Bundle Member Interface Remote Identifier | +------+----------------------------------------------+¶
The authors would like to thank Acee Lindem for his shepherd review and helpful comments to improve this document.¶
The authors would like to thank Michael Richardson for RTGDIR early review.¶
The authors would also like to thank Shraddha Hegde, and Tom Petch for their review of this document and their comments.¶