Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members
draft-ietf-lsr-l2-bundle-member-remote-id-12

LSR Working Group                                                L. Gong
Internet-Draft                                              China Mobile
Intended status: Standards Track                                  C. Lin
Expires: 2 May 2027                                                X. Hu
                                                    New H3C Technologies
                                                             L. Ginsberg
                                                               P. Psenak
                                                           Cisco Systems
                                                         29 October 2026

Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members
              draft-ietf-lsr-l2-bundle-member-remote-id-12

Abstract

   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.  This document
   describes how Open Shortest Path First (OSPF) and Intermediate System
   to Intermediate System (IS-IS) advertise the remote interface
   identifiers for L2 bundle members.  The corresponding extension of
   BGP Link State (BGP-LS) is also specified.

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 May 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Gong, et al.               Expires 2 May 2027                   [Page 1]
Internet-Draft         L2 Bundle Member Remote ID           October 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.  Advertising L2 Bundle Member Remote Interface Identifier  . .   4
     3.1.  OSPF Advertisement  . . . . . . . . . . . . . . . . . . .   5
     3.2.  IS-IS Advertisement . . . . . . . . . . . . . . . . . . .   5
     3.3.  BGP-LS Advertisement  . . . . . . . . . . . . . . . . . .   6
   4.  OSPF Extension  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IS-IS Extension . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  BGP-LS Extension  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acquisition of the Remote Interface Identifier  . . . . . . .  11
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

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

Gong, et al.               Expires 2 May 2027                   [Page 2]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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.  These IGP advertisements are also the source of the
   corresponding BGP-LS advertisements ([RFC9085]); advertising the
   remote interface identifier in the IGP therefore allows the pairing
   relationship to be conveyed to a controller via BGP-LS along with the
   other L2 bundle member attributes.  A management system could
   alternatively retrieve the connectivity relationships between bundle
   members directly from the routers; describing such a management-based
   approach is outside the scope of this document.

   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.

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

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

                 Figure 1: Network Topology with L2 Bundle

Gong, et al.               Expires 2 May 2027                   [Page 3]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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.  The controller therefore needs to determine 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.

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.

Gong, et al.               Expires 2 May 2027                   [Page 4]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

3.1.  OSPF Advertisement

   In OSPF, the remote interface identifiers of L2 bundle members are
   advertised as follows.

   OSPFv2 Extended Link TLV [RFC7684], or OSPFv3 Router-Link TLV
   [RFC8362], for the parent L3 link:

   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)

3.2.  IS-IS Advertisement

   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 Attribute Descriptor, so the L2 Bundle
   Member Interface Remote Identifier sub-TLV carries multiple remote
   interface identifiers, one for each bundle member advertised in the
   associated L2 Bundle Attribute Descriptor.

   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

Gong, et al.               Expires 2 May 2027                   [Page 5]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

3.3.  BGP-LS Advertisement

   In BGP-LS, the remote interface identifiers of L2 bundle members are
   advertised in the BGP-LS Link Network Layer Reachability Information
   (Link NLRI) as follows.  As specified in Section 2.2.3 of [RFC9085],
   the L2 Bundle Member Attributes TLV is associated with the Link NLRI
   that describes the parent L3 link.

   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.

Gong, et al.               Expires 2 May 2027                   [Page 6]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   Remote Interface ID:  4 octets of a remote interface identifier.  See
      Section 7 for the acquisition of the remote interface identifier.

   A receiver first associates this sub-TLV with the bundle member
   identified by the enclosing L2 Bundle Member Attributes sub-TLV.
   After this association, a remote interface ID with value of zero is
   not valid and MUST be ignored and handled by the receiver as if the
   sub-TLV was not present (i.e., the remote identifier of that member
   is treated as unknown).  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/remote identifier semantics for
   unnumbered links defined in Section 2.1 of [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).

