idnits 2.17.1 draft-filsfils-spring-srv6-net-pgm-illustration-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-spring-srv6-network-programming]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 72 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 14, 2019) is 1689 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 945, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING C. Filsfils 3 Internet-Draft P. Camarillo, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: February 15, 2020 Z. Li 6 Huawei Technologies 7 S. Matsushima 8 SoftBank 9 B. Decraene 10 Orange 11 D. Steinberg 12 Lapishills Consulting Limited 13 D. Lebrun 14 Google 15 R. Raszuk 16 Bloomberg LP 17 J. Leddy 18 Individual Contributor 19 August 14, 2019 21 Illustrations for SRv6 Network Programming 22 draft-filsfils-spring-srv6-net-pgm-illustration-01 24 Abstract 26 This document illustrates how SRv6 Network Programming 27 [I-D.ietf-spring-srv6-network-programming] can be used to create 28 interoperable and protected overlays with underlay optimization and 29 service programming. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in BCP 36 14 [RFC2119] [RFC8174] when, and only when, they appear in all 37 capitals, as shown here. 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 February 15, 2020. 56 Copyright Notice 58 Copyright (c) 2019 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 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1. Simplified SID allocation . . . . . . . . . . . . . . . . 3 76 2.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 4 77 2.3. Basic security . . . . . . . . . . . . . . . . . . . . . 4 78 2.4. SR-L3VPN . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 6 80 2.6. SR-EVPN-FXC . . . . . . . . . . . . . . . . . . . . . . . 7 81 2.7. SR-EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 2.7.1. EVPN Bridging . . . . . . . . . . . . . . . . . . . . 7 83 2.7.2. EVPN Multi-homing with ESI filtering . . . . . . . . 9 84 2.7.3. EVPN Layer-3 . . . . . . . . . . . . . . . . . . . . 10 85 2.7.4. EVPN Integrated Routing Bridging (IRB) . . . . . . . 11 86 2.8. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 11 87 2.8.1. SR policy from the Ingress PE . . . . . . . . . . . . 11 88 2.8.2. SR policy at a midpoint . . . . . . . . . . . . . . . 12 89 2.9. End-to-End policy with intermediate BSID . . . . . . . . 13 90 2.10. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 2.11. SR TE for Service programming . . . . . . . . . . . . . . 15 92 3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 3.1. Seamless deployment . . . . . . . . . . . . . . . . . . . 17 94 3.2. Integration . . . . . . . . . . . . . . . . . . . . . . . 18 95 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 18 96 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 97 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 98 6. Informative References . . . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 Segment Routing leverages the source routing paradigm. An ingress 104 node steers a packet through a ordered list of instructions, called 105 segments. Each one of these instructions represents a function to be 106 called at a specific location in the network. A function is locally 107 defined on the node where it is executed and may range from simply 108 moving forward in the segment list to any complex user-defined 109 behavior. The network programming consists in combining segment 110 routing functions, both simple and complex, to achieve a networking 111 objective that goes beyond mere packet routing. 113 [I-D.ietf-spring-srv6-network-programming] defines the SRv6 Network 114 Programming concept and the main segment routing behaviors. 116 This document illustrates how these concepts can be used to enable 117 the creation of interoperable overlays with underlay optimization and 118 service programming. 120 The terminology for this document is defined in 121 [I-D.ietf-spring-srv6-network-programming]. 123 2. Illustration 125 We introduce a simplified SID allocation technique to ease the 126 reading of the text. We document the reference diagram. We then 127 illustrate the network programming concept through different use- 128 cases. These use-cases have been thought to allow straightforward 129 combination between each other. 131 2.1. Simplified SID allocation 133 To simplify the illustration, we assume: 135 A::/16 is dedicated to the internal address space 137 B::/16 is dedicated to the internal SRv6 SID space 139 We assume a location expressed in 32 bits and a function expressed 140 in 16 bits 142 Node k has a classic IPv6 loopback address A:k::/128 which is 143 advertised in the IGP 144 Node k has B:k::/32 for its local SID space. Its SIDs will be 145 explicitly allocated from that block 147 Node k advertises B:k::/32 in its IGP 149 Function 0:0:1:: (function 1, for short) represents the End 150 function with PSP support 152 Function 0:0:C2:: (function C2, for short) represents the End.X 153 function towards neighbor 2 155 Each node k has: 157 An explicit SID instantiation B:k:1::/128 bound to an End function 158 with additional support for PSP 160 An explicit SID instantiation B:k:Cj::/128 bound to an End.X 161 function to neighbor J with additional support for PSP 163 2.2. Reference diagram 165 Let us assume the following topology where all the links have IGP 166 metric 10 except the link 3-4 which is 100. 168 Nodes A, B and 1 to 8 are considered within the network domain while 169 nodes CE-A, CE-B and CE-C are outside the domain. 171 CE-B 172 \ 173 3------4---5 174 | \ / 175 | 6 176 | / 177 A--1--- 2------7---8--B 178 / \ 179 CE-A CE-C 180 Tenant100 Tenant100 with 181 IPv4 20/8 183 Figure 1: Reference topology 185 2.3. Basic security 187 Any edge node such as 1 would be configured with an ACL on any of its 188 external interface (e.g. from CE-A) which drops any traffic with SA 189 or DA in B::/16. See SEC-1. 191 Any core node such as 6 could be configured with an ACL with the 192 SEC-2 behavior "IF (DA == LocalSID) && (SA is not in A::/16 or 193 B::/16) THEN drop". 195 SEC-3 protection is a default property of SRv6. A SID must be 196 explicitly instantiated. In our illustration, the only available 197 SIDs are those explicitly instantiated. 199 2.4. SR-L3VPN 201 Let us illustrate the SR-L3VPN use-case applied to IPv4. 203 Nodes 1 and 8 are configured with a tenant 100, each respectively 204 connected to CE-A and CE-C. 206 Node 8 is configured with a locally instantiated End.DT4 SID 207 B:8:D100:: bound to tenant IPv4 table 100. 209 Via BGP signaling or an SDN-based controller, Node 1's tenant-100 210 IPv4 table is programmed with an IPv4 SR-VPN route 20/8 via SRv6 211 policy . 213 When 1 receives a packet P from CE-A destined to 20.20.20.20, 1 looks 214 up 20.20.20.20 in its tenant-100 IPv4 table and finds an SR-VPN entry 215 20/8 via SRv6 policy . As a consequence, 1 pushes an 216 outer IPv6 header with SA=A:1::, DA=B:8:D100:: and NH=4. 1 then 217 forwards the resulting packet on the shortest path to B:8::/32. 219 When 8 receives the packet, 8 matches the DA in its "My SID Table", 220 finds the bound function End.DT4(100) and confirms NH=4. As a 221 result, 8 decaps the outer header, looks up the inner IPv4 DA in 222 tenant-100 IPv4 table, and forward the (inner) IPv4 packet towards 223 CE-C. 225 The reader can easily infer all the other SR-IPVPN instantiations: 227 +---------------------------------+----------------------------------+ 228 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8)| 229 +---------------------------------+----------------------------------+ 230 | IPv4 tenant route with egress | End.DT4 function bound to | 231 | tenant table lookup | IPv4-tenant-100 table | 232 +---------------------------------+----------------------------------+ 233 | IPv4 tenant route without egress| End.DX4 function bound to | 234 | tenant table lookup | CE-C (IPv4) | 235 +---------------------------------+----------------------------------+ 236 | IPv6 tenant route with egress | End.DT6 function bound to | 237 | tenant table lookup | IPv6-tenant-100 table | 238 +---------------------------------+----------------------------------+ 239 | IPv6 tenant route without egress| End.DX6 function bound to | 240 | tenant table lookup | CE-C (IPv6) | 241 +---------------------------------+----------------------------------+ 243 2.5. SR-Ethernet-VPWS 245 Let us illustrate the SR-Ethernet-VPWS use-case. 247 Node 8 is configured a locally instantiated End.DX2 SID B:8:DC2C:: 248 bound to local attachment circuit {ethernet CE-C}. 250 Via BGP signalling or an SDN controller, node 1 is programmed with an 251 Ethernet VPWS service for its local attachment circuit {ethernet CE- 252 A} with remote endpoint B:8:DC2C::. 254 When 1 receives a frame F from CE-A, node 1 pushes an outer IPv6 255 header with SA=A:1::, DA=B:8:DC2C:: and NH=59. Note that no 256 additional header is pushed. 1 then forwards the resulting packet on 257 the shortest path to B:8::/32. 259 When 8 receives the packet, 8 matches the DA in its "My SID Table" 260 and finds the bound function End.DX2. After confirming that next- 261 header=59, 8 decaps the outer IPv6 header and forwards the inner 262 Ethernet frame towards CE-C. 264 The reader can easily infer the Ethernet VPWS use-case: 266 +------------------------+-----------------------------------+ 267 | Route at ingress PE(1) | SR-VPN Egress SID of egress PE(8) | 268 +------------------------+-----------------------------------+ 269 | Ethernet VPWS | End.DX2 function bound to | 270 | | CE-C (Ethernet) | 271 +------------------------+-----------------------------------+ 273 2.6. SR-EVPN-FXC 275 Let us illustrate the SR-EVPN-FXC use-case (Flexible cross-connect 276 service). 278 Node 8 is configured with a locally instantiated End.DX2V SID 279 B:8:DC2C:: bound to the L2 table T1. Node 8 is also configured with 280 local attachment circuits {ethernet CE1-C VLAN:100} and {ethernet 281 CE2-C VLAN:200} in table T1. 283 Via an SDN controller or derived from a BGP-based sginalling, the 284 node 1 is programmed with an EVPN-FXC service for its local 285 attachment circuit {ethernet CE-A} with remote endpoint B:8:DC2C::. 286 For this purpose, the EVPN Type-1 route is used. 288 When node 1 receives a frame F from CE-A, it pushes an outer IPv6 289 header with SA=A:1::, DA=B:8:DC2C:: and NH=59. Note that no 290 additional header is pushed. Node 1 then forwards the resulting 291 packet on the shortest path to B:8::/32. 293 When node 8 receives the packet, it matches the IP DA in its "My SID 294 Table" and finds the bound function End.DX2V. After confirming that 295 next-header=59, node 8 decaps the outer IPv6 header, performs a VLAN 296 loopkup in table T1 and forwards the inner Ethernet frame to matching 297 interface e.g. for VLAN 100, packet is forwarded to CE1-C and for 298 VLAN 200, frame is forwarded to CE2-C. 300 The reader can easily infer the Ethernet FXC use-case: 302 +---------------------------------+------------------------------------+ 303 | Route at ingress PE (1) | SR-VPN Egress SID of egress PE (8) | 304 +---------------------------------+------------------------------------+ 305 | EVPN-FXC | End.DX2V function bound to | 306 | | CE1-C / CE2-C (Ethernet) | 307 +---------------------------------+------------------------------------+ 309 2.7. SR-EVPN 311 The following section details some of the particular use-cases of SR- 312 EVPN. In particular bridging (unicast and multicast), multi-homing 313 ESI filtering, L3 EVPN and EVPN-IRB. 315 2.7.1. EVPN Bridging 317 Let us illustrate the SR-EVPN unicast and multicast bridging. 319 Nodes 1, 3 and 8 are configured with a EVPN bridging service (E-LAN 320 service). 322 Node 1 is configured with a locally instantiated End.DT2U SID 323 B:1:D2AA:: bound to a local L2 table T1 where EVPN is enabled. This 324 SID will be used to attract unicast traffic. Additionally, Node 1 is 325 configured with a locally instantiated End.DT2M SID B:1:D2AF:: bound 326 to the same local L2 table T1. This SID will be used to attract 327 multicast traffic. Node 1 is also configured with local attachment 328 circuit {ethernet CE-A VLAN:100} associated to table T1. 330 A similar instantiation is done at Node 4 and Node 8 resulting in: 332 - Node 1 - My SID table: 334 - End.DT2U SID: B:1:D2AA:: table T1 336 - End.DT2M SID: B:1:D2AF:: table T1 338 - Node 3 - My SID table: 340 - End.DT2U SID: B:3:D2BA:: table T3 342 - End.DT2M SID: B:3:D2BF:: table T3 344 - Node 8 - My SID table: 346 - End.DT2U SID: B:8:D2CA:: table T8 348 - End.DT2M SID: B:8:D2CF:: table T8 350 Nodes 1, 4 and 8 are going to exchange the End.DT2M SIDs via BGP- 351 based EVPN Type-3 route. Upon reception of the EVPN Type-3 routes, 352 each node build its own replication list per L2 table that will be 353 used for ingress BUM traffic replication. The replication lists are 354 the following: 356 - Node 1 - replication list: {B:3:D2BF:: and B:8:D2CF::} 358 - Node 3 - replication list: {B:1:D2AF:: and B:8:D2CF::} 360 - Node 8 - replication list: {B:1:D2AF:: and B:3:D2CF::} 362 When node 1 receives a BUM frame F from CE-A, it replicates that 363 frame to every node in the replication list. For node 3, it pushes 364 an outer IPv6 header with SA=A:1::, DA=B:3:D2BF:: and NH=59. For 365 node 8, it performs the same operation but DA=B:8:D2CF::. Note that 366 no additional headers are pushed. Node 1 then forwards the resulting 367 packets on the shortest path for each destination. 369 When node 3 receives the packet, it matches the DA in its "My SID 370 Table" and finds the bound function End.DT2M with its related layer2 371 table T3. After confirming that next-header=59, node 3 decaps the 372 outer IPv6 header and forwards the inner Ethernet frame to all 373 layer-2 output interface found in table T3. Similar processing is 374 also performed by node 8 upon packet reception. This example is the 375 same for any BUM stream coming from CE-B or CE-C. 377 Node 1,3 and 8 are also performing software MAC learning to exchange 378 MAC reachability information (unicast traffic) via BGP among 379 themselves. 381 Each MAC being learnt is exchanged using BGP-based EVPN Type-2 route. 383 When node 1 receives an unicast frame F from CE-A, it learns its MAC- 384 SA=CEA in software. Node 1 transmits that MAC and its associated SID 385 B:1:D2AA:: using BGP-based EVPN route-type 2 to all remote nodes. 387 When node 3 receives an unicast frame F from CE-B destinated to MAC- 388 DA=CEA, it performs a L2 lookup on T3 to find the associated SID. It 389 pushes an outer IPv6 header with SA=A:3::, DA=B:1:D2AA:: and NH=59. 390 Node 3 then forwards the resulting packet on the shortest path to 391 B:1::/32. Similar processing is also performed by node 8. 393 2.7.2. EVPN Multi-homing with ESI filtering 395 In L2 network, support for traffic loop avoidance is mandatory. In 396 EVPN all-active multi-homing scenario enforces that requirement using 397 ESI filtering. Let us illustrate how it works: 399 Nodes 3 and 4 are peering partners of a redundancy group where the 400 access CE-B, is connected in an all-active multi-homing way with 401 these two nodes. Hence, the topology is the following: 403 CE-B 404 / \ 405 3------4---5 406 | \ / 407 | 6 408 | / 409 A--1--- 2------7---8--B 410 / \ 411 CE-A CE-C 412 Tenant100 Tenant100 with 413 IPv4 20/8 415 EVPN ESI filtering - Reference topology 417 Nodes 3 and 4 are configured with an EVPN bridging service (E-LAN 418 service). 420 Node 3 is configured with a locally instantiated End.DT2M SID 421 B:3:D2BF:: bound to a local L2 table T1 where EVPN is enabled. This 422 SID is also configured with the optional argument Arg.FE2 that 423 specifies the attachment circuit. Particularly, node 3 assigns 424 identifier 0xC1 to {ethernet CE-B}. 426 Node 4 is configured with a locally instantiated End.DT2M SID 427 B:4:D2BF:: bound to a local L2 table T1 where EVPN is enabled. This 428 SID is also configured with the optional argument Arg.FE2 that 429 specifies the attachment circuit. Particularly, node 3 assigns 430 identifier 0xC2 to {ethernet CE-B}. 432 Both End.DT2M SIDs are exchanged between nodes via BGP-based EVPN 433 Type-3 routes. Upon reception of EVPN Type-3 routes, each node build 434 its own replication list per L2 table T1. 436 On the other hand, the End.DT2M SID arguments (Arg.F2) are exchanged 437 between nodes via SRv6 VPN SID attached to the BGP-based EVPN Type-1 438 route. The BGP ESI-filtering extended community label is set to 439 implicit-null [I-D.dawra-idr-srv6-vpn]. 441 Upon reception of EVPN Type-1 route and Type-3 route, node 3 merges 442 merges the End.DT2M SID (B:4:D2BF:) with the Arg.FE2(0:0:0:C2::) from 443 node 4 (its peering partner). This is done by a simple OR bitwise 444 operation. As a result, the replication list on node 3 for the PEs 445 3,4 and 8 is: {B:1:D2AF::; B:4:D2BF:C2::; B:8:D2CF::}. 447 In a similar manner, the replication list on node 4 for the PEs 1,3 448 and 8 is: {B:1:D2AF::; B:3:D2BF:C1::; B:8:D2CF::}. Note that in this 449 case the SID for PE3 contains the OR bitwise operation of SIDs 450 B:3:D2BF:: and 0:0:0:C1::. 452 When node 3 receives a BUM frame F from CE-B, it replicates that 453 frame to remote PEs. For node 4, it pushes an outer IPv6 header with 454 SA=A:1::, DA=B:4:D2AF:C2:: and NH=59. Note that no additional header 455 is pushed. Node 3 then forwards the resulting packet on the shortest 456 path to node 4, and once the packet arrives to node 4, the End.DT2M 457 function is executed forwarding to all L2 OIFs except the ones 458 corresponding to identifier 0xC2. 460 2.7.3. EVPN Layer-3 462 EVPN layer-3 works exactly in the same way than L3VPN. Please refer 463 to section Section 2.4 465 2.7.4. EVPN Integrated Routing Bridging (IRB) 467 EVPN IRB brings Layer-2 and Layer-3 together. It uses BGP-based EVPN 468 Type-2 route to achieve Layer-2 intra-subnet and Layer-3 inter-subnet 469 forwarding. The EVPN Type-2 route-2 maintains the MAC/IP 470 association. 472 Node 8 is configured with a locally instantiated End.DT2U SID 473 B:8:D2C:: used for unicast L2 traffic. Node 8 is also configured 474 with locally instantiated End.DT4 SID B:8:D100:: bound to IPv4 tenant 475 table 100. 477 Node 1 is going to be configured with the EVPN IRB service. 479 Node 8 signals to other remote PEs (1, 3) each ARP/ND request learned 480 via BGP-based EVPN Type-2 route. For example, when node 8 receives 481 an ARP/ND packet P from a host (20.20.20.20) on CE-C destined to 482 10.10.10.10, it learns its MAC-SA=CEC in software. It also learns 483 the ARP/ND entry (IP SA=20.20.20.20) in its cache. Node 8 transmits 484 that MAC/IP and its associated L3 SID (B:8:D100::) and L2 SID 485 (B:8:D2C::). 487 When node 1 receives a packet P from CE-A destined to 20.20.20.20 488 from a host (10.10.10.10), node 1 looks up its tenant-100 IPv4 table 489 and finds an SR-VPN entry for that prefix. As a consequence, node 1 490 pushes an outer IPv6 header with SA=A:1::, DA=B:8:D100:: and NH=4. 491 Node 1 then forwards the resulting packet on the shortest path to 492 B:8::/32. EVPN inter-subnet forwarding is then achieved. 494 When node 1 receives a packet P from CE-A destined to 20.20.20.20 495 from a host (10.10.10.11), P looks up its L2 table T1 MAC-DA lookup 496 to find the associated SID. It pushes an outer IPv6 header with 497 SA=A:1::, DA=B:8:D2C:: and NH=59. Note that no additional header is 498 pushed. Node 8 then forwards the resulting packet on the shortest 499 path to B:8::/32. EVPN intra-subnet forwarding is then achieved. 501 2.8. SR TE for Underlay SLA 503 2.8.1. SR policy from the Ingress PE 505 Let's assume that node 1's tenant-100 IPv4 route "20/8 via 506 B:8:D100::" is programmed with a color/community that requires low- 507 latency underlay optimization 508 [I-D.ietf-spring-segment-routing-policy]. 510 In such case, node 1 either computes the low-latency path to the 511 egress node itself or delegates the computation to a PCE. 513 In either case, the location of the egress PE can easily be found by 514 looking for who originates the locator comprising the SID B:8:D100::. 515 This can be found in the IGP's LSDB for a single domain case, and in 516 the BGP-LS LSDB for a multi-domain case. 518 Let us assume that the TE metric encodes the per-link propagation 519 latency. Let us assume that all the links have a TE metric of 10, 520 except link 27 which has TE metric 100. 522 The low-latency path from 1 to 8 is thus 1234678. 524 This path is encoded in a SID list as: first a hop through B:3:C4:: 525 and then a hop to 8. 527 As a consequence the SR-VPN entry 20/8 installed in the Node1's 528 Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy . 531 When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks 532 up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8. As a 533 consequence, 1 pushes an outer header with SA=A:1::, DA=B:3:C4::, 534 NH=SRH followed by SRH (B:8:D100::, B:3:C4::; SL=1; NH=4). 1 then 535 forwards the resulting packet on the interface to 2. 537 2 forwards to 3 along the path to B:3::/32. 539 When 3 receives the packet, 3 matches the DA in its "My SID Table" 540 and finds the bound function End.X to neighbor 4. 3 notes the PSP 541 capability of the SID B:3:C4::. 3 sets the DA to the next SID 542 B:8:D100::. As 3 is the penultimate segment hop, it performs PSP and 543 pops the SRH. 3 forwards the resulting packet to 4. 545 4, 6 and 7 forwards along the path to B:8::/32. 547 When 8 receives the packet, 8 matches the DA in its "My SID Table" 548 and finds the bound function End.DT(100). As a result, 8 decaps the 549 outer header, looks up the inner IPv4 DA (20.20.20.20) in tenant-100 550 IPv4 table, and forward the (inner) IPv4 packet towards CE-B. 552 2.8.2. SR policy at a midpoint 554 Let us analyze a policy applied at a midpoint on a packet without 555 SRH. 557 Packet P1 is (A:1::, B:8:D100::). 559 Let us consider P1 when it is received by node 2 and let us assume 560 that that node 2 is configured to steer B:8::/32 in a T.Insert 561 behavior associated with SR policy . 563 In such a case, node 2 would send the following modified packet P1 on 564 the link to 3: 566 (A:1::, B:3:C4::)(B:8:D100::, B:3:C4::; SL=1). 568 The rest of the processing is similar to the previous section. 570 Let us analyze a policy applied at a midpoint on a packet with an 571 SRH. 573 Packet P2 is (A:1::, B:7:1::)(B:8:D100::, B:7:1::; SL=1). 575 Let us consider P2 when it is received by node 2 and let us assume 576 that node 2 is configured to steer B:7::/32 in a T.Insert behavior 577 associated with SR policy . 579 In such a case, node 2 would send the following modified packet P2 on 580 the link to 4: 582 (A:1::, B:3:C4::)(B:7:1::, B:5:1::, B:3:C4::; SL=2)(B:8:D100::, 583 B:7:1::; SL=1) 585 Node 3 would send the following packet to 4: (A:1::, 586 B:5:1::)(B:6:1::, B:5:1::, B:3:C4::; SL=1)(B:8:D100::, B:7:1::; SL=1) 588 Node 4 would send the following packet to 5: (A:1::, 589 B:5:1::)(B:6:1::, B:5:1::, B:3:C4::; SL=1)(B:8:D100::, B:7:1::; SL=1) 591 Node 5 would send the following packet to 6: (A:1::, 592 B:7:1::)(B:8:D100::, B:7:1::; SL=1) 594 Node 6 would send the following packet to 7: (A:1::, 595 B:7:1::)(B:8:D100::, B:7:1::; SL=1) 597 Node 7 would send the following packet to 8: (A:1::, B:8:D100::) 599 2.9. End-to-End policy with intermediate BSID 601 Let us now describe a case where the ingress VPN edge node steers the 602 packet destined to 20.20.20.20 towards the egress edge node connected 603 to the tenant100 site with 20/8, but via an intermediate SR Policy 604 represented by a single routable Binding SID. Let us illustrate this 605 case with an intermediate policy which both encodes underlay 606 optimization for low-latency and the service programming via two SR- 607 aware container-based apps. 609 Let us assume that the End.B6.Insert SID B:2:B1:: is configured at 610 node 2 and is associated with midpoint SR policy . 613 B:3:C4:: realizes the low-latency path from the ingress PE to the 614 egress PE. This is the underlay optimization part of the 615 intermediate policy. 617 B:9:A1:: and B:6:A2:: represent two SR-aware NFV applications 618 residing in containers respectively connected to node 9 and 6. 620 Let us assume the following ingress VPN policy for 20/8 in tenant 100 621 IPv4 table of node 1: T.Encaps with SRv6 Policy . 624 This ingress policy will steer the 20/8 tenant-100 traffic towards 625 the correct egress PE and via the required intermediate policy that 626 realizes the SLA and NFV requirements of this tenant customer. 628 Node 1 sends the following packet to 2: (A:1::, B:2:B1::) 629 (B:8:D100::, B:2:B1::; SL=1) 631 Node 2 sends the following packet to 4: (A:1::, B:3:C4::) (B:6:A2::, 632 B:9:A1::, B:3:C4::; SL=2)(B:8:D100::, B:2:B1::; SL=1) 634 Node 4 sends the following packet to 5: (A:1::, B:9:A1::) (B:6:A2::, 635 B:9:A1::, B:3:C4::; SL=1)(B:8:D100::, B:2:B1::; SL=1) 637 Node 5 sends the following packet to 9: (A:1::, B:9:A1::) (B:6:A2::, 638 B:9:A1::, B:3:C4::; SL=1)(B:8:D100::, B:2:B1::; SL=1) 640 Node 9 sends the following packet to 6: (A:1::, B:6:A2::) 641 (B:8:D100::, B:2:B1::; SL=1) 643 Node 6 sends the following packet to 7: (A:1::, B:8:D100::) 645 Node 7 sends the following packet to 8: (A:1::, B:8:D100::) which 646 decaps and forwards to CE-B. 648 The benefits of using an intermediate Binding SID are well-known and 649 key to the Segment Routing architecture: the ingress edge node needs 650 to push fewer SIDs, the ingress edge node does not need to change its 651 SR policy upon change of the core topology or re-homing of the 652 container-based apps on different servers. Conversely, the core and 653 service organizations do not need to share details on how they 654 realize underlay SLA's or where they home their NFV apps. 656 2.10. TI-LFA 658 Let us assume two packets P1 and P2 received by node 2 exactly when 659 the failure of link 27 is detected. 661 P1: (A:1::, B:7:1::) 663 P2: (A:1::, B:7:1::)(B:8:D100::, B:7:1::; SL=1) 665 Node 2's pre-computed TI-LFA backup path for the destination B:7::/32 666 is . It is installed as a T.Insert transit behavior. 668 Node 2 protects the two packets P1 and P2 according to the pre- 669 computed TI-LFA backup path and send the following modified packets 670 on the link to 4: 672 P1: (A:1::, B:3:C4::)(B:7:1::, B:3:C4::; SL=1) 674 P2: (A:1::, B:3:C4::)(B:7:1::, B:3:C4::; SL=1) (B:8:D100::, 675 B:7:1::; SL=1) 677 Node 4 then sends the following modified packets to 5: 679 P1: (A:1::, B:7:1::) 681 P2: (A:1::, B:7:1::)(B:8:D100::, B:7:1::; SL=1) 683 Then these packets follow the rest of their post-convergence path 684 towards node 7 and then go to node 8 for the VPN decaps. 686 2.11. SR TE for Service programming 688 We have illustrated the service programming through SR-aware apps in 689 a previous section. 691 We illustrate the use of End.AS function 692 [I-D.xuclad-spring-sr-service-programming] to service chain an IP 693 flow bound to the internet through two SR-unaware applications hosted 694 in containers. 696 Let us assume that servers 20 and 70 are respectively connected to 697 nodes 2 and 7. They are respectively configured with SID spaces 698 B:20::/32 and B:70::/32. Their connected routers advertise the 699 related prefixes in the IGP. Two SR-unaware container-based 700 applications App2 and App7 are respectively hosted on server 20 and 701 70. Server 20 (70) is configured explicitly with an End.AS SID 702 A:20:2:: for App2 (A:70:7:: for App7). 704 Let us assume a broadband customer with a home gateway CE-A connected 705 to edge router 1. Router 1 is configured with an SR policy which 706 encapsulates all the traffic received from CE-A into a T.Encaps 707 policy where B:8:D0:: is an End.DT4 708 SID instantiated at node 8. 710 P1 is a packet sent by the broadband customer to 1: (X, Y) where X 711 and Y are two IPv4 addresses. 713 1 sends the following packet to 2: (A1::, B:20:2::)(B:8:D0::, 714 B:70:7::, B:20:2::; SL=2; NH=4)(X, Y). 716 2 forwards the packet to server 20. 718 20 receives the packet (A1::, B:20:2::)(B:8:D0::, B:70:7::, B:20:2::; 719 SL=2; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App2. 720 App2 works on the packet and forwards it back to 20. 20 pushes the 721 outer IPv6 header with SRH (A1::, B:70:7::)(B:8:D0::, B:70:7::, 722 B:20:2::; SL=1; NH=4) and sends the (whole) IPv6 packet with the 723 encapsulated IPv4 packet back to 2. 725 2 and 7 forward to server 70. 727 70 receives the packet (A1::, B:70:7::)(B:8:D0::, B:70:7::, B:20:2::; 728 SL=1; NH=4)(X, Y) and forwards the inner IPv4 packet (X,Y) to App7. 729 App7 works on the packet and forwards it back to 70. 70 pushes the 730 outer IPv6 header with SRH (A1::, B:8:D0::)(B:8:D0::, B:70:7::, 731 B:20:2::; SL=0; NH=4) and sends the (whole) IPv6 packet with the 732 encapsulated IPv4 packet back to 7. 734 7 forwards to 8. 736 8 receives (A1::, B:8:D0::)(B:8:D0::, B:70:7::, B:20:2::; SL=0; 737 NH=4)(X, Y) and performs the End.DT4 function and sends the IP packet 738 (X, Y) towards its internet destination. 740 3. Benefits 742 3.1. Seamless deployment 744 The VPN use-case can be realized with SRv6 capability deployed solely 745 at the ingress and egress PE's. 747 All the nodes in between these PE's act as transit routers as per 748 [RFC8200]. No software/hardware upgrade is required on all these 749 nodes. They just need to support IPv6 per [RFC8200]. 751 The SRTE/underlay-SLA use-case can be realized with SRv6 capability 752 deployed at few strategic nodes. 754 It is well-known from the experience deploying SR-MPLS that 755 underlay SLA optimization requires few SIDs placed at strategic 756 locations. This was illustrated in our example with the low- 757 latency optimization which required the operator to enable one 758 single core node with SRv6 (node 4) where one single and End.X SID 759 towards node 5 was instantiated. This single SID is sufficient to 760 force the end-to-end traffic via the low-latency path. 762 The TI-LFA benefits are collected incrementally as SRv6 capabilities 763 are deployed. 765 It is well-know that TI-LFA is an incremental node-by-node 766 deployment. When a node N is enabled for TI-LFA, it computes TI- 767 LFA backup paths for each primary path to each IGP destination. 768 In more than 50% of the case, the post-convergence path is loop- 769 free and does not depend on the presence of any remote SRv6 SID. 770 In the vast majority of cases, a single segment is enough to 771 encode the post-convergence path in a loop-free manner. If the 772 required segment is available (that node has been upgraded) then 773 the related back-up path is installed in FIB, else the pre- 774 existing situation (no backup) continues. Hence, as the SRv6 775 deployment progresses, the coverage incrementally increases. 776 Eventually, when the core network is SRv6 capable, the TI-LFA 777 coverage is complete. 779 The service programming use-case can be realized with SRv6 capability 780 deployed at few strategic nodes. 782 The service-programming deployment is again incremental and does 783 not require any pre-deployment of SRv6 in the network. When an 784 NFV app A1 needs to be enabled for inclusion in an SRv6 service 785 chain, all what is required is to install that app in a container 786 or VM on an SRv6-capable server (Linux 4.10 or FD.io 17.04 787 release). The app can either be SR-aware or not, leveraging the 788 proxy functions. 790 By leveraging the various End functions it can also be used to 791 support any current VNF/CNF implementations and their forwarding 792 methods (e.g. Layer 2). 794 The ability to leverage SR TE policies and BSIDs also permits 795 building scalable, hierarchical service-chains. 797 3.2. Integration 799 The SRv6 network programming concept allows integrating all the 800 application and service requirements: multi-domain underlay SLA 801 optimization with scale, overlay VPN/Tenant, sub-50msec automated 802 FRR, security and service programming. 804 3.3. Security 806 The combination of well-known techniques (SEC-1, SEC-2) and carefully 807 chosen architectural rules (SEC-3) ensure a secure deployment of SRv6 808 inside a multi-domain network managed by a single organization. 810 Inter-domain security will be described in a companion document. 812 4. Acknowledgements 814 The authors would like to acknowledge Stefano Previdi, Dave Barach, 815 Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul 816 Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu 817 Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang, 818 Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif 819 Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk, 820 Jisu Bhattacharya and Saleem Hafeez. 822 5. Contributors 824 Daniel Bernier 825 Bell Canada 826 Canada 828 Email: daniel.bernier@bell.ca 830 Daniel Voyer 831 Bell Canada 832 Canada 834 Email: daniel.voyer@bell.ca 835 Bart Peirens 836 Proximus 837 Belgium 839 Email: bart.peirens@proximus.com 841 Hani Elmalky 842 Ericsson 843 United States of America 845 Email: hani.elmalky@gmail.com 847 Prem Jonnalagadda 848 Barefoot Networks 849 United States of America 851 Email: prem@barefootnetworks.com 853 Milad Sharif 854 Barefoot Networks 855 United States of America 857 Email: msharif@barefootnetworks.com 859 Stefano Salsano 860 Universita di Roma "Tor Vergata" 861 Italy 863 Email: stefano.salsano@uniroma2.it 865 Ahmed AbdelSalam 866 Gran Sasso Science Institute 867 Italy 869 Email: ahmed.abdelsalam@gssi.it 871 Gaurav Naik 872 Drexel University 873 United States of America 875 Email: gn@drexel.edu 877 Arthi Ayyangar 878 Arista 879 United States of America 881 Email: arthi@arista.com 882 Satish Mynam 883 Innovium Inc. 884 United States of America 886 Email: smynam@innovium.com 888 Wim Henderickx 889 Nokia 890 Belgium 892 Email: wim.henderickx@nokia.com 894 Shaowen Ma 895 Juniper 896 Singapore 898 Email: mashao@juniper.net 900 Ahmed Bashandy 901 Individual 902 United States of America 904 Email: abashandy.ietf@gmail.com 906 Francois Clad 907 Cisco Systems, Inc. 908 France 910 Email: fclad@cisco.com 912 Kamran Raza 913 Cisco Systems, Inc. 914 Canada 916 Email: skraza@cisco.com 918 Darren Dukes 919 Cisco Systems, Inc. 920 Canada 922 Email: ddukes@cisco.com 924 Patrice Brissete 925 Cisco Systems, Inc. 926 Canada 928 Email: pbrisset@cisco.com 929 Zafar Ali 930 Cisco Systems, Inc. 931 United States of America 933 Email: zali@cisco.com 935 6. Informative References 937 [I-D.dawra-idr-srv6-vpn] 938 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 939 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 940 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 941 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 942 Signaling for SRv6 based Services.", draft-dawra-idr- 943 srv6-vpn-05 (work in progress), October 2018. 945 [I-D.ietf-6man-segment-routing-header] 946 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 947 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 948 Routing Header (SRH)", draft-ietf-6man-segment-routing- 949 header-22 (work in progress), August 2019. 951 [I-D.ietf-spring-segment-routing-policy] 952 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 953 bogdanov@google.com, b., and P. Mattes, "Segment Routing 954 Policy Architecture", draft-ietf-spring-segment-routing- 955 policy-03 (work in progress), May 2019. 957 [I-D.ietf-spring-srv6-network-programming] 958 Filsfils, C., Camarillo, P., Leddy, J., 959 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 960 Network Programming", draft-ietf-spring-srv6-network- 961 programming-01 (work in progress), July 2019. 963 [I-D.xuclad-spring-sr-service-programming] 964 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 965 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 966 Henderickx, W., and S. Salsano, "Service Programming with 967 Segment Routing", draft-xuclad-spring-sr-service- 968 programming-02 (work in progress), April 2019. 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, 972 DOI 10.17487/RFC2119, March 1997, 973 . 975 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 976 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 977 May 2017, . 979 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 980 (IPv6) Specification", STD 86, RFC 8200, 981 DOI 10.17487/RFC8200, July 2017, 982 . 984 Authors' Addresses 986 Clarence Filsfils 987 Cisco Systems, Inc. 988 Belgium 990 Email: cf@cisco.com 992 Pablo Camarillo Garvia (editor) 993 Cisco Systems, Inc. 994 Spain 996 Email: pcamaril@cisco.com 998 Zhenbin Li 999 Huawei Technologies 1000 China 1002 Email: lizhenbin@huawei.com 1004 Satoru Matsushima 1005 SoftBank 1006 1-9-1,Higashi-Shimbashi,Minato-Ku 1007 Tokyo 105-7322 1008 Japan 1010 Email: satoru.matsushima@g.softbank.co.jp 1012 Bruno Decraene 1013 Orange 1014 France 1016 Email: bruno.decraene@orange.com 1017 Dirk Steinberg 1018 Lapishills Consulting Limited 1019 Cyprus 1021 Email: dirk@lapishills.com 1023 David Lebrun 1024 Google 1025 Belgium 1027 Email: david.lebrun@uclouvain.be 1029 Robert Raszuk 1030 Bloomberg LP 1031 United States of America 1033 Email: robert@raszuk.net 1035 John Leddy 1036 Individual Contributor 1037 United States of America 1039 Email: john@leddy.net