Internet-Draft SR in TwoD-IP Routing February 2022
Xu, et al. Expires 1 September 2022 [Page]
Workgroup:
SPRING Working Group
Internet-Draft:
draft-xu-spring-segment-twod-ip-routing-02
Published:
Intended Status:
Informational
Expires:
Authors:
M. Xu
Tsinghua University
B. Wang
Tsinghua University
T. Wang
Beijing University of Posts and Telecommunications
S. Yang
Shenzhen University
J. Wu
Tsinghua University

Segment Routing in Two Dimensional IP Routing

Abstract

Segment Routing (SR) allows a headend node to steer traffic into a Segment Routing Policy (SR Policy), which represents the routing path by matching the destination address and the corresponding Binding Segment Identifier (BSID). However, determining the target SR Policy only based on destination aspect is incapable for demands for higher dimensional routing. Two Dimensional IP (TwoD-IP) routing is an Internet routing architecture that makes forwarding decisions based on source and destination addresses. TwoD-IP routing can easily express a routing policy between host to host, or network to network, and have much lower storage and calculation consumption compared to the higher dimensional routing.

In this document, we extend SR to support TwoD-IP routing, illustrate some typical scenarios of SR with TwoD-IP routing to express the advantage of extending SR to support TwoD-IP routing, and describe the mechanism of how TwoD IP routing protocol cooperates with SR.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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 5 August 2022.

▲

Table of Contents

1. Introduction

Segment routing (SR) [RFC8402] allows a headend node to steer a packet flow into an Segment Routing Policy (SR Policy), which represents the routing path. So that the administrator can specific forwarding path on headend node [I-D.ietf-spring-segment-routing-policy].

The headend node can steers packets into an SR Policy either by matching the destination address or routing policy. However, due to the increasing demands of higher dimensional routing like Multi-homing or Source Related Policy Routing, only directs packets based on destination aspect is limited under those scenarios. Moreover, directing packets into SR Policy by routing policy, which can match other fields in packets like port and source address, needs many access in memory. Considering the high-speed ternary content-addressable memory (TCAM) based solution for routers is limited by its low capacity, simply adding one more dimension on routing policy can easily become undeployable on TCAM-based solution.

To achieve higher Dimensional routing objectives, we introduce Two Dimensional-IP (TwoD-IP) routing protocol. [I-D.xu-rtgwg-twod-ip-routing] The TwoD-IP routing architecture can easily express a routing policy between host to host, or network to network, and have much lower storage and calculation consumption compared to higher dimensional routing.

In this document, we extend Segment Routing to support Two Dimensional IP(TwoD-IP) routing to enriches the routing abilities, describe how they cooperate to achieve higher dimensional routing like Multi-homing.

To extend Segment Routing to support Two Dimensional IP(TwoD-IP) routing, modification of the data plane and control plane is necessary. In data plane, the TwoD-IP routing protocol needs a TwoD-IP forwarding table to stores the source and destination address information. In control plane, the TwoD-IP routing protocol leverages OSPFv3 Router Information(RI) LSA to broadcast configuration and the SR Policy Dynamic Path Computation to compute optimal forwarding path under setting configuration. With these modifications, the headend node will be able to make forwarding decisions base on both source and destination aspects without damaging existing SR architecture.

2. Terminology

Terminology used in this document:

3. Benefit of extend Segment routing to support TwoD-IP routing

This section lists two scenarios which can benefit from TwoD-IP routing protocol with Segment Routing technology. Illustrating that TwoD-IP routing protocol can seamless deployment with SR and combine their advantage to achieve users demands of higher dimensional routing.

3.1. Multi-homing

Even though Segment Routing is able to steer flows to the destination in different way, it is still limited to process the source-related routing scenario like Multi-homing.

Multi-homing[RFC4177] is prevalent among ISPs for better traffic distribution and reliability. In this case, a network could be connected to multiple upstream ISPs, Hosts are assigned multiple addresses, one for each ISP. The network is responsible for delivering packets from Hosts to the export exit router that is connected to the corresponding upstream ISP.

