Microloop Prevention in a Hierarchical Segment Routing Solution for CATS

Introduction An end-to-end CATS process is described as a hierarchical two segment routing manner in and and it is further analyzed in which implys that a hierarchical segment routing solution requires incremental solutions and designs. Compared to non hierarchical routing methods, a hierarchical segment solution has its unique features and proposes additional requirements as follows:

Aggregate explicit and detailed information of multiple service instances appropriately to avoid a loop caused by improper routing and forwarding decisions led by inadequate cohesive information.
Solve the microloop problem occurred in hierarchical segment routing under a multi-point decision-making circumstance due to inconsistent convergence time.

In IP networks, due to the distributed LSDB of IGP, there might be microloop issues when IGP converges out of order. Solutions has proposed such as Order FIB and Order Metric, but due to their principles of controlling the convergence order of network devices to guarantee orderly convergence, the convergence process becomes much more complex and the convergence time increases significantly. Thus, these schemes have not been widely applied and deployed in networks. Currently, SR technology is commonly used to address microloop issues, such as constructing an acyclic SRv6 Segment List to eliminate loops. However, an explicit destination is determined since the source device in IP routing circumstances while a specific service instance may not be designated during the first segment in a hierarchical segment service routing process. There is a lack of connection between forwarding behaviors on multiple devices. Thus, a conventional SR based solution requires incremental designs. Therefore, this draft proposes possible aggregation methods, designs hierarchical entries including global bases and local bases and introduces a forwarding behaviour with Computing Segments.

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

LSDB: Link State DataBase
IGP: Interior Gateway Protocol
RIB: Routing Information Base
FIB: Forwarding Information Base
SR: Segment Routing
SRv6: Segment Routing over IPv6
GRIB: Global Routing Information Base
GFIB: Global Forwarding Information Base
LRIB: Local Routing Information Base
LFIB: Local Forwarding Information Base

Aggregation of Computing Resource Status Information Assume that for a computing related service, a Service ID is utilized as an identifier as proposed in . Various computing related services may be sensitive to different attributes among metadata of computing resources and network capabilities, such as CPU cores, CPU load, I/O, memory, delay, bandwidth, etc. For a service instance which is able to provide a computing related service, metadata of sensitive attributes collected is capable of indicating the performance at the moment. Furthermore, as illustrated in , a Metric value can be calculated with the metadata of sensitive attributes as input variables. Therefore, the aggregation of computing resource status information is divided into the following two categories. 1. Aggregation of Metric Values. As shown below, a set of meta information been sensitive to a computing related service is recorded as a Attribute Set, the Attribute Set collected at Instance 1 for Service ID 1 is Attribute Set 1,1 for instance. There are multiple instances located in a edge cloud or a central data center connected to corresponding PEs. Based on the respective metadata of dynamic computing status and network conditions meta information of these service instances at a certain time, corresponding Metric values representing their capabilities can be calculated. As shown below, Instance 1, 2 and 3 located at PE 1 are all able to provide services represented by Service ID 1, 2 and 3. Accordingly, Metric 1,1 to Metric 3,3 are calculated respectively.

Aggregation of Metrics Attribute Set 1,1-->Metric 1,1 +---+Instance 1| Service ID2-->Attribute Set 2,1-->Metric 2,1 | +----------+ Service ID3-->Attribute Set 3,1-->Metric 3,1 | +------+ | +----------+ Service ID1-->Attribute Set 1,2-->Metric 1,2 | PE 1 +---+---+Instance 2| Service ID2-->Attribute Set 2,2-->Metric 2,2 +--++--+ | +----------+ Service ID3-->Attribute Set 3,2-->Metric 3,2 || | || | +----------+ Service ID1-->Attribute Set 1,3-->Metric 1,3 || +---+Instance 3| Service ID2-->Attribute Set 2,3-->Metric 2,3 || +----------+ Service ID3-->Attribute Set 3,3-->Metric 3,3 || || PE 1: || Service ID1-->Metric 1 = Function(Metric 1,1 Metric 1,2 Metric 1,3) || Service ID2-->Metric 2 = Function(Metric 2,1 Metric 2,2 Metric 2,3) || Service ID3-->Metric 3 = Function(Metric 3,1 Metric 3,2 Metric 3,3) || vv +--++--+ | PE 2 | +------+ ]]> Based on a framework of hierarchical computing status awareness and segment service routing, edge devices apply a corresponding aggregation algorithm to these Metric values, and publish and notify the aggregated results to the network. For a computing-related service represented by a Service ID, aggregation algorithms include but are not limited to:

