SPRING Working Group M. Xu Internet-Draft B. Wang Intended status: Informational Tsinghua University Expires: 2 April 2022 T. Wang Beijing University of Posts and Telecommunications J. Wu Tsinghua University September 2021 Segment Routing in Two Dimensional IP Routing draft-xu-spring-segment-twod-ip-routing-00 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/. Xu, et al. Expires 2 April 2022 [Page 1] Internet-Draft SR in TwoD-IP Routing September 2021 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 March 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Benefit of extend Segment routing to support TwoD-IP routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Multi-homing . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Source Related Policy Routing . . . . . . . . . . . . . . 5 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 5. Advertisement of TwoD-IP configuration . . . . . . . . . . . 8 5.1. TwoD-IP configuration TLV . . . . . . . . . . . . . . . . 8 5.2. Optimization Object Sub-TLV . . . . . . . . . . . . . . . 9 5.3. Constraints Sub-TLV . . . . . . . . . . . . . . . . . . . 10 5.4. destination/source address Sub-TLV . . . . . . . . . . . 11 6. TwoD-IP forwarding path computation . . . . . . . . . . . . . 12 6.1. Setting up the SR Policy Dynamic candidate path . . . . . 13 6.2. TwoD-IP forwarding table entry creation . . . . . . . . . 13 7. TwoD-IP forwarding table Design . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Xu, et al. Expires 2 April 2022 [Page 2] Internet-Draft SR in TwoD-IP Routing September 2021 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: Xu, et al. Expires 2 April 2022 [Page 3] Internet-Draft SR in TwoD-IP Routing September 2021 * SR: Segment Routing. * TwoD-IP routing protocol: Two Dimensional IP routing protocol, which makes routing decisions based on both destination and source IP addresses. * SID: Segment Identifier. * SRv6: Segment Routing over IPv6 data plane. * SR Policy: a framework that enables instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node. 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. Xu, et al. Expires 2 April 2022 [Page 4] Internet-Draft SR in TwoD-IP Routing September 2021 +--------------------+ | | | 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. 3.2. Source Related Policy Routing 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. Xu, et al. Expires 2 April 2022 [Page 5] Internet-Draft SR in TwoD-IP Routing September 2021 +---------+ +------+ 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 two parts: data plane and control plane. 4.1. Data Plane TCAM resources are future limited to the higher dimensional routing, including TwoD-IP routing. [I-D.xu-rtgwg-twod-ip-routing] propose a novel forwarding table design to increase the TCAM resource utilizatioin significantly. The data plane of extending SR to support TwoD-IP routing introduces this Two-D forwarding table design into the original SR data plane. Considering Segment Routing leverages the source routing paradigm, administrator just need to deploy TwoD-IP forwarding table in headend node, which makes implementing TwoD-IP routing much easier. Different with traditional destination-based FIB, each entry in the TwoD-IP forwarding table is a 3-tuple: {destination address, source address, next hop} [I-D.xu-rtgwg-twod-ip-routing] Xu, et al. Expires 2 April 2022 [Page 6] Internet-Draft SR in TwoD-IP Routing September 2021 The next hop in the TwoD-IP forwarding table should steer the packet into the associated SR Policy, and the SR architecture has provided an identifier to do that: Binding segment/BSID. The headend of an SR Policy binds a SID(BSID) to its policy, so the next hop in TwoD-IP forwarding table should be a BSID, which is associated with the SR Policy that corresponding to the entry's pairs. So the TwoD-IP forwarding table tuple is {destination address, source address, BSID}, when a packet arrive, the headend node can extract both destination and source addresses from the packet, then lookup the Two-IP forwarding table, and output a matched entry. Finally, headend node will forward the packet to the matched entry's next hop, which is a BSID associated with a SR Policy, to get the dynamic candidate path that steers it to the destination. Segment Routing can be instantiated on two data planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6). Different data plane has different BSID format, in SR-MPLS, SID are an MPLS label or an index into an MPLS label space, in SRv6, SID is an IPv6 address. So even we could deploy TwoD-IP routing on both two data planes, we still deploy TwoD-IP routing with SR over IPv6(SRv6), so that the next hop elements in TwoD-IP forwarding table will be SRv6 BSID which is an IPv6 address. 4.2. Control Plane Within TwoD-IP routing, the control plane is concerned with user demands, it focus on providing services that are related with source addresses. They need to collect demands from users, and compute the routing table to satisfy these demands. And Segment Routing support many control plane. So we can extend one of them to achieve configuration exchange and optimal forwarding path computation objects.. * TwoD-IP configuration exchange: TwoD-IP routing protocol focus on transforming users demand for destination and source address pairs to forwarding action, which mean that we have one more dimension of source address information to exchange along with headend node, and the forwarding configurations corresponding to the destination and source address pairs. * TwoD-IP forwarding path computation: We leverage the SR Policy Dynamic Path Computation to achieve forwarding path computation, transferring our demand for pair to optimization object and constraint source format which can specify a dynamic candidate path of SR Policy, then the dynamic candidate path can be computed by either the headend or a Path Computation Xu, et al. Expires 2 April 2022 [Page 7] Internet-Draft SR in TwoD-IP Routing September 2021 Element (PCE). So TwoD-IP routing protocol doesn't need to concern about how the candidate path is computed and what the path really is. 5. Advertisement of TwoD-IP configuration TwoD-IP configuration needs to be installed in the headend node so that the headend node can creates the TwoD-IP forwarding table entry and the SR Policy with dynamic candidate path corresponding it. The TwoD-IP configuration can be installed in headend node manually or automatically by advertising of TwoD-IP configurations between nodes. A TwoD-IP configuration contains three parts: destination addresses,source addresses and the user demands of the pairs, including optimization objective and constraints. 5.1. TwoD-IP configuration TLV The configurations of TwoD-IP routing is within the TwoD-IP configuration TLV, the TwoD-IP configuration TLV is a TLV of OSPFv3 Router Information(RI) LSA, TwoD-IP configuration information will be broadcast by letting An OSPF router advertising an OSPFv3 RI LSA that include the TwoD-IP configuration TLV. Because TwoD-IP routing is deployed in SR over IPv6, the OSPF router will exchange router information with OSPFv3 Router Information(RI) LSA. The router may advertise multiple instances of TwoD-IP configuration TLV within the OSPFv3 Router Information(RI) LSA - one for each of the TwoD-IP configuration needs to be advertised. The format of 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: Xu, et al. Expires 2 April 2022 [Page 8] Internet-Draft SR in TwoD-IP Routing September 2021 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 four Sub-TLVs: Optimization Object Sub-TLV, Constraint Sub-TLV, destination and source address Sub-TLV. There could be multiple Sub-TLV of them to specify the dynamic candidate path of SR Policy and the pairs associated the SR Policy. 5.2. Optimization Object Sub-TLV The Optimization and the constraint is basically refer to [I-D.filsfils-spring-sr-policy-considerations]. The format of Optimization 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 | Flags | T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 TLV. Reserved (20 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Flags(4 bits): Identify the optimization objective, The following flags are defined: 0 1 2 3 +-+-+-+-+ |M|N| | +-+-+-+-+ Where: Xu, et al. Expires 2 April 2022 [Page 9] Internet-Draft SR in TwoD-IP Routing September 2021 * 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. 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 5.3. Constraints Sub-TLV The constrains we use in TwoD-IP routing is Inclusion and/or exclusion some node/service identified as a IPv6 address. The format of Optimization 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 | Flags | T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | variable | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Constraints Sub-TLV Format Where: Type: 16 bit field. The value is 2 for this type. Length: 16 bit field. The total length of the value portion of the TLV. Reserved (20 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Flags(4 bits): Identify the optimization objective, The following Xu, et al. Expires 2 April 2022 [Page 10] Internet-Draft SR in TwoD-IP Routing September 2021 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) T (Type - 8 bits): Specifies the metric type. Two values are currently defined: * T=1: TE affinity * T=2: IPv6 address(can be a SRv6 SID) variable: 128 bit field. Corresponding the variable defined in T. 5.4. destination/source address Sub-TLV A TwoD-IP routing demand corresponding a pair, so the Optimization object and constraint define a TwoD-IP demand and naturally need to bind a pair. The pair's information is carried in destination/source address Sub-TLV, and it's format is: Xu, et al. Expires 2 April 2022 [Page 11] Internet-Draft SR in TwoD-IP Routing September 2021 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 | 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. Reserved (8 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. TwoD-IP forwarding path computation The procedure of transforming the TwoD-IP configuration to a candidate path has two steps: setting up the SR Policy Dynamic candidate path and TwoD-IP forwarding table entry creation. Xu, et al. Expires 2 April 2022 [Page 12] Internet-Draft SR in TwoD-IP Routing September 2021 6.1. Setting up the SR Policy Dynamic candidate path The TwoD-IP configuration contains the Optimization object and constraint information, when the headend node receive TwoD-IP configuration information(manually or automatically), it will extracts the Optimization object and constraint information to generate a SR Policy which enable Dynamic candidate path. An SR Policy is identified through the tuple,[I-D.ietf-spring-segment-routing-policy] so the headend node will extract the first destination address in TwoD-IP configuration TLV - destination address Sub-TLV as the endpoint, dynamic assign a color value to distinguish the SR Policy from others with the same endpoint. And the candidate path associated to the SR Policy is a dynamic candidate path which expresses an optimization objective and a set of constraints that extract from the TwoD-IP configuration TLV - Optimization Object Sub-TLV and Constraint Sub- TLV. Then the headend node(or with the help of a PCE) computes the solution Segment-List that solve the optimization problem and also match our TwoD-IP routing demand. 6.2. TwoD-IP forwarding table entry creation After Setting up the SR Policy dynamic candidate path, the active dynamic candidate path will be defined with a BSID which can steers the packets to the dynamic candidate path, and installs the BSID- keyed entry in the TwoD-IP forwarding table. The TwoD-IP forwarding table has two dimensions: destination and source, so TwoD-IP forwarding table has two index: destination address and source address, a pair of determines a action(next hop) which is a BSID. The headend node receives a TwoD-IP configuration TLV, generates a SR Policy depends on it, and also will creates pairs in TwoD-IP forwarding table as a index, and installs their action(next hop) with the BSID that define the dynamic candidate path generated with the same TwoD-IP configuration TLV informations. 7. TwoD-IP forwarding table Design Traditional forwarding table only supports making forwarding decisions based on destination IP addresses even in Segment Routing architecture. TwoD-IP routing needs a new forwarding table structure that supports making forwarding decisions based on both destination and source IP addresses. Xu, et al. Expires 2 April 2022 [Page 13] Internet-Draft SR in TwoD-IP Routing September 2021 Considering the compatibility with Segment Routing architecture, There's no need to modify the FIB structure directly. we imitate the way SR Policy process interacting with the FIB process to install our TwoD IP process in data plane. we just need to install in FIB with destination address that in the active TwoD-IP pair with next-hop = TwoD IP routing process which maintain a TwoD IP Forwarding table. The TwoD-IP forwarding table structure is the same as [I-D.xu-rtgwg-twod-ip-routing] called FIST which is designed to avoid forwarding table explosion with a new source dimension. In conclusion, TwoD IP routing procedure maintains a TwoD-IP forwarding table separate from the headend node's FIB and installs FIB entries with destination addresses in the chosen pairs with next-hop = TwoD IP routing interface. When a headend node receives a packet with destination matching the destination address of TwoD IP routing pairs, headend node steers the packet to TwoD IP routing process to the TwoD-IP forwarding table, then the headend node will lookup the TwoD-IP forwarding table base on the packet's both destination and source address extracted from the packet and output a matched entry. Finally, headend node will forward the packet to the next hop associated with the matched entry, which is a BSID, after steering the packet to the BSID, the headend node will insert the Segment-List of the dynamic candidate path of the BSID to the packet head so that it can be forwarded through this path SR Policy process interacts with the RIB/FIB process to install an active SR Policy in the data plane.[I-D.filsfils-spring-sr-policy-considerations] TwoD IP routing protocol doesn't change the FIB structure so Segment Routing's advanced features like On-Demand Next Hop will still work. (we allocate higher authority to TwoD IP routing process to install and modify FIB entries to avoid conflicting) 8. Security Considerations This document does not introduce additional security requirements and mechanisms. 9. IANA Considerations Some newly designed TwoD-IP routing protocols may need new protocol numbers assigned by IANA. Xu, et al. Expires 2 April 2022 [Page 14] Internet-Draft SR in TwoD-IP Routing September 2021 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, July 2018, . 10.2. Informative References [I-D.filsfils-spring-sr-policy-considerations] Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and P. Mattes, "SR Policy Implementation and Deployment Considerations", Work in Progress, Internet-Draft, draft- filsfils-spring-sr-policy-considerations-07, 4 April 2021, . [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-13, 28 May 2021, . [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-05, 10 September 2021, . [I-D.xu-rtgwg-twod-ip-routing] Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP Routing Architecture", Work in Progress, Internet-Draft, draft-xu-rtgwg-twod-ip-routing-00, 4 March 2012, . Xu, et al. Expires 2 April 2022 [Page 15] Internet-Draft SR in TwoD-IP Routing September 2021 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for IPv6", RFC 4177, DOI 10.17487/RFC4177, September 2005, . Authors' Addresses Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing Phone: +86-10-6278-5822 Email: xmw@cernet.edu.cn Bo Wang Tsinghua University Beijing Email: wangbo2019@tsinghua.edu.cn Tingfeng Wang Beijing University of Posts and Telecommunications Beijing P.R. China Email: wangtingfeng@bupt.edu.cn Jianping Tsinghua University Beijing P.R. China Email: jianping@cernet.edu.cn Xu, et al. Expires 2 April 2022 [Page 16]