For example, in Figure 1, a multi-homed site is connected to two ISPs: ISP1 and ISP2. ISP1 has a prefix P1, and ISP2 has a prefix P2. A host connect to the multi-homed site has two addresses, address A that assigned from ISP1, and address B that assigned from ISP2. the multi-homed site should deliver the traffic from A towards the Internet to ISP1, and deliver the traffic from B towards the Internet to ISP2.

                 +--------------------+
                 |                    |
                 |       Internet     |
                 |                    |
                 +--+---------------+-+
                    |               |
                    |  l3           | l4
                    |               |
             +------+----+       +--+--------+
             |   ISP1    |       |   ISP2    |
             | Prefix P1 |       | Prefix P2 |
             +--------+--+       +-+---------+
                      |            |
                      | l1         | l2
                   +--+------------+--+
                   |                  |
                   | Multi-homed Site |        +---------+
                   |                  +--------+  Host   |
                   +------------------+        +---------+
                                          ISP1 assign address: A
                                          ISP2 assign address: B

                Figure 1: Multi-homing scenario

Although SR can assign different forwarding paths to different ISP for an incoming packet, it still lacks the ability to classify the packets toward the same destination address with different source addresses A and B. With the help of TwoD-IP and Segment Routing, the administrator can easily implement Multi-homing by modifying the headend node that receives packets from Host, which means that administrator does not need to concern about the intermediate node. After extending SR to support TwoD-IP routing, the headend node can routing packet based on both source and destination address, guides packets from Host through the optimal path to the corresponding ISP.

In this scenario, an ingress edge node wants to forward packets with the same destination address through different kind of paths in order to achieve source related demand.

For example, in Figure 2, assume a network has four routers: a, b, c and d, c has a service(such as authentication or encIPherer). The operator wants a packet from a to d to be delivered to service c first and then node c will forward the processed packet to it's destination d.

                                    +---------+
                             +------+    c    +-----+
                             |      +(service)+     |
                             |      +---------+     |
                             |                      |
        +------+          +--+---+              +---+--+
        |  a   +----------+  b   +--------------+   d  |
        +------+          +------+              +------+

                Figure 2: TwoD-IP routing for Service

In Segment Routing Architecture, we can allocate a Service segment associated with node c's service.[I-D.ietf-spring-sr-service-programming] and can be integrated as part of an SR Policy P1(Headend node: b, color, Endpoint: d) of Segment-List < c > . But SR Policy steers packets to a specific SR Policy only when this packet's destination matching corresponding entry, which means headend node can't only steers packets from a to SR Policy P1.

But with TwoD-IP routing, headend node b can easily steer packets matching destination of b and source of a to SR Policy P1, then the packet will be delivered to service c first and then node c will forward the processed packet to it's destination d.

4. Framework

The mechanism of how we combine TwoD IP routing and Segment Routing can be separated into the data plane and the control plane.

The data plane is mainly concerned about the forward table. It is the foundation of two-dimensional packets forwarding. It needs to be able to store the two-dimensional information of destination and source address without expanding TCAM resource, and the lookup process needs to be quick to support massive packets routing. Then we describe the lookup process and forwarding table updating based on it.

Under SR Two-D IP routing, The control plane is concerned with network status and user demands related to <destination address, source address> pair. It needs to transform the user demand to the Policy routing and integrate the Policy routing to the forwarding table so that the headend node can steers packets to a Policy routing representing user demand by checking the packet's <destination address, source address> pair.

5. Data Plane

The administrator only need to deploy the TwoD-IP forwarding table in the headend node, which makes implementing TwoD-IP routing is much easier. TwoD-IP routing leverages the Segment Routing to deploy the TwoD-IP forwarding table in the headend, which makes implementing TwoD-IP routing is much easier. To achieve the ability of steering packets' forwarding path to follow our decision, we are not willing to damage the existing segment routing architecture.

