BGP-LS Extensions for IS-IS Flood Reflection

Abstract

IS-IS Flood Reflection is a mechanism that allows flat, single-area IS-IS topologies to scale beyond their traditional limitations.¶

This document defines new BGP-LS (BGP Link-State) TLVs in order to carry IS-IS Flood Reflection information.¶

1. Introduction

IS-IS Flood Reflection [RFC9377] is a mechanism that allows flat, single-area IS-IS topologies to scale beyond their existing limitations.¶

Flood Reflection topologies are broken into clusters. The participating nodes must convey their unique Cluster ID signifying their membership in a particular topology as well as their role (e.g. Flood Reflector or Client).¶

BGP Link-State RFC9552 [RFC9552] defines mechanisms to advertise information about the underlying IGP in BGP NLRI to an external entity (e.g. a controller). A new BGP-LS TLV is required in order to describe IS-IS Flood Reflection node and link details. This document defines that TLV.¶

2. BGP-LS Extensions for IS-IS Flood Reflection

Controllers may need to compute traffic engineered paths across Flood Reflection clusters. This requires that they be aware of Flood Reflection information (be it operational or configured), such as Cluster ID, C-bit (which indicates Flood Reflector or Client), and any applicable sub-TLVs.¶

The IS-IS Flood Reflection TLV can be advertised in BGP-LS as either a Node attribute or a Link attribute. When describing a node, values are derived from the IS-IS Flood Reflection Discovery Sub-TLV. When describing a link, values are derived from the IS-IS Adjacency Sub-TLV. The semantics of any fields within the TLV/sub-TLVs are described in [RFC9377].¶

This document defines the following BGP-LS TLVs for use with IS-IS Flood Reflection.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|  RESERVED   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Flood Reflection Cluster ID                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Sub-TLVs ...                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Design Considerations

It is typical that a BGP-LS extension mirror all of the corresponding IGP components (i.e. TLVs, sub-TLVs, and sub-sub-TLVs) in order to carry the necessary IGP information. IS-IS Flood Reflection [RFC9377] describes "Tunnel-Based" deployments where an optional "Flood Reflection Discovery Tunnel Type Sub-Sub-TLV" is used to facilitate the creation of "L1 Shortcuts" (i.e. tunnels) between nodes in a Flood Reflection cluster. In this document, it is RECOMMENDED that this sub-sub-TLV be excluded from the BGP-LS extension for the following reasons.¶

For example, shortcuts could be point-to-point IS-IS tunnels or be encapsulated by other means. In deployments where the tunnels are IS-IS based, no additional BGP-LS extension is required as the existing BGP-LS extensions for IS-IS will suffice.¶

However, for deployments where tunnels are encapsulated by other means it is not desirable for BGP-LS to carry that information as it is tunnel information and not IGP information. Other existing or new BGP-LS extensions that correspond to the particular tunnel type SHOULD be used to fulfill any BGP-LS requirements.¶

An implementation MAY still choose to include the "Flood Reflection Discovery Tunnel Type Sub-Sub-TLV" for the sake of completeness. For example, it might be beneficial for cases where BGP-LS is the only way this information can be obtained.¶

7. References