Advertisement of Remote Interface Identifiers for Layer 2 Bundle MembersChina MobileChinagongliyan@chinamobile.comNew H3C TechnologiesChinalinchangwang.04414@h3c.comNew H3C TechnologiesChinahuxiaolong.1260@outlook.comCisco SystemsUnited States of Americaginsberg@cisco.comCisco SystemsApollo Business CenterMlynske nivy 43Bratislava 821 09Slovakiappsenak@cisco.com
Routing
LSR Working GroupOSPF, IS-IS, BGP-LS, Layer 2 Bundle, Link Aggregation
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-LS is also specified.
Introduction
BGP-LS is widely used for collecting topology information
from IGPs. In networks where Layer 2 (L2) interface bundles (such as
a Link Aggregation Group (LAG) ) 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.
When advertising L2 bundles in OSPF and IS-IS , 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.
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 when, and only when, they appear in all
capitals, as shown here.
Use Case 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.
Network Topology with L2 Bundle
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 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.
Advertising L2 Bundle Member Remote Interface Identifier
In OSPF, the remote interface identifiers of L2 bundle members are
advertised as follows.
OSPFv2 Extended Link TLV, or OSPFv3 Router-Link TLV, for L3 Link:
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.
In BGP-LS, the remote interface identifiers of L2 bundle members are
advertised as follows.
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)
]]>
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 a L2 bundle member.
It can be carried as a sub-TLV of the OSPF L2 Bundle Member
Attributes TLV . It has the following format:
Type:
TBA.
Length:
4.
Remote Interface ID:
Remote identifier of interface, 4 octets.
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.
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 . It has the following format:
Type:
TBA.
Length:
4 * Number of L2 Bundle Member Descriptors.
Remote Interface ID:
Remote identifier of interface, 4 octets.
There MUST be one Remote Interface ID for each of the L2 Bundle
Members advertised under the associated L2 Bundle Member Attribute
Descriptor. A remote interface ID with value of zero MUST be ignored
and handled as if the value was unknown.
MP-TLV for the new IS-IS sub-TLV SHOULD be set to "N".
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 3) and IS-IS
(Section 4).
It can be carried as a sub-TLV of the BGP-LS L2 Bundle Member
Attributes TLV . It has the following format:
Type:
TBA.
Length:
4.
Remote Interface ID:
Remote identifier of interface, 4 octets.
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.
Acquirement of Remote Interface Identifier
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. Some L2 protocols may be used to get the remote
interface identifiers for bundle members. This may be discovered via
when used to form the LAG bundle. A router may also
run LLDP on the bundle members to exchange local interface
identifiers with its neighbor, by using the Port ID TLV.
How the remote interface identifier is obtained is out of the scope
of this document.
Operational Considerations
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.
Security Considerations
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 , ,
, and are applicable to this
document.
As always, 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 and is
recommended to prevent such attacks.
As always, 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 , , , and 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 .
IANA Considerations
This document adds the following new sub-TLV to the "OSPFv2 Extended
Link TLV Sub-TLVs" registry.
This document adds the following new sub-TLV to the "OSPFv3
Extended-LSA Sub-TLVs" registry.
This document adds the following new sub-TLV to the "IS-IS Sub-TLVs
for TLVs Advertising Neighbor Information" registry.
This document adds the following new sub-TLV to the "BGP-LS NLRI and
Attribute TLVs" registry.
IEEE Standard for Local and Metropolitan Area Networks--Link AggregationKey words for use in RFCs to Indicate Requirement LevelsAuthentication/Confidentiality for OSPFv3IS-IS Cryptographic AuthenticationIS-IS Generic Cryptographic AuthenticationOSPFv2 HMAC-SHA Cryptographic AuthenticationSupporting Authentication Trailer for OSPFv3Security Extension for OSPFv2 When Using Manual Key ManagementAmbiguity of Uppercase vs Lowercase in RFC 2119 Key WordsSegment Routing ArchitectureAdvertising Layer 2 Bundle Member Link Attributes in IS-ISBorder Gateway Protocol - Link State (BGP-LS) Extensions for Segment RoutingBorder Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer EngineeringAdvertising L2 Bundle Member Link Attributes in OSPFMulti-Part TLVs in IS-ISIEEE Standard for Local and Metropolitan Area Networks - Station and Media Access Control Connectivity DiscoveryDistribution of Link-State and Traffic Engineering Information Using BGPContributorsCisco SystemsIndiaketant.ietf@gmail.com