The fast, massive packets routing required fast forwarding entries searching speed, which required the TCAM to store the forwarding entries. However, the TCAM resource is limited under TwoD-IP routing for the dimensional explosion problem in which two-d forward entries grow exponentially. To routing massive packets as fast as possible, a brand new forwarding table structure needs to be design

5.1. Forwarding Table Design

5.1.1. Design Goals

Unlike the existing SR Policy architecture that steers packets into matching Binding SID based on destination field in the packet, the TwoD-IP routing should steer packets into a BSID according to both the destination and source IP address. The new forwarding table design should satisfy the following requirements:

  • Compatibility. The forwarding table SHALL NOT be incompatible with the existing Segment Routing deployment to assign the forwarding path according to the two-dimensional IP address in the headend node.

  • Speed requirement. The TCAM must be used for fast searching and should parallel the IP searching for both destination and source address

  • Storage requirement. TCAM resources will be limited for the higher dimensional routing to avoid dimensional explosion problem, the destination and source address needs to be stored seperatelly

5.1.2. Forwarding Table Structure 

            Source  +------------+------+------+------+------+
            Table   |default     | 111* | 101* | 100* | 11** |
                    +------------+------+------+------+------+
                    |        0   |   1  |   2  |   3  |   4  |
                    +------------+------+------+------+------+
      Destination        default           Mapping Table
        Table         | FIB Index |            index          |
    +-------+---+  --+-----------+------+------+------+------+---
    | 111*  | 0 |    |        0  |  0   |      |  1   |      |
    +-------+---+  --+-----------+------+------+------+------+---
    | 100*  | 1 |    |  1        |  2   |      |      |      |
    +-------+---+  --+-----------+------+------+------+------+---
    | 101*  | 2 |    |  2        |      |      |      |  2   |
    +-------+---+  --+-----------+------+------+------+------+---
    | 11**  | 3 |    |  3        |      |      |      |      |
    +-------+---+  --+-----------+------+------+------+------+---
    | 10**  | 4 |    |  4        |      |      |      |  3   |
    +-------+---+  --+-----------+------+------+------+------+---
                     |           |      |      |      |      |
                                  TD-table

                    +------+---------+               +------+---------+
                    |Index |Next hop |               |prefix|Next hop |
                    +------+---------+               +------+---------+
                    | 0    |BSID1    |               | 0    |1.0.0.0  |
                    +------+---------+               +------+---------+
        Mapping     | 1    |BSID1    |   Default     | 1    |1.0.0.1  |
        Table       +------+---------+    FIB        +------+---------+
                    | 2    |BSID2    |               | 2    |1.0.0.2  |
                    +------+---------+               +------+---------+
                    | 3    |BSID3    |               | 3    |1.0.0.3  |
                    +------+---------+               +------+---------+

 Figure 2: SR in Two-Dimensional IP Routing Forwarding Table Structure

To achieve all design goals of the forwarding table, we integrate the TwoD-IP routing forwarding table structure called FIST into Segment Rouitng's FIB. As shown in Figure 3, the forwarding table structure consists of the following components:

  • Destination table: It resides in TCAM for fast lookup, and stores the destination prefixes. Each destination prefix in the destination table corresponds to a row number.

  • Source table: It resides in TCAM for fast lookup, and stores the source prefixes. Each source prefix in the source table corresponds to a column number.

  • Two Dimensional Table (TD-table): A two-dimensional array resides in SRAM. Given a row and column numbers, we can find a cell in TD-table. Each cell in TD-table stores an index value of default FIB or Mapping table, which can be mapped to a next-hop.

  • Mapping table: It resides in SRAM, and maps index values to next hops, and the next hop of mapping table will be the Binding SID, which represents the forwarding path we set.

  • Default FIB: It is the same as the existing FIB, which can reside in TCAM or SRAM. The keys of the entries MUST be in keeping with the Destination Table.