Gong, et al.               Expires 2 May 2027                   [Page 7]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

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

   Remote Interface ID:  4 octets of a remote interface identifier.  See
      Section 7 for the acquisition 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 receiver MUST
   first associate each Remote Interface ID with the corresponding L2
   Bundle Member Descriptor based on this positional ordering.  In cases
   where the remote interface IDs are known for some but not all of the
   bundle members, the sub-TLV is present but the entries corresponding
   to bundle members for which the remote interface IDs are unknown MUST
   have a value of zero.

   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 is not a
   shared attribute sub-TLV as defined in Section 3.2 of [RFC8668]; it
   advertises one remote interface identifier for each of the bundle
   members listed in the enclosing L2 Bundle Attribute Descriptor rather
   than a single value that applies to all of them.  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 associated with
   the same bundle member are received, either within a single L2 Bundle
   Attribute Descriptor or in multiple L2 Bundle Attribute Descriptors,
   implementations MUST use the first occurrence in the lowest numbered
   Link State Protocol Data Unit (LSP) and ignore subsequent
   occurrences.

Gong, et al.               Expires 2 May 2027                   [Page 8]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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:  4 octets of a remote interface identifier.  See
      Section 7 for the acquisition of the remote interface identifier.

   A receiver first associates this sub-TLV with the member of the
   enclosing L2 Bundle Member Attributes TLV instance.  After this
   association, a remote interface ID with value of zero is not valid
   and MUST be ignored and handled by the receiver as if the sub-TLV was
   not present (i.e., the remote identifier of that member is treated as
   unknown).

Gong, et al.               Expires 2 May 2027                   [Page 9]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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 individual TLVs or
   sub-TLVs from the BGP-LS Attribute.  A BGP-LS Speaker performs the
   syntactic validation of the BGP-LS Attribute as specified in
   Section 8.2.2 of [RFC9552]: since this sub-TLV has a fixed Length of
   4, an instance with an invalid Length causes the recognizing speaker
   to apply the 'Attribute Discard' fault handling, which discards all
   TLVs in the BGP-LS Attribute (not just this sub-TLV).  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.

Gong, et al.               Expires 2 May 2027                  [Page 10]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

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 for unnumbered links defined in Section 2.1 of
   [RFC4202].

   The relationship between the local and remote identifiers is
   reciprocal.  When an L2 Bundle Member Link advertisement is sent by
   the neighbor, the remote interface identifier MUST match the non-zero
   32-bit value that the neighboring router advertises as the L2 Bundle
   Member Link Local Identifier for that same bundle member.  This
   requirement constrains the value of an advertised remote identifier;
   it does not require or forbid the advertisement of remote
   identifiers.  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

Gong, et al.               Expires 2 May 2027                  [Page 11]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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.

   The configuration and operational state for this feature (the per-
   link enablement, the association of each bundle member with its
   remote identifier, and the validation state described in Section 7)
   is expected to be provided as augmentations to the base YANG data
   models for OSPF ([RFC9129]) and for IS-IS ([RFC9130]).  The
   definition of such augmentations is outside the scope of this
   document.

   In the event that the values of the remote identifiers change (e.g.,
   due to reassignment after reboot), an implementation MUST update the
   values advertised in the L2 Bundle Member Interface Remote Identifier
   sub-TLV to be consistent with the new value.  This applies to cases
   where the value is learned and to cases where the value is locally
   configured.

   If the connectivity relationships are also collected via a
   management-based approach (see Section 1), a mismatch between the two
   sets of information might be observed.  In such a case, the
   information retrieved via the management-based approach takes
   precedence.

9.  Security Considerations

   This document describes how OSPF, IS-IS and BGP-LS advertise the
   remote interface identifiers for L2 bundle members.  The security
   considerations of [RFC8668], [RFC9356], [RFC9552] and [RFC9085] 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

Gong, et al.               Expires 2 May 2027                  [Page 12]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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, when an originator determines, using the validation
   described in Section 7, that a remote identifier it has been
   advertising is no longer valid, it MUST NOT continue to advertise
   that remote identifier.

   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.

Gong, et al.               Expires 2 May 2027                  [Page 13]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   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.

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

Gong, et al.               Expires 2 May 2027                  [Page 14]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   +------+----------------------------------------------+
   | 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, Behcet Sarikaya for GENART review, and Brian Weis for SECDIR
   review.

   The authors would also like to thank Shraddha Hegde, Tom Petch, and
   Siddhant Mehta for their review of this document and their comments.

   The authors would also like to thank Gunter Van de Velde for his
   shepherd AD review and helpful comments to improve this document.

   The authors would like to thank Mohamed Boucadair, Deb Cooley, Roman
   Danyliw, Christopher Inacio, Jim Guichard, and Mahesh Jethanandani
   for their IESG review and helpful comments to improve this document.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4202]  Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
              in Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
              <https://www.rfc-editor.org/info/rfc4202>.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
              <https://www.rfc-editor.org/info/rfc4552>.

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

