]> Huawei

China zhangli344@huawei.com

Huawei

China jie.dong@huawei.com

Huawei

China lichenxi1@huawei.com

Routing Area LSR Working Group IGP This document extends ISIS and OSPF, allowing a network device to advertise the relationship between a physical interface and its sub-interfaces. This extension enables the links based on sub-interfaces to participate in the alternative paths for load balancing in SRv6 BE bandwidth polling.

Introduction The SRv6 BE bandwidth pooling technology enables network devices to detect link bandwidth and bandwidth usage in real time, thereby quickly identifying faults and congestion, and automatically calculating available alternative paths to load balance traffic. This function relies on network devices advertising their interface bandwidth and bandwidth usage information to external systems. There are several RFCs defining how to advertise the maximum bandwidth and utilized bandwidth of a link by IGP. describes extensions to Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering(TE). It defines the Maximum Link Bandwidth sub-TLV used to describe the maximum bandwidth of a link between two directly connected IS-IS neighbors. further extends , and defines the Unidirectional Utilized Bandwidth Sub-TLV to describe the bandwidth utilization between two directly connected IS-IS neighbors. describes extensions to OSPF protocol to support Traffic Engineering(TE). It defines the Maximum Link Bandwidth sub-TLV in the Link TLV used to describe the maximum bandwidth of a link between two directly connected OSPF neighbors further extends , and defines the Unidirectional Utilized Bandwidth Sub-TLV to describe the bandwidth utilization between two directly connected OSPF neighbors. However, these layer 3 protocols, such as IS-IS and OSPF, often establish neighbor relationships through sub-interfaces. When two directly connected IS-IS neighbors are established based on the sub-interface, then the Maximum Link Bandwidth and Unidirectional Utilized Bandwidth of the sub-interfaces are the same as their parent physical interface, since the sub-interfaces don't have independent bandwidth and bandwidth utilization information. The remote devices don't know the relationship between the sub-interfaces and their parent physical interface. Therefore, the remote devices don't know the maximum link bandwidth and unidirectional utilized bandwidth information is shared among all the sub-interfaces of a specific physical interface. This makes a remote link based on sub-interfaces difficult to participate in traffic load balancing as an alternative forwarding path. This document extends ISIS and OSPF, allowing a network device to advertise the relationship between a physical interface and its sub-interfaces. This extension enables the links based on sub-interfaces to participate in the alternative paths for load balancing in SRv6 BE bandwidth polling.

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.

Terminology

ISIS extensions There are two extension options to advertise the relationship between a physical interface and its sub-interfaces.

Physical Local Link Relationship Information TLV This extension option defines a new top level TLV named Physical Local Link Relationship Information TLV. This TLV describes the relationship between a physical interface and its sub-interfaces, and the physical bandwidth and bandwidth utilization information of the physical interface. The physical bandwidth and bandwidth utilization information is shared for all the sub-interfaces. The format of Interface Relationship TLV is shown as follows:

Format of physical local link relationship information TLV

where: Type: TBD1, to be allocated by the IANA. Length: the size of the value field in octets. L3 Neighbor System ID + pseudonode ID: 7-octet length, indicates a neighbor node； Flags： 8-bit length, currently not defined, reserved for future. Link Local/Remote Identifiers sub-TLV: as defined in , it is used to identify the physical interface. Inter-Lengh: 1-octet length, indicates the length of the following fields, including Sub-Interface Member Link Local Identifiers and Inter-Number. Inter-Number: 1-octet length, indicates the number of the sub-interfaces. Sub-Interface Member Link Local Identifiers: 4 * Inter-Number length, includes one or more link local identifiers for sub-interfaces. Sub-TLVs: variable length, the Maximum Link Bandwidth Sub-TLV and Unidirectional Utilized Bandwidth Sub-TLV SHOULD be included in this TLV.

Physical Local Link Information sub-TLV This extension option defines a new type of sub-TLV named Physical Local Link Information sub-TLV. It describes the identifier, physical bandwidth, and bandwidth utilization information of the Physical interface of a link. It can be included in the TLVs 22 (Extended IS Reachability TLV) and 222 (Extended IS Reachability TLV). The format of the Physical Local Link Information sub-TLV is shown as follows:

Format of physical local link information sub-TLV

where: Type: TBD1, to be allocated by the IANA. Length: the size of the value field in octets. Flags: 8-bit length, currently not defined, reserved for future. Physical Local Link Identifier: 4-octet length, the identifier of the local physical interface. Sub-TLVs: variable length, the Maximum Link Bandwidth Sub-TLV and Unidirectional Utilized Bandwidth Sub-TLV SHOULD be included in this TLV.

OSPF extensions TBD

Use cases As shown in the following figure, there are four nodes A, B, C, and D on the network. There are two links between node D and node C. IS-IS neighbor relationships are established between sub-interfaces d1 and d2 of node D and sub-interfaces c1 and c2 of node C. Sub-interfaces d1 and d2 correspond to the same physical interface d, and sub-interfaces c1 and c2 correspond to the same physical interface c. The physical bandwidth of the link between A and B is 100 Gbit/s, and 70 Gbit/s is used. The physical bandwidth of the link between C and D is 50 Gbit/s, and 20 Gbit/s is used.

An example for using the Sub-interface Link as Traffic Optimization Path

After the link state synchronization, node A receives and parses the related TLVs, and establishes the following mapping between the physical interface and sub-interfaces:

• Node D
  • Physical interface d
    • Bandwidth attributes of interface d（physical bandwidth and bandwidth utilization ratio）
    • sub-interface d1
    • sub-interface d2
• Node C
  • Physical interface c
    • Bandwidth attributes of interface c（physical bandwidth and bandwidth utilization ratio）
    • sub-interface c1
    • sub-interface c2

Assume that node A is the source node and node C is the destination node, the traffic rate is 60Gbit/s. In normal cases, the primary path is A->B->C. Node A calculates an alternative path A->D->C for node C, where two links are established between node D and node C through two sub-interfaces. Node A perceives that there is a congestion on the path A->B->C, it decides to use the alternative paths for load balancing. Based on the above established mapping relationship, node A knows that the two links corresponds to one physical interface, then uses them as a single load balancing link. Then node A will allocate 30Gbit/s on each path. However, if node A does not know the mapping relationship, it will consider A->D->C as two independent paths, allocating 20Gbit/s on each path. This result in the traffic on the physical interfaces d exceeds its maximum bandwidth, therefore a large number of packets will be lost.

IANA Considerations TBD

Security Considerations TBD

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810.

Acknowledgements TBD