Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members

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 2 April 2027.¶

Copyright Notice

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

Table of Contents

1. Introduction

BGP Link State (BGP-LS) [RFC9552] is widely used for collecting topology information from Interior Gateway Protocols (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 Open Shortest Path First (OSPF) [RFC9356] and Intermediate System to Intermediate System (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 L2 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.¶

2. Use Case

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 L2 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 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 controller can then correlate the member links at the two ends of the L2 bundle: as specified in Section 7, the remote identifier advertised by one router for a bundle member equals the local identifier advertised by its neighbor for that same member, so a remote identifier advertised at one end matches the local identifier advertised at the other end.¶

An absent remote identifier means that the value is not learned or not advertised for that member; it does not indicate that the peer has no corresponding member. In particular, when one endpoint of the L2 bundle implements the extension described in this document and the other endpoint does not, the members advertised by the endpoint that supports the extension will not carry remote identifiers.¶

3. Advertising L2 Bundle Member Remote Interface Identifier

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 Layer 3 (L3) link (i.e., the logical link directly operated on by the L3 protocol, as distinguished from the individual L2 bundle member links which are not directly visible to L3).¶

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 attribute objects (the L2 Bundle Member Attributes Type-Length-Value (TLV) for IS-IS and BGP-LS, and the L2 Bundle Member Attributes sub-TLV for OSPF) and of their 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.¶

L2 Bundle Member Attributes sub-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 sub-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 sub-TLV:
  L2 Bundle Member Descriptor of Member #n
  L2 Bundle Member Interface Remote Identifier sub-TLV (Optional -
    as defined in Section 4)

L2 Bundle Member Attributes TLV:
  Parent L3 Neighbor Descriptor
  L2 Bundle Attribute Descriptor (one or more may be present):
    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

BGP-LS Link NLRI: The parent L3 link for R1->R2 (as described in
    Section 2.2.3 of [RFC9085])
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)

4. OSPF Extension

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 an L2 bundle member.¶

It can be carried as a sub-TLV of the OSPF L2 Bundle Member Attributes sub-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                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBA (to be assigned from the "OSPFv2 Extended Link TLV Sub-TLVs" registry and the "OSPFv3 Extended-LSA Sub-TLVs" registry).¶

Length:

4.¶

Remote Interface ID:

Remote identifier of interface, 4 octets. See Section 7 for the definition of the remote interface identifier.¶

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. An originator MUST NOT advertise a value of zero for the Remote Interface ID, since a value of zero is reserved to indicate that the remote interface identifier is unknown, consistent with the Link Local Identifier defined in [RFC4202] (see Section 7).¶

If the Length of this sub-TLV is not 4, the sub-TLV MUST be ignored and handled as if it 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 sub-TLV. If multiple instances of this sub-TLV are received within the same L2 Bundle Member Attributes sub-TLV, implementations MUST use the first occurrence and ignore subsequent occurrences.¶

5. IS-IS Extension

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                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBA (to be assigned from the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry).¶

Length:

A non-zero multiple of 4: 4 * Number of L2 Bundle Member Descriptors in the enclosing L2 Bundle Attribute Descriptor.¶

Remote Interface ID:

Remote identifier of interface, 4 octets. See Section 7 for the definition of the remote interface identifier.¶

The number of Remote Interface IDs carried in this sub-TLV MUST equal the Number of L2 Bundle Member Descriptors advertised in the enclosing L2 Bundle Attribute Descriptor. The Remote Interface IDs are ordered such that the first Remote Interface ID corresponds to the first L2 Bundle Member Descriptor listed in the L2 Bundle Attribute Descriptor, the second Remote Interface ID corresponds to the second L2 Bundle Member Descriptor, and so on. A remote interface ID with value of zero MUST be ignored and handled as if the value was unknown.¶

If the Length of this sub-TLV is zero or is not a multiple of 4, or if the number of Remote Interface IDs it carries does not equal the Number of L2 Bundle Member Descriptors in the enclosing L2 Bundle Attribute Descriptor, the sub-TLV MUST be ignored and handled as if it was not present (i.e., the remote identifiers of all the bundle members in that descriptor are treated as unknown).¶

The L2 Bundle Member Interface Remote Identifier sub-TLV MUST NOT appear more than once within the sub-TLV set of a single L2 Bundle Attribute Descriptor. If multiple instances of this sub-TLV are received within the same L2 Bundle Attribute Descriptor (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.¶

A value of zero in a Remote Interface ID is permitted only as a positional placeholder indicating that the remote identifier for the corresponding bundle member is unknown; it MUST NOT be used with any other meaning. As described in Section 7, when the remote identifier of every bundle member in an L2 Bundle Attribute Descriptor is unknown, the originator SHOULD omit the sub-TLV entirely rather than advertise zero for each member.¶

The L2 Bundle Attribute Descriptor has a one-octet Length field, and the Number of L2 Bundle Member Descriptors field is also one octet; the sub-TLV space available for this sub-TLV within an L2 Bundle Attribute Descriptor is therefore bounded. When the remote identifiers for a set of bundle members do not fit within these one-octet limits (including the sub-TLV header), the originator SHOULD split the members across multiple L2 Bundle Attribute Descriptors within the same L2 Bundle Member Attributes TLV, with each instance of this sub-TLV covering the members of its associated descriptor.¶

The Multi-Part TLV (MP-TLV) applicability [RFC9885] for the new IS-IS sub-TLV is N (MP-TLV procedures are not applicable to this sub-TLV).¶

6. BGP-LS Extension

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 4) and IS-IS (Section 5).¶

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                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBA (to be assigned from the "BGP-LS NLRI and Attribute TLVs" registry).¶

Length:

4.¶

Remote Interface ID:

Remote identifier of interface, 4 octets. See Section 7 for the definition of the remote interface identifier.¶

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

The L2 Bundle Member Attributes TLV (type 1172) carrying this sub-TLV is associated with the Link NLRI that describes the parent L3 link.¶

An L2 Bundle Member Descriptor and its L2 Bundle Member Interface Remote Identifier sub-TLV advertised in OSPF (Section 4) map one-to-one to an L2 Bundle Member Attributes TLV instance in BGP-LS. For IS-IS (Section 5), the ordered list of Remote Interface IDs carried in a single sub-TLV instance maps positionally to the ordered list of L2 Bundle Member Link Local Identifiers advertised under the associated L2 Bundle Attribute Descriptor, and each member and its remote identifier are exported in the corresponding L2 Bundle Member Attributes TLV instance in BGP-LS.¶

A member whose remote identifier is unknown, or which is advertised with a value of zero in IS-IS as described in Section 7, is exported without the L2 Bundle Member Interface Remote Identifier sub-TLV in the corresponding L2 Bundle Member Attributes TLV instance; a value of zero is never exported in BGP-LS.¶

With respect to the roles defined in Section 3 of [RFC9552], a BGP-LS Producer originates this sub-TLV as part of the BGP-LS Attribute of the Link NLRI describing the parent L3 link, following the mapping described above. A BGP-LS Propagator does not perform semantic validation of this sub-TLV and does not remove it due to semantic or syntactic length mismatches beyond the 'Attribute Discard' fault handling defined in Section 8.2.2 of [RFC9552]. Semantic validation of the sub-TLV (e.g., consistency checking as described in Section 7) is performed by the BGP-LS Consumer, and the handling of any resulting errors is specific to the application and outside the scope of this document.¶

7. Acquisition of the Remote Interface Identifier

The routers at both ends of the L2 bundle independently assign a non-zero 32-bit identifier to each of their bundle members and advertise it as the L2 Bundle Member Link Local Identifier in the L2 Bundle Member Descriptor ([RFC9356], [RFC8668]), consistent with the Link Local Identifier defined in [RFC4202].¶

The remote interface identifier advertised by a router for a bundle member MUST be the exact non-zero 32-bit value that the neighboring router advertises as the L2 Bundle Member Link Local Identifier for that same bundle member. In other words, if R1 advertises remote identifier X for its local member with identifier A, then R2 (the neighbor) advertises local identifier X for that member, and symmetrically R2 advertises remote identifier A for its local member with identifier X. This relationship ensures that a controller can correlate the advertisements from the two ends of each member link.¶

IGPs provide no direct way for a router to learn the identifiers assigned by its neighbor to the individual bundle members, since the L3 protocol does not operate on the bundle members. The acquisition of the exact remote identifier value is therefore outside the scope of this document. Implementations MAY obtain the value through configuration or through implementation-specific discovery procedures. L2 protocols such as the Link Layer Discovery Protocol (LLDP) ([IEEE802.1AB]) and the Link Aggregation Control Protocol (LACP) ([IEEE802.1AX]) allow a router to discover the identity of the neighboring port on each member link, and implementations MAY use them as part of such procedures. Note, however, that the identifiers carried by these protocols are not required to match the L2 Bundle Member Link Local Identifiers advertised by the neighbor: the LLDP Port ID is subtype-dependent and is not necessarily a 32-bit numeric value, and the LACP Actor and Partner Port Numbers are 16-bit values assigned independently by each end. Any mapping between the identifiers discovered via these protocols and the neighbor's advertised L2 Bundle Member Link Local Identifiers is implementation-specific.¶

To verify the correctness of the acquired remote identifiers, implementations SHOULD provide mechanisms to validate that received advertisements are consistent with the relationship defined above, i.e., that the value advertised as the remote identifier for a member equals the value advertised as the L2 Bundle Member Link Local Identifier for the corresponding member by the neighboring router. Mismatched pairs may indicate misconfiguration or incorrect discovery.¶

8. Operational Considerations

Implementations MUST NOT enable the advertisement of the L2 Bundle Member Interface Remote Identifier sub-TLV by default and MUST provide a configuration option to enable its advertisement on specific links.¶

9. Security Considerations

This document describes how OSPF, IS-IS and BGP-LS would advertise the remote interface identifiers for L2 bundle members. The security considerations of [RFC8668], [RFC9356], [RFC9552], [RFC9085] and [RFC9086] are applicable to this document. In addition, the acquisition of the remote interface identifiers specified in Section 7 introduces the trust considerations described below.¶

The advertisement of the remote interface identifier introduces a new trust boundary. IGP authentication protects the advertisement once the originating router has created it, but it does not authenticate the local L2 information from which the router obtained the remote member mapping. As described in Section 7, the value of the remote identifier may be acquired through configuration or through implementation-specific discovery procedures that may rely on L2 protocols such as LLDP and LACP. The trust placed in these acquisition mechanisms therefore directly affects the trustworthiness of the information advertised by this document.¶

A spoofed, stale, or inconsistent mapping produced by the acquisition mechanism could cause a router to advertise a false remote interface identifier and thus create a false association between the member links at the two ends of the L2 bundle. A controller that consumes this information for TE or failure correlation might then steer traffic onto member links that are not actually connected or misdiagnose the scope of a failure. To limit the impact of stale information, an originator MUST NOT continue to advertise a remote identifier that it knows to be no longer valid and SHOULD withdraw or replace the value when its source changes or ages out, as specified in Section 7.¶

The relationship between the local and remote identifiers is reciprocal as defined in Section 7: the remote identifier advertised by one router for a bundle member MUST equal the local identifier advertised by its neighbor for that same member. Recipients such as a BGP-LS Consumer can use this reciprocity to validate the mapping. As noted in Section 7, implementations SHOULD provide mechanisms to validate received advertisements against this relationship; mismatched pairs may indicate misconfiguration, incorrect discovery, or tampering with the acquisition mechanism.¶

Advertising the remote interface identifier exposes additional topology detail beyond that provided by the advertisements specified in [RFC8668], [RFC9356], and [RFC9085]: it reveals the pairing of the individual member links between the two ends of the L2 bundle. An operator who considers this detail sensitive should take it into account when deciding whether to enable the advertisement (see Section 8). The isolation of BGP-LS peering sessions is recommended to ensure that BGP-LS topology information (including the newly added remote interface identifier information) is not advertised to an external BGP peering session outside the trusted domain, as described in Section 10 of [RFC9552].¶

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

10. IANA Considerations

This document adds the following new sub-TLV to the "OSPFv2 Extended Link TLV Sub-TLVs" registry. The L2 Bundle Member (L2BM) column indicates whether the sub-TLV MAY appear ("Y") or MUST NOT appear ("N") within the L2 Bundle Member Attributes sub-TLV [RFC9356].¶

+------+----------------------------------------------+----+
| 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. In this registry, the "L2BM" column has an additional value "X", which indicates that a sub-TLV is not a sub-TLV of the Router-Link TLV and MUST NOT appear within the L2 Bundle Member Attributes sub-TLV.¶

+------+----------------------------------------------+----+
| 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 |
+------+----------------------------------------------+

11. Acknowledgements

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

Contributors

Authors' Addresses