Gong, et al.               Expires 2 May 2027                  [Page 15]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   [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, February
              2009, <https://www.rfc-editor.org/info/rfc5310>.

   [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, October
              2009, <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, March 2014,
              <https://www.rfc-editor.org/info/rfc7166>.

   [RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
              "Security Extension for OSPFv2 When Using Manual Key
              Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
              <https://www.rfc-editor.org/info/rfc7474>.

   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <https://www.rfc-editor.org/info/rfc7684>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
              F. Baker, "OSPFv3 Link State Advertisement (LSA)
              Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
              2018, <https://www.rfc-editor.org/info/rfc8362>.

   [RFC8668]  Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
              M., and E. Aries, "Advertising Layer 2 Bundle Member Link
              Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
              December 2019, <https://www.rfc-editor.org/info/rfc8668>.

   [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, August 2021,
              <https://www.rfc-editor.org/info/rfc9085>.

   [RFC9356]  Talaulikar, K. and P. Psenak, "Advertising L2 Bundle
              Member Link Attributes in OSPF", RFC 9356, January 2023,
              <https://www.rfc-editor.org/info/rfc9356>.

Gong, et al.               Expires 2 May 2027                  [Page 16]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   [RFC9552]  Talaulikar, K., Ed., "Distribution of Link-State and
              Traffic Engineering Information Using BGP", RFC 9552,
              DOI 10.17487/RFC9552, December 2023,
              <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, October
              2025, <https://www.rfc-editor.org/info/rfc9885>.

12.2.  Informative References

   [IEEE802.1AB]
              "IEEE Standard for Local and Metropolitan Area Networks -
              Station and Media Access Control Connectivity Discovery",
              IEEE Std 802.1AB-2016, 29 January 2016.

   [IEEE802.1AX]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks--Link Aggregation", IEEE Std 802.1AX,
              DOI 10.1109/IEEESTD.2020.9105034, May 2020,
              <https://doi.org/10.1109/IEEESTD.2020.9105034>.

   [RFC8537]  Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to
              the Fast Reroute Procedures for Co-routed Associated
              Bidirectional Label Switched Paths (LSPs)", RFC 8537,
              DOI 10.17487/RFC8537, February 2019,
              <https://www.rfc-editor.org/info/rfc8537>.

   [RFC9059]  Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
              Element Communication Protocol (PCEP) Extensions for
              Associated Bidirectional Label Switched Paths (LSPs)",
              RFC 9059, DOI 10.17487/RFC9059, June 2021,
              <https://www.rfc-editor.org/info/rfc9059>.

   [RFC9129]  Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem,
              "YANG Data Model for the OSPF Protocol", RFC 9129,
              DOI 10.17487/RFC9129, October 2022,
              <https://www.rfc-editor.org/info/rfc9129>.

   [RFC9130]  Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and
              L. Lhotka, "YANG Data Model for the IS-IS Protocol",
              RFC 9130, DOI 10.17487/RFC9130, October 2022,
              <https://www.rfc-editor.org/info/rfc9130>.

Contributors

Gong, et al.               Expires 2 May 2027                  [Page 17]
Internet-Draft         L2 Bundle Member Remote ID           October 2026

   Ketan Talaulikar
   Cisco Systems
   India
   Email: ketant.ietf@gmail.com

Authors' Addresses

   Liyan Gong
   China Mobile
   China
   Email: gongliyan@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com

   Xiaolong Hu
   New H3C Technologies
   China
   Email: huxiaolong.1260@outlook.com

   Les Ginsberg
   Cisco Systems
   United States of America
   Email: ginsberg@cisco.com

   Peter Psenak
   Cisco Systems
   Apollo Business Center
   Mlynske nivy 43
   Bratislava 821 09
   Slovakia
   Email: ppsenak@cisco.com

Gong, et al.               Expires 2 May 2027                  [Page 18]