Take the average of the corresponding Metric values calculated for a specific service among all service instances.
Take the weighted average of the corresponding Metric values calculated for a specific service among all service instances.
Take the maximum of the corresponding Metric value calculated for a specific service among all service instances.
Take the minimum of the corresponding Metric value calculated for a specific service among all service instances.
Take the median of the corresponding Metric values calculated for a specific service among all service instances.

The differential evaluation methods of each service can degenerate into a unified or service class based evaluation method based on conditions. Specifically here, different Service IDs can also correspond to a same Metric value calculated by a unified evaluation algorithm or a set of Service IDs corresponds to one Metric. 2. Aggregation of Metadata Sets.

Aggregation of Metadata Set Attribute Set 1,1 +---+Instance 1| Service ID2-->Attribute Set 2,1 | +----------+ Service ID3-->Attribute Set 3,1 | Metadata Set 1 = | U(Attribute Set 1,1, Attribute Set 2,1, Attribute Set 3,1) | +------+ | +----------+ Service ID1-->Attribute Set 1,2 | PE 1 +---+---+Instance 2| Service ID2-->Attribute Set 2,2 +--++--+ | +----------+ Service ID3-->Attribute Set 3,2 || | Metadata Set 2 = || | U(AttributetSet 1,2, Attribute Set 2,2, Attribute Set 3,2) || | || | +----------+ Service ID1-->Attribute Set 1,3 || +---+Instance 3| Service ID2-->Attribute Set 2,3 || +----------+ Service ID3-->Attribute Set 3,3 || Metadata Set 3 = || U(AttributetSet 1,3, Attribute Set 2,3, Attribute Set 3,3) || || PE 1: || Cohesive Metadata Set = || Function(Metadata Set 1,Metadata Set 2,Metadata Set 3) vv +--++--+ | PE 2 | +------+ ]]> The other aggregation method is shown above. For instance 1 located at PE 1, the Attribute Set of Service ID 1 to Service ID 3 are Attribute Set 1 to Attribute Set 3 respectively. The union of meta information in these Attribute Sets of multiple computing related services is recorded as the Metadata Set of instance 1. Similar to the process of aggregating Metric values, edge devices can also aggregate multiple Metadata Sets into a Cohesive Metadata Set, and then publish and notify the aggregated results to the network. For all service instances at an edge device, the aggregation algorithm includes but is not limited to:

Take the average value of same elements in Metadata Sets as the corresponding element value of the Cohesive Metadata Set.
Take the weighted average of same elements in Metadata Sets as the corresponding element value of the Cohesive Metadata Set.
Take the maximum value of same elements in Metadata Sets as the corresponding element value of the Cohesive Metadata Set.
Take the minimum value of same elements in Metadata Sets as the corresponding element value of the Cohesive Metadata Set.
Take the median value of same elements in Metadata Sets as the corresponding element value of the Cohesive Metadata Set.
Apply a corresponding strategy to select an instance and directly use the Metadata Set of the selected instance as the Cohesive metadata set.

In conclusion, a PE can aggregate multiple Metric values or Metadata Sets and further publish and advertise the coarse granularity and relatively stable information to the network. As analyzed in , an aggregation result should maintain its comparability to the information of any explicit service instance.

