idnits 2.17.1 draft-xu-spring-segment-twod-ip-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2021) is 953 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-filsfils-spring-sr-policy-considerations-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 == Outdated reference: A later version (-01) exists of draft-xu-rtgwg-twod-ip-routing-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group M. Xu 3 Internet-Draft B. Wang 4 Intended status: Informational Tsinghua University 5 Expires: 2 April 2022 T. Wang 6 Beijing University of Posts and Telecommunications 7 J. Wu 8 Tsinghua University 9 September 2021 11 Segment Routing in Two Dimensional IP Routing 12 draft-xu-spring-segment-twod-ip-routing-00 14 Abstract 16 Segment Routing (SR) allows a headend node to steer traffic into a 17 Segment Routing Policy (SR Policy), which represents the routing path 18 by matching the destination address and the corresponding Binding 19 Segment Identifier (BSID). However, determining the target SR Policy 20 only based on destination aspect is incapable for demands for higher 21 dimensional routing. Two Dimensional IP (TwoD-IP) routing is an 22 Internet routing architecture that makes forwarding decisions based 23 on source and destination addresses. TwoD-IP routing can easily 24 express a routing policy between host to host, or network to network, 25 and have much lower storage and calculation consumption compared to 26 the higher dimensional routing. 28 In this document, we extend SR to support TwoD-IP routing, illustrate 29 some typical scenarios of SR with TwoD-IP routing to express the 30 advantage of extending SR to support TwoD-IP routing, and describe 31 the mechanism of how TwoD IP routing protocol cooperates with SR. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 5 March 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Benefit of extend Segment routing to support TwoD-IP 75 routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Multi-homing . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Source Related Policy Routing . . . . . . . . . . . . . . 5 78 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 81 5. Advertisement of TwoD-IP configuration . . . . . . . . . . . 8 82 5.1. TwoD-IP configuration TLV . . . . . . . . . . . . . . . . 8 83 5.2. Optimization Object Sub-TLV . . . . . . . . . . . . . . . 9 84 5.3. Constraints Sub-TLV . . . . . . . . . . . . . . . . . . . 10 85 5.4. destination/source address Sub-TLV . . . . . . . . . . . 11 86 6. TwoD-IP forwarding path computation . . . . . . . . . . . . . 12 87 6.1. Setting up the SR Policy Dynamic candidate path . . . . . 13 88 6.2. TwoD-IP forwarding table entry creation . . . . . . . . . 13 89 7. TwoD-IP forwarding table Design . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 10.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 Segment routing (SR) [RFC8402] allows a headend node to steer a 100 packet flow into an Segment Routing Policy (SR Policy), which 101 represents the routing path. So that the administrator can specific 102 forwarding path on headend node 103 [I-D.ietf-spring-segment-routing-policy]. 105 The headend node can steers packets into an SR Policy either by 106 matching the destination address or routing policy. However, due to 107 the increasing demands of higher dimensional routing like Multi- 108 homing or Source Related Policy Routing, only directs packets based 109 on destination aspect is limited under those scenarios. Moreover, 110 directing packets into SR Policy by routing policy, which can match 111 other fields in packets like port and source address, needs many 112 access in memory. Considering the high-speed ternary content- 113 addressable memory (TCAM) based solution for routers is limited by 114 its low capacity, simply adding one more dimension on routing policy 115 can easily become undeployable on TCAM-based solution. 117 To achieve higher Dimensional routing objectives, we introduce Two 118 Dimensional-IP (TwoD-IP) routing protocol. 119 [I-D.xu-rtgwg-twod-ip-routing] The TwoD-IP routing architecture can 120 easily express a routing policy between host to host, or network to 121 network, and have much lower storage and calculation consumption 122 compared to higher dimensional routing. 124 In this document, we extend Segment Routing to support Two 125 Dimensional IP(TwoD-IP) routing to enriches the routing abilities, 126 describe how they cooperate to achieve higher dimensional routing 127 like Multi-homing. 129 To extend Segment Routing to support Two Dimensional IP(TwoD-IP) 130 routing, modification of the data plane and control plane is 131 necessary. In data plane, the TwoD-IP routing protocol needs a TwoD- 132 IP forwarding table to stores the source and destination address 133 information. In control plane, the TwoD-IP routing protocol 134 leverages OSPFv3 Router Information(RI) LSA to broadcast 135 configuration and the SR Policy Dynamic Path Computation to compute 136 optimal forwarding path under setting configuration. With these 137 modifications, the headend node will be able to make forwarding 138 decisions base on both source and destination aspects without 139 damaging existing SR architecture. 141 2. Terminology 143 Terminology used in this document: 145 * SR: Segment Routing. 147 * TwoD-IP routing protocol: Two Dimensional IP routing protocol, 148 which makes routing decisions based on both destination and source 149 IP addresses. 151 * SID: Segment Identifier. 153 * SRv6: Segment Routing over IPv6 data plane. 155 * SR Policy: a framework that enables instantiation of an ordered 156 list of segments on a node for implementing a source routing 157 policy with a specific intent for traffic steering from that node. 159 3. Benefit of extend Segment routing to support TwoD-IP routing 161 This section lists two scenarios which can benefit from TwoD-IP 162 routing protocol with Segment Routing technology. Illustrating that 163 TwoD-IP routing protocol can seamless deployment with SR and combine 164 their advantage to achieve users demands of higher dimensional 165 routing. 167 3.1. Multi-homing 169 Even though Segment Routing is able to steer flows to the destination 170 in different way, it is still limited to process the source-related 171 routing scenario like Multi-homing. 173 Multi-homing[RFC4177] is prevalent among ISPs for better traffic 174 distribution and reliability. In this case, a network could be 175 connected to multiple upstream ISPs, Hosts are assigned multiple 176 addresses, one for each ISP. The network is responsible for 177 delivering packets from Hosts to the export exit router that is 178 connected to the corresponding upstream ISP. 180 For example, in Figure 1, a multi-homed site is connected to two 181 ISPs: ISP1 and ISP2. ISP1 has a prefix P1, and ISP2 has a prefix P2. 182 A host connect to the multi-homed site has two addresses, address A 183 that assigned from ISP1, and address B that assigned from ISP2. the 184 multi-homed site should deliver the traffic from A towards the 185 Internet to ISP1, and deliver the traffic from B towards the Internet 186 to ISP2. 188 +--------------------+ 189 | | 190 | Internet | 191 | | 192 +--+---------------+-+ 193 | | 194 | l3 | l4 195 | | 196 +------+----+ +--+--------+ 197 | ISP1 | | ISP2 | 198 | Prefix P1 | | Prefix P2 | 199 +--------+--+ +-+---------+ 200 | | 201 | l1 | l2 202 +--+------------+--+ 203 | | 204 | Multi-homed Site | +---------+ 205 | +--------+ Host | 206 +------------------+ +---------+ 207 ISP1 assign address: A 208 ISP2 assign address: B 210 Figure 1: Multi-homing scenario 212 Although SR can assign different forwarding paths to different ISP 213 for an incoming packet, it still lacks the ability to classify the 214 packets toward the same destination address with different source 215 addresses A and B. With the help of TwoD-IP and Segment Routing, the 216 administrator can easily implement Multi-homing by modifying the 217 headend node that receives packets from Host, which means that 218 administrator does not need to concern about the intermediate node. 219 After extending SR to support TwoD-IP routing, the headend node can 220 routing packet based on both source and destination address, guides 221 packets from Host through the optimal path to the corresponding ISP. 223 3.2. Source Related Policy Routing 225 In this scenario, an ingress edge node wants to forward packets with 226 the same destination address through different kind of paths in order 227 to achieve source related demand. 229 For example, in Figure 2, assume a network has four routers: a, b, c 230 and d, c has a service(such as authentication or encipherer). The 231 operator wants a packet from a to d to be delivered to service c 232 first and then node c will forward the processed packet to it's 233 destination d. 235 +---------+ 236 +------+ c +-----+ 237 | +(service)+ | 238 | +---------+ | 239 | | 240 +------+ +--+---+ +---+--+ 241 | a +----------+ b +--------------+ d | 242 +------+ +------+ +------+ 244 Figure 2: TwoD-IP routing for Service 246 In Segment Routing Architecture, we can allocate a Service segment 247 associated with node c's 248 service.[I-D.ietf-spring-sr-service-programming] and can be 249 integrated as part of an SR Policy P1(Headend node: b, color, 250 Endpoint: d) of Segment-List < c > . But SR Policy steers packets to 251 a specific SR Policy only when this packet's destination matching 252 corresponding entry, which means headend node can't only steers 253 packets from a to SR Policy P1. 255 But with TwoD-IP routing, headend node b can easily steer packets 256 matching destination of b and source of a to SR Policy P1, then the 257 packet will be delivered to service c first and then node c will 258 forward the processed packet to it's destination d. 260 4. Framework 262 The mechanism of how we combine TwoD IP routing and Segment Routing 263 can be separated into two parts: data plane and control plane. 265 4.1. Data Plane 267 TCAM resources are future limited to the higher dimensional routing, 268 including TwoD-IP routing. [I-D.xu-rtgwg-twod-ip-routing] propose a 269 novel forwarding table design to increase the TCAM resource 270 utilizatioin significantly. The data plane of extending SR to 271 support TwoD-IP routing introduces this Two-D forwarding table design 272 into the original SR data plane. 274 Considering Segment Routing leverages the source routing paradigm, 275 administrator just need to deploy TwoD-IP forwarding table in headend 276 node, which makes implementing TwoD-IP routing much easier. 277 Different with traditional destination-based FIB, each entry in the 278 TwoD-IP forwarding table is a 3-tuple: {destination address, source 279 address, next hop} [I-D.xu-rtgwg-twod-ip-routing] 280 The next hop in the TwoD-IP forwarding table should steer the packet 281 into the associated SR Policy, and the SR architecture has provided 282 an identifier to do that: Binding segment/BSID. The headend of an SR 283 Policy binds a SID(BSID) to its policy, so the next hop in TwoD-IP 284 forwarding table should be a BSID, which is associated with the SR 285 Policy that corresponding to the entry's pairs. 288 So the TwoD-IP forwarding table tuple is {destination address, source 289 address, BSID}, when a packet arrive, the headend node can extract 290 both destination and source addresses from the packet, then lookup 291 the Two-IP forwarding table, and output a matched entry. Finally, 292 headend node will forward the packet to the matched entry's next hop, 293 which is a BSID associated with a SR Policy, to get the dynamic 294 candidate path that steers it to the destination. 296 Segment Routing can be instantiated on two data planes: SR over MPLS 297 (SR-MPLS) and SR over IPv6 (SRv6). Different data plane has 298 different BSID format, in SR-MPLS, SID are an MPLS label or an index 299 into an MPLS label space, in SRv6, SID is an IPv6 address. So even 300 we could deploy TwoD-IP routing on both two data planes, we still 301 deploy TwoD-IP routing with SR over IPv6(SRv6), so that the next hop 302 elements in TwoD-IP forwarding table will be SRv6 BSID which is an 303 IPv6 address. 305 4.2. Control Plane 307 Within TwoD-IP routing, the control plane is concerned with user 308 demands, it focus on providing services that are related with source 309 addresses. They need to collect demands from users, and compute the 310 routing table to satisfy these demands. And Segment Routing support 311 many control plane. So we can extend one of them to achieve 312 configuration exchange and optimal forwarding path computation 313 objects.. 315 * TwoD-IP configuration exchange: TwoD-IP routing protocol focus on 316 transforming users demand for destination and source address pairs 317 to forwarding action, which mean that we have one more dimension 318 of source address information to exchange along with headend node, 319 and the forwarding configurations corresponding to the destination 320 and source address pairs. 322 * TwoD-IP forwarding path computation: We leverage the SR Policy 323 Dynamic Path Computation to achieve forwarding path computation, 324 transferring our demand for pair to 325 optimization object and constraint source format which can specify 326 a dynamic candidate path of SR Policy, then the dynamic candidate 327 path can be computed by either the headend or a Path Computation 328 Element (PCE). So TwoD-IP routing protocol doesn't need to 329 concern about how the candidate path is computed and what the path 330 really is. 332 5. Advertisement of TwoD-IP configuration 334 TwoD-IP configuration needs to be installed in the headend node so 335 that the headend node can creates the TwoD-IP forwarding table entry 336 and the SR Policy with dynamic candidate path corresponding it. The 337 TwoD-IP configuration can be installed in headend node manually or 338 automatically by advertising of TwoD-IP configurations between nodes. 340 A TwoD-IP configuration contains three parts: destination 341 addresses,source addresses and the user demands of the pairs, including optimization objective and constraints. 344 5.1. TwoD-IP configuration TLV 346 The configurations of TwoD-IP routing is within the TwoD-IP 347 configuration TLV, the TwoD-IP configuration TLV is a TLV of OSPFv3 348 Router Information(RI) LSA, TwoD-IP configuration information will be 349 broadcast by letting An OSPF router advertising an OSPFv3 RI LSA that 350 include the TwoD-IP configuration TLV. 352 Because TwoD-IP routing is deployed in SR over IPv6, the OSPF router 353 will exchange router information with OSPFv3 Router Information(RI) 354 LSA. 356 The router may advertise multiple instances of TwoD-IP configuration 357 TLV within the OSPFv3 Router Information(RI) LSA - one for each of 358 the TwoD-IP configuration needs to be advertised. 360 The format of the TwoD-IP configuration TLV is the same as the format 361 used by[RFC3630]. The variable TLV section consists of one or more 362 nested TLV tuples. The format of each TLV is: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Sub-TLVs | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 3. TwoD-IP configuration TLV Format 374 Where: 376 Type is TBD 378 Length: 16 bit field. The total length of the value portion(Sub- 379 TLVs) of the TLV 381 Sub-TLVs: Each TwoD-IP configuration TLV has four Sub-TLVs: 382 Optimization Object Sub-TLV, Constraint Sub-TLV, destination and 383 source address Sub-TLV. There could be multiple Sub-TLV of them 384 to specify the dynamic candidate path of SR Policy and the 385 pairs associated the SR 386 Policy. 388 5.2. Optimization Object Sub-TLV 390 The Optimization and the constraint is basically refer to 391 [I-D.filsfils-spring-sr-policy-considerations]. 393 The format of Optimization Object Sub-TLV is: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Reserved | Flags | T | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 4: Optimization Object Sub-TLV Format 405 Where: 407 Type: 16 bit field. The value is 1 for this type. 409 Length: 16 bit field. The total length of the value portion of 410 the TLV. 412 Reserved (20 bits): This field MUST be set to zero on transmission 413 and MUST be ignored on receipt. 415 Flags(4 bits): Identify the optimization objective, The following 416 flags are defined: 418 0 1 2 3 419 +-+-+-+-+ 420 |M|N| | 421 +-+-+-+-+ 423 Where: 425 * M flag: Min-Metric - requests computation of a solution 426 Segment-List optimized for a selected metric. 428 * N flag: Min-Metric with margin and maximum number of SIDs - Min 429 Metric with two changes: a margin of by which two paths with 430 similar metrics would be considered equal, a constraint on the 431 max number of SIDs in the Segment-List. 433 T (Type - 8 bits): Specifies the metric type. Three values are 434 currently defined: 436 * T=1: IGP metric 438 * T=2: TE metric 440 * T=3: Hop Counts 442 5.3. Constraints Sub-TLV 444 The constrains we use in TwoD-IP routing is Inclusion and/or 445 exclusion some node/service identified as a IPv6 address. 447 The format of Optimization Object Sub-TLV is: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved | Flags | T | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | variable | 457 | ... | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 5: Constraints Sub-TLV Format 462 Where: 464 Type: 16 bit field. The value is 2 for this type. 466 Length: 16 bit field. The total length of the value portion of 467 the TLV. 469 Reserved (20 bits): This field MUST be set to zero on transmission 470 and MUST be ignored on receipt. 472 Flags(4 bits): Identify the optimization objective, The following 473 flags are defined: 475 0 1 2 3 476 +-+-+-+-+ 477 |I|E|D| | 478 +-+-+-+-+ 480 Where: 482 * I flag: Inclusion 484 * E flag: Exclusion 486 * D flag: Diversity to another service instance (e.g., link, 487 node) 489 T (Type - 8 bits): Specifies the metric type. Two values are 490 currently defined: 492 * T=1: TE affinity 494 * T=2: IPv6 address(can be a SRv6 SID) 496 variable: 128 bit field. Corresponding the variable defined in T. 498 5.4. destination/source address Sub-TLV 500 A TwoD-IP routing demand corresponding a pair, 501 so the Optimization object and constraint define a TwoD-IP demand and 502 naturally need to bind a pair. The pair's 503 information is carried in destination/source address Sub-TLV, and 504 it's format is: 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | PrefixLength | Reserved | PrefixNumbers | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Address Prefix1 | 514 | ... | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Address Prefix2 | 517 | ... | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | ... | 520 | | 522 Figure 6: destination/source address Sub-TLV Format 524 Where: 526 Type: 16 bit field. The value is 3 for destination address, 4 for 527 source address. 529 Length: 16 bit field. The total length of the value 530 portion(addresses information) of the TLV. 532 PrefixLength: 8 bit field. The length of IPv6 address. The IPv6 533 address information is transferring in Prefix format in order to 534 reduce packet length and all the addresses needed to transferring 535 is group by same prefix length. 537 Reserved (8 bits): This field MUST be set to zero on transmission 538 and MUST be ignored on receipt. 540 PrefixNumbers: 16 bit field. The number of address prefix in the 541 length of PrefixLength. 543 Address Prefix: The address prefix in the length of PrefixLength 544 and will be padded with 0 to fit the multiple 32 bit length. 546 6. TwoD-IP forwarding path computation 548 The procedure of transforming the TwoD-IP configuration to a 549 candidate path has two steps: setting up the SR Policy Dynamic 550 candidate path and TwoD-IP forwarding table entry creation. 552 6.1. Setting up the SR Policy Dynamic candidate path 554 The TwoD-IP configuration contains the Optimization object and 555 constraint information, when the headend node receive TwoD-IP 556 configuration information(manually or automatically), it will 557 extracts the Optimization object and constraint information to 558 generate a SR Policy which enable Dynamic candidate path. 560 An SR Policy is identified through the tuple,[I-D.ietf-spring-segment-routing-policy] so the headend 562 node will extract the first destination address in TwoD-IP 563 configuration TLV - destination address Sub-TLV as the endpoint, 564 dynamic assign a color value to distinguish the SR Policy from others 565 with the same endpoint. And the candidate path associated to the SR 566 Policy is a dynamic candidate path which expresses an optimization 567 objective and a set of constraints that extract from the TwoD-IP 568 configuration TLV - Optimization Object Sub-TLV and Constraint Sub- 569 TLV. Then the headend node(or with the help of a PCE) computes the 570 solution Segment-List that solve the optimization problem and also 571 match our TwoD-IP routing demand. 573 6.2. TwoD-IP forwarding table entry creation 575 After Setting up the SR Policy dynamic candidate path, the active 576 dynamic candidate path will be defined with a BSID which can steers 577 the packets to the dynamic candidate path, and installs the BSID- 578 keyed entry in the TwoD-IP forwarding table. 580 The TwoD-IP forwarding table has two dimensions: destination and 581 source, so TwoD-IP forwarding table has two index: destination 582 address and source address, a pair of determines a action(next hop) which is a BSID. 585 The headend node receives a TwoD-IP configuration TLV, generates a SR 586 Policy depends on it, and also will creates pairs in TwoD-IP forwarding table as a index, and 588 installs their action(next hop) with the BSID that define the dynamic 589 candidate path generated with the same TwoD-IP configuration TLV 590 informations. 592 7. TwoD-IP forwarding table Design 594 Traditional forwarding table only supports making forwarding 595 decisions based on destination IP addresses even in Segment Routing 596 architecture. TwoD-IP routing needs a new forwarding table structure 597 that supports making forwarding decisions based on both destination 598 and source IP addresses. 600 Considering the compatibility with Segment Routing architecture, 601 There's no need to modify the FIB structure directly. we imitate the 602 way SR Policy process interacting with the FIB process to install our 603 TwoD IP process in data plane. we just need to install in FIB with 604 destination address that in the active TwoD-IP 605 pair with next-hop = TwoD IP routing process which maintain a TwoD IP 606 Forwarding table. 608 The TwoD-IP forwarding table structure is the same as 609 [I-D.xu-rtgwg-twod-ip-routing] called FIST which is designed to avoid 610 forwarding table explosion with a new source dimension. 612 In conclusion, TwoD IP routing procedure maintains a TwoD-IP 613 forwarding table separate from the headend node's FIB and installs 614 FIB entries with destination addresses in the chosen pairs with next-hop = TwoD IP routing 616 interface. 618 When a headend node receives a packet with destination matching the 619 destination address of TwoD IP routing pairs, headend node steers the 620 packet to TwoD IP routing process to the TwoD-IP forwarding table, 621 then the headend node will lookup the TwoD-IP forwarding table base 622 on the packet's both destination and source address extracted from 623 the packet and output a matched entry. Finally, headend node will 624 forward the packet to the next hop associated with the matched entry, 625 which is a BSID, after steering the packet to the BSID, the headend 626 node will insert the Segment-List of the dynamic candidate path of 627 the BSID to the packet head so that it can be forwarded through this 628 path 630 SR Policy process interacts with the RIB/FIB process to install an 631 active SR Policy in the data 632 plane.[I-D.filsfils-spring-sr-policy-considerations] TwoD IP routing 633 protocol doesn't change the FIB structure so Segment Routing's 634 advanced features like On-Demand Next Hop will still work. (we 635 allocate higher authority to TwoD IP routing process to install and 636 modify FIB entries to avoid conflicting) 638 8. Security Considerations 640 This document does not introduce additional security requirements and 641 mechanisms. 643 9. IANA Considerations 645 Some newly designed TwoD-IP routing protocols may need new protocol 646 numbers assigned by IANA. 648 10. References 650 10.1. Normative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 658 Decraene, B., Litkowski, S., and R. Shakir, "Segment 659 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 660 July 2018, . 662 10.2. Informative References 664 [I-D.filsfils-spring-sr-policy-considerations] 665 Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and 666 P. Mattes, "SR Policy Implementation and Deployment 667 Considerations", Work in Progress, Internet-Draft, draft- 668 filsfils-spring-sr-policy-considerations-07, 4 April 2021, 669 . 672 [I-D.ietf-spring-segment-routing-policy] 673 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 674 P. Mattes, "Segment Routing Policy Architecture", Work in 675 Progress, Internet-Draft, draft-ietf-spring-segment- 676 routing-policy-13, 28 May 2021, 677 . 680 [I-D.ietf-spring-sr-service-programming] 681 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 682 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 683 S. Salsano, "Service Programming with Segment Routing", 684 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 685 service-programming-05, 10 September 2021, 686 . 689 [I-D.xu-rtgwg-twod-ip-routing] 690 Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP 691 Routing Architecture", Work in Progress, Internet-Draft, 692 draft-xu-rtgwg-twod-ip-routing-00, 4 March 2012, 693 . 696 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 697 (TE) Extensions to OSPF Version 2", RFC 3630, 698 DOI 10.17487/RFC3630, September 2003, 699 . 701 [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for 702 IPv6", RFC 4177, DOI 10.17487/RFC4177, September 2005, 703 . 705 Authors' Addresses 707 Mingwei Xu 708 Tsinghua University 709 Department of Computer Science, Tsinghua University 710 Beijing 712 Phone: +86-10-6278-5822 713 Email: xmw@cernet.edu.cn 715 Bo Wang 716 Tsinghua University 717 Beijing 719 Email: wangbo2019@tsinghua.edu.cn 721 Tingfeng Wang 722 Beijing University of Posts and Telecommunications 723 Beijing 724 P.R. China 726 Email: wangtingfeng@bupt.edu.cn 728 Jianping 729 Tsinghua University 730 Beijing 731 P.R. China 733 Email: jianping@cernet.edu.cn