5.1.3. Lookup Action

Even though there is a Default FIB in forwarding table structure which is the same as existing FIB, the lookup action is not based on it, it based on the Destination and Source Table. More specific, when a packet arrives at the source router, the lookup action is as follows.

  1. Extract the destination address d and source address s from the packet;

  2. Perform the following two operations in parallel:

    • Lookup the destination address d in the destination table using the LMF rule, and output the row number n;

    • Lookup the source address s in the source table using the LMF rule, and output the column number m;

  3. Lookup the cell that is in the nth row and mth column of the TD-table, and output the index value v of default FIB or Mapping table:

    • If there's TwoD-IP rule corresponding to the <destination, source> pair, the output column number m of the source table will not be default (i.e. 0), so the index value of v will corresponds to the Mapping table. So we lookup v in the mapping table, and output the corresponding next hop;

    • If there is not TwoD-IP rule corresponding to the <destination, source> pair, the output column number m of the source table will be default (i.e. 0), so the index value of v will corresponds to the Default FIB. So we lookup v in the Default FIB, and output the corresponding next hop;

The most considerable lookup time is the entries searching for the address. To speed it up, we store the destination and source address IP prefix in TCAM, and look up those tables in parallel. After getting the output index of the entries based on the <destination address, source address> pair, every subsequent lookup action will consume one SRAM clock cycle.

The SR TwoD-IP routing should activate the policy routing based on the packet's <destination address, source address> pair in the headend node. Moreover, the SR architecture has provided an identification called Binding segment (BSID) to represent a policy routing. So the next hop in the Mapping table SHOULD steer the packet into the BSID of SR Policy, which represents a Segment-List.

5.1.4. Forwarding table Update Action

In Segment Routing in Two Dimensional IP Routing architecture, not only TwoD-IP routing will modify the forwarding table FIST to satisfy its routing policy, but the existing Segment Routing Policy will also deploy its routing Policy. We do not want to damage the existing Segment Routing architecture, so it is still available for Segment Routing to modify the FIB to steer packets into specific SID such as SR Policy On-Demand next hop. However, any modification of FIB in Segment Routing MUST reside in FIST Default FIB, and if there are any modifications of keys in FIST Default FIB, the Destination Table must be in keeping with it for correcting lookup.

The reason any modification of SR Policy MUST resides in FIST Default FIB is that under segment Routing in Two Dimensional IP Routing architecture, the TwoD-IP routing policy is priority-first. The routing Policy located in FIST Default FIB will be matched only when there is no TwoD-IP policy corresponding to incoming packet's <destination, source> pair.

6. Control Plane

Under SR Two-D IP routing, The control plane is concerned with network status and user demands. Furthermore, The Two-D IP routing can offload the network status like topology or reachability to the SR framework. However, the Two-D IP routing is still responsible for transforming the user demand of two-dimensional destination and source addresses to the forwarding Policy and integrating it to the forwarding table.

The control plane of SR Two-D IP routing is consists of the following parts:

6.1. Advertisement of TwoD-IP configuration

The headend node needs to transform the TwoD-IP configuration to the Policy routing and install it into the forwarding table to achieve the two-dimensional IP routing. We need to be concerned about how to notification these TwoD-IP configurations to the headend node. There are two practical ways to achieve this object: install the headend node manually or advertise these TwoD-IP configurations from other nodes to the headend node.

When advertising TwoD-IP configurations between nodes, three parts needs to be carried: destination addresses, source addresses, and the user demands of the <destination, source> pairs. Because we leverage the SR Policy to represent the routing policy and SR Policy Dynamic Path Computation to compute the target forwarding path, the user demand will be expressed as an optimization objective and constraints.

6.1.1. TwoD-IP configuration architecture