Design of Hierarchical Entries With the application of appropriate aggregation functions, the exposed entries gain essential correctness. However, due to the indeterminacy of forwarding behaviours and inseparable entries, a microloop problem still occurs under circumstances of sudden failures or dynamic updates. Therefore, a design of hierarchical entries is proposed in this section. Taking an aggregation of Metric values as an example, Metric values of several service instances at an edge device PE are aggregated and published and advertised in the network. By collecting and exchanging entries, a Global RIB was constructed. On the other hand, PE generates a Local RIB by collecting the running status of its local service instances. Afterwards, scheduling strategies are applied in the control plane and corresponding decisions are made. Suppose the entry with the smallest Metric value is selected as the optimal entry, it will further be distributed to the forwarding plane on the device and a Global FIB and a Local FIB is generated respectively, ultimately instructing the packet forwarding process. A typical form of GRIB, GFIB, LRIB and LFIB, taking PE 4 as an example, is displayed as follows. To be noted, the computing status of PE 4 itself is also displayed as an entry in the GRIB with an aggregated manner.

Hierarchical Global and Local Entries

Forwarding Behaviours with Computing Segments Although a design of hierarchical entries separates entries with information of different granularity, global and local entries both further require to be correlated with packet features and defined forwarding behaviours. As defined in , a Computing Segment is introduced. With the introduction of hierarchical entries displayed in the previous sections, a Computing Segment END.C can be further assorted as END.CG and END.CL associated with GFIB and LFIB respectively. Except for the different entries to lookup, END.CG and END.CL have identical semantics as stated in the previous work. The form of a packet delivered in the forwarding process is also shown below.

Usecase A microloop problem is displayed as follows with a circumstance of non hierarchical entries. A minimum Metric value is taken as the aggregated Metric value published by a PE. Instance 4,4 located at PE 4 is considered to be the most appropriate service instance with the minimum Metric value which represents the best performance when a service request accesses from PE 1. With a hierarchical computing status awareness and routing scheme, the traffic is first steered to PE 4 and then a sudden failure happens at Instance 4,4. PE 4 discovers the invalidity of Instance 4,4 and distributes a new FIB entry by recalculating in the control plane. PE 1 is selected as the updated next hop determined by PE 4. Thus, the traffic is steered back to PE 1. However, the event of the invalidity of Instance 4,4 has not been notified to the remote PE 1. Therefore, a microloop exists before PE 1 updates its entries.

Microloop Problem with Non Hierarchical Entries An identical condition with introduction of hierarchical entries is analyzed below. A global choice is made at the access device which is PE 1 indicated by a END.CG SID. Then, PE 4 is selected as the most appropriate next hop with the minimum aggregated Metric value. Identically, a sudden failure happens at Instance 4,4 and PE 1 has not been notified yet. Unlike the previous mentioned conditions, a specific local behaviour to lookup the LFIB denoted by a END.CL SID is implemented at PE 4. Although Instance 4,4 becomes invalid, Instance 4,1 is determined as the substitution with a suboptimal Metric value. Contrary to early analysis, the traffic is not steered back between PEs. Thus, a microloop problem is prevented through the design of hierarchical entries and the introduction of Computing Segments.

Microloop Prevention with Hierarchical Entries +------------+ | PE 2 | | PE 4 +-+--+Instance 4,1| +---+--+ +------+ | +------------+ |( ) | +------------+ | (--------------------) +--+Instance 4,2| +---------+--+ | +------------+ |Instance 2,1| | +------------+ +------------+ +--+Instance 4,3| | +------------+ | +------------+ +--+Instance 4,4|x Local FIB: +------------+ +------------+-------------+------+ Local RIB: | Service ID | NHP |OutInt| +------------+-------------+--------+ +------------+-------------+------+ | Service ID | NHP | Metric | |Service ID 1| Instance4,4 | |x +------------+-------------+--------+ +------------+-------------+------+ |Service ID 1| Instance4,1 | 26 | | +------------+-------------+--------+ | |Service ID 1| Instance4,2 | 36 | v +------------+-------------+--------+ +------------+-------------+------+ |Service ID 1| Instance4,3 | 34 | | Service ID | NHP |OutInt| +------------+-------------+--------+ +------------+-------------+------+ |Service ID 1| Instance4,4 | 20 |x |Service ID 1| Instance4,1 | | +------------+-------------+--------+ +------------+-------------+------+ ]]>

Security Considerations TBA.

Acknowledgements TBA.

IANA Considerations TBA.