The configurations of TwoD-IP routing is organized as TwoD-IP configuration TLV. For example, this brand new TLV can be a TLV of OSPFv3 Router Information(RI) LSA, which introduce the ability to broadcast the TwoD-IP configuration information between OSPF nodes by advertising an OSPFv3 RI LSA that carries the TwoD-IP configuration TLV.

More specifically, all three kinds of TwoD-IP configuration, including destination addresses, source addresses, and the user demands of the <destination, source> pairs are all included within the TwoD-IP configuration TLV as three kinds of Sub-TLVs. The TwoD-IP configuration TLV is the same as the format used by[RFC3630]. The variable TLV section consists of one or more nested TLV tuples. The format of each TLV is:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Sub-TLVs                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3.  TwoD-IP configuration TLV Format

Where:

Type is TBD
Length: 16 bit field. The total length of the value portion(Sub-TLVs) of the TLV
Sub-TLVs: Each TwoD-IP configuration TLV has three kinds of Sub-TLVs: Demands Sub-TLV, destination address Sub-TLV and source address Sub-TLV. These Sub-TLVs represent the two-dimensional information of destination and source addresses and corresponding user demands of <destination address, source address> pairs.

6.1.2. Demands Object Sub-TLV

To leverage the ability of SR Policy Dynamic Path Computation, the user demand MUST be represented by the formation of Optimization object and constraints. So each user demand carried by Demands Object Sub-TLV is consists of Optimization object and constraints information. And the Optimization and the constraint is refer to the [I-D.filsfils-spring-sr-policy-considerations].

The format of Demands Object Sub-TLV is:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Reserved             |O Flags|  Optimize T   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Reserved             |C Flags| Constraint T  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Constraint      variables                    |
      |                           ...                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Optimization Object Sub-TLV Format

Where:

Type: 16 bit field. The value is 1 for this type.
Length: 16 bit field. The total length of the value portion of the Sub-TLV.
Reserved (20 bits): This field MUST be set to zero on transmission and MUST be ignored on receIPt.

O Flags(4 bits): Optimization object Flags, identify the optimization objective, The following flags are defined:

       0 1 2 3
      +-+-+-+-+
      |M|N|   |
      +-+-+-+-+

Where:

  • M flag: Min-Metric - requests computation of a solution Segment-List optimized for a selected metric.

  • N flag: Min-Metric with margin and maximum number of SIDs - Min Metric with two changes: a margin of by which two paths with similar metrics would be considered equal, a constraint on the max number of SIDs in the Segment-List.

Optimize T (Type - 8 bits): Specifies the metric type. Three values are currently defined:

  • T=1: IGP metric

  • T=2: TE metric

  • T=3: Hop Counts

  • T=4: Delay

C Flags(4 bits): Constraints Flags, iIdentify the Constraints of forwarding path computation, The following flags are defined:

       0 1 2 3
      +-+-+-+-+
      |I|E|D| |
      +-+-+-+-+

Where:

  • I flag: Inclusion

  • E flag: Exclusion

  • D flag: Diversity to another service instance (e.g., link, node)

Constraint T (Type - 8 bits): Specifies the metric type. Two values are currently defined:

  • T=1: TE affinity

  • T=2: IPv6 address(can be an SRv6 SID)

variable: 128 bit field. Corresponding to the type defined in Constraint T.

6.1.3. destination/source address Sub-TLV

A TwoD-IP routing demand corresponding a <destination, source> pair, so the Optimization object and constraint define a TwoD-IP demand and naturally need to bind a <destination, source> pair. The pair's information is carried in destination/source address Sub-TLV, and it's format is:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PrefixLength  |T|  Reserved   |         PrefixNumbers         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix1                        |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix2                        |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             ...                               |
      |                                                               |

            Figure 6: destination/source address Sub-TLV Format

Where:

Type: 16 bit field. The value is 3 for destination address, 4 for source address.
Length: 16 bit field. The total length of the value portion(addresses information) of the TLV.
PrefixLength: 8 bit field. The length of IPv6 address. The IPv6 address information is transferring in Prefix format in order to reduce packet length and all the addresses needed to transferring is group by same prefix length.
T (dimensional type): 1 bit. 0 for destination addresses, 1 for source addresses.
Reserved (7 bits): This field MUST be set to zero on transmission and MUST be ignored on receIPt.
PrefixNumbers: 16 bit field. The number of address prefix in the length of PrefixLength.
Address Prefix: The address prefix in the length of PrefixLength and will be padded with 0 to fit the multiple 32 bit length.

6.2. TwoD-IP forwarding path computation

The procedure of transforming the TwoD-IP configuration to a forwarding path and steering corresponding packets through it consists of two steps: Calling the SR Policy Dynamic candidate path and TwoD-IP forwarding table entries modification.

6.2.1. Setting up the SR Policy Dynamic candidate path

In keeping with SR Policy Dynamic Path Computation, the TwoD-IP configuration contains the Optimization object and constraint information. when the headend node receives TwoD-IP configuration information(manually or automatically), it will extract the Optimization object and constraint information to generate a corresponding SR Policy .

The candidate path associated of an SR Policy is a dynamic candidate path that is expressed by optimization objective and a set of constraints extracted from the TwoD-IP Demands Sub-TLV. Then the headend node(or with the help of a PCE) computes the solution Segment-List that solves the optimization problem to match our TwoD-IP routing demand. After path computation, the SR Policy can represent the forwarding path that satisfies the TwoD-IP Demand. Any packets steered to this SR Policy can be forwarded to the destination following the target path. After offloading the path computation to SR without private custom, TwoD-IP routing can achieve higher compatibility and easier deployment.

6.2.2. TwoD-IP forwarding table entries modification

an SR Policy can be represented by the identifier called Binding segment (BSID) under Segment Routing architecture. So after path computation under user demands, we can get the SR policy which represents the target forwarding path and the BSID associated with it. Then we need to install this BSID into the TwoD-IP forwarding table so that the TwoD-IP forwarding table can match and steer packets into target BSID, and forward them through SR Policy dynamic path.

More specifically, The control plane will install the BSID into the Mapping Table and get the index of entry that stores it. then for all the <destination address, source address> pairs associated with this BSID, the control plane will update the TD-table cells of these pairs to the Mapping Table index or update entries to the source or destination table if there is an uninstalled pair.

7. Security Considerations

This document does not introduce additional security requirements and mechanisms.

8. IANA Considerations

This memo asks the IANA for no new parameters.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.

9.2. Informative References

[I-D.filsfils-spring-sr-policy-considerations]
Filsfils, C., Talaulikar, K., Król, P. G., Horneffer, M., and P. Mattes, "SR Policy Implementation and Deployment Considerations", Work in Progress, Internet-Draft, draft-filsfils-spring-sr-policy-considerations-09, , <https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-09>.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22>.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-service-programming-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-10>.
[I-D.xu-rtgwg-twod-ip-routing]
Xu, M., Wu, J., Yang, S., Cui, L., and D. Wang, "Two Dimensional IP Routing Architecture", Work in Progress, Internet-Draft, draft-xu-rtgwg-twod-ip-routing-01, , <https://datatracker.ietf.org/doc/html/draft-xu-rtgwg-twod-ip-routing-01>.
[RFC3630]
Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, , <https://www.rfc-editor.org/info/rfc3630>.
[RFC4177]
Huston, G., "Architectural Approaches to Multi-homing for IPv6", RFC 4177, DOI 10.17487/RFC4177, , <https://www.rfc-editor.org/info/rfc4177>.

Authors' Addresses

Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing
Phone: +86-10-6278-5822
Bo Wang
Tsinghua University
Beijing
Tingfeng Wang
Beijing University of Posts and Telecommunications
Beijing
P.R. China
Shu Yang
Shenzhen University
Guangdong
P.R. China
Jianping Wu
Tsinghua University
Beijing
P.R. China