idnits 2.17.1 draft-agrawal-spring-srv6-mpls-interworking-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 4 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 (July 8, 2019) is 1751 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPRING S. Agrawal 2 Internet-Draft Z. Ali 3 Intended status: Standards Track C. Filsfils 4 Expires: January 9, 2020 Cisco Systems 5 D. Voyer 6 Bell Canada 7 G. Dawra 8 LinkedIn 9 Z. Li 10 Huawei Technologies 11 July 8, 2019 13 SRv6 and MPLS interworking 14 draft-agrawal-spring-srv6-mpls-interworking-01 16 Abstract 18 This document describes SRv6 and MPLS/SR-MPLS interworking and co- 19 existence procedures. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Interworking Procedures . . . . . . . . . . . . . . . . . . . 4 64 3. Building blocks for domain stitching . . . . . . . . . . 5 65 3.1. Stitching heterogenous domains using a Controller . . . . 5 66 3.1.1. Illustration . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Stitching heterogenous domains usin BGP inter domain 68 routing . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. 6toM and Mto6 considerations . . . . . . . . . . . . . . 7 70 4. FRR handling . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Migration and co-existence . . . . . . . . . . . . . . . . . 8 72 6. BGP based services interworking and migration . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 Many of the deployments require SRv6 insertion in the brownfield 82 networks. The incremental deployment of SRv6 into existing networks 83 require SRv6 to interwork and co-exist with SR-MPLS/ MPLS. 85 There are various SRv6 and SR-MPLS/ MPLS interworking scenarios 86 possible. They can be classified into the following four categories. 88 o SRv6 over SR MPLS/ MPLS (6oM) 90 o SR MPLS/ MPLS over SRv6 (Mo6) 91 o SRv6 to SR-MPLS/ MPLS (6toM) 93 o SR-MPLS/ MPLS to SRv6 (Mto6) 95 These scenarios cover various cascading of SRv6/ MPLS network, e.g., 96 SR-MPLS/MPLS <-> SRv6 <-> SR-MPLS/MPLS <-> SRv6 <-> SR-MPLS/MPLS, 97 etc. The draft addresses all these possible interworking scenarios. 99 In addition, the draft also addresses migration and coexistence of 100 the SRv6 and SR-MPLS/ MPLS. Co-existence means a network that 101 supports both SRv6 and MPLS in a given domain. This may be a 102 transient state when brownfield SR-MPLS/ MPLS network upgrades to 103 SRv6 (migration) or permanent state when some devices are not capable 104 of SRv6 but supports native IPv6 and SR-MPLS/ MPLS. 106 1.1. Terminology 108 SID: A Segment Identifier which represents a specific segment in 109 segment routing domain. The SID type used in this document is IPv6 110 address (also referenced as SRv6 Segment or SRv6 SID). 112 Node k has a classic IPv6 loopback address Ak::/128. 114 A SID at node k with locator block B and function F is represented by 115 B:k:F:: 117 A SID list is represented as where S1 is the first SID 118 to visit, S2 is the second SID to visit and S3 is the last SID to 119 visit along the SR path. 121 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 123 -IPv6 header with source address SA, destination addresses DA and SRH 124 as next-header 126 -SRH with SID list with SegmentsLeft = SL 128 Note the difference between the <> and () symbols: 129 represents a SID list where S1 is the first SID and S3 is the last 130 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 131 encoded in the SRH format where the rightmost SID in the SRH is the 132 first SID and the leftmost SID in the SRH is the last SID. When 133 referring to an SR policy in a high-level use-case, it is simpler to 134 use the notation. When referring to an illustration of 135 the detailed packet behavior, the (S3, S2, S1; SL) notation is more 136 convenient. 138 domain: Without loss of the generality, domain is assumed to be 139 instantiated by a single IGP instance or a network within IGP if 140 there is clear separation of data plane. 142 2. Interworking Procedures 144 This documents refers to interworking as a stitching of SRv6 domain 145 and SR-MPLS/ MPLS domain. Special stitching procedures are performed 146 on routers which acts as border between such domains. Border routers 147 need to support both SRv6 and SR-MPLS/ MPLS. Interworking is 148 applicable when SRv6 domains are deployed and need to interop with 149 existing SR-MPLS/ MPLS backbones or access networks. 151 This draft proposes two ways to stitch heterogeneous domains: a 152 controller based solution and a BGP signaling based approach. The 153 PCE based solution is applicable to both best effort as well as 154 deployments where tight SLA guarantees are required (e.g., ODN like 155 deployments scenarios). The BGP signaling covers the best effort 156 case. Specifically, the draft proposes the following two ways to 157 stitch heterogeneous domains end to end: 159 o Stitching using a Controller: An SDN based approach like Multi- 160 Domain On Demand Nexthop (ODN) case for SLA contract end to end 161 across heterogeneous domains. Path Computation Element (PCE) can 162 act like the controller. These procedures can be used when 163 overlay prefixes have SLA requirement signaled through a color 164 community. These procedures can also be used for the best effort 165 services. 167 o Stitching using BGP Inter-Domain Routing. BGP 3107 procedures 168 advertising PE locators/Loopbacks for best effort end to end 169 connectivity. These procedures are applicable in deployments 170 where an SDN controller is not deployed. These procedures can be 171 used when overlay prefixes don't have SLA requirement 173 In summary the draft covers the following SRv6/ MPLS interworking 174 scenarios. 175 - Carrying SRv6 over SR-MPLS (controller stitches domains). 176 - Carrying SRv6 over SR-MPLS (BGP stitches domains). 177 - Carrying SR-MPLS over SRv6 (controller stitches domains). 178 - Carrying SR-MPLS over SRv6 (BGP stitches domains). 179 - SRv6 to SR-MPLS translation (controller stitches domains). 180 - SRv6 to SR-MPLS translation (BGP stitches domains). 181 - SR-MPLS to SRv6 translation (controller stitches domains). 182 - SR-MPLS to SRv6 translation (BGP stitches domains). 183 - Cascaded domains (controller stitches domains). 184 - Cascaded domains (BGP stitches domains). 186 While the number of interworking scenarios is large, the few building 187 blocks outlines in this draft address all of them. For the same 188 reasons, without the loss of generality, the building blocks are 189 illustrated using the SRv6 over SR-MPLS example of Figure 1 but the 190 procedure equally applies to the other deployment scenarios. 192 2 5 8 193 * * / \ * * 194 * * / \ * * 195 * * / \ * * 196 1 SRv6 4 MPLS 7 SRv6 10 197 * IGP1 * \ IGP2 / * IGP3 * 198 * * \ / * * 199 * * \ / * * 200 3 6 9 202 Example Network Scenario(6oM) 204 Figure 1 206 3. Building blocks for domain stitching 208 3.1. Stitching heterogenous domains using a Controller 210 This procedure provides a best-effort path as well as a path that 211 satisfies the Service Level Agreement (SLA), across multiple domains. 212 A PCE may act as an SDN controller. In that case, based on the SLA, 213 the PCE computes and programs end to end path. The PCE is also aware 214 of interworking requirement at border nodes, as each domain feeds 215 topological information to the controller through BGP LS feeds. 216 Intermediate domain of different data plane type is represented by 217 Binding SID (BSID) of head end type in SID list. The intermediate 218 domain BSID is programmed at domain entry border node with SID list 219 through domain and exit node SID as last segment. In summary, an 220 intermediate heterogenous domain is replaced by a BSID of the data 221 plane nature of headend. The procedure work for all of deployment 222 model mentioned above. 224 3.1.1. Illustration 226 The procedure is illustrated using the example of Figure 1. 228 When a service prefix (e.g., vpn or evpn) is received on head end 229 with SLA (color extended community), the head- end (Node 1) node 230 requests a PCE for a path to egress node that can satisfy the SLA. 231 This is because Node 1 does not know how to compute the traffic 232 engineered path through the multi-domain network to node 10. Node 1 233 requests SR PCE to compute a path to node 10 providing optimization 234 objective, constraints(eg: low latency). The PCE computes low 235 latency path via node 2, 5 and 8. The PCE identifies the end-to-end 236 path is not consistent data plane and kicks in interworking 237 procedures at the border node(4). It programs a policy at 4 that 238 "Stitches" domains using SRv6 End.BM BSID.The PCE installs SRv6 239 End.BM BSID at node 4 with segments are node 5, 7. SR PCE responds 240 back to node 1 with SRv6 segments via node 2, End.BM at node 4, node 241 8 and node 10. 243 The data plan operations for the above-mentioned interworking example 244 are described in the following: 246 o Node 1 performs SRv6 function T.Encaps.Red with VPN service SID 247 and SRv6 Policy (BLUE,10): 248 Packet leaving node 1 IPv6 ((A:1::, B:2:E::) (B:10::DT4, B:8:E::, 249 B:4:BM-BLUE-7:: ; SL=3)) 251 o Node 2 performs End function 252 Packet leaving node 2 IPv6 ((A:1::, B:4:BM-BLUE-7::) (B:10::DT4, 253 B:8:E::, B:4:BM-BLUE-7:: ; SL=2)) 255 o Node 4 performs End.BM function 256 Packet leaving node 4 MPLS (16005,16007,2)((A:1::, B:8:E::) 257 (B:10::DT4, B:8:E::, B:4:BM-BLUE-7-:: ; SL=1)) 259 o Node 7 performs a native ipv6 lookup on due PHP behavior for 16007 260 Packet leaving node 7 IPv6 ((A:1::, B:8:E::) (B:10::DT4, B:8:E::, 261 B:4:BM-BLUE-7:: ; SL=1)) 263 o Node 8 performs End(PSP) function 264 Packet leaving node 8 IPv6 ((A:1::, B:10::DT4)) 266 o Node 10 performs End.DT function and lookups IP in vrf and send 267 traffic to CE. 269 3.2. Stitching heterogenous domains usin BGP inter domain routing 271 For providing services across domains, edge node locators need to be 272 reachable. 274 -Locators are advertised by edge nodes in the BGP ipv6 unicast 275 address family (AFI=2,Safi=1) to border nodes. These locators are 276 also advertised in its local IGP domain. 278 -On border nodes these prefixes are like any IPv6 global prefixes. 279 These will be advertised in BGP IPv6 LU[AFI=2/SAFI=4] session using 280 3107 procedures in label core. It could be summary prefix for all 281 locators in that domain. 283 -Remote domain border router advertising locator over SRv6 domain 284 need to attach SRv6 SID in prefix SID attribute. SRv6 SID in this 285 case will be End function of advertising border node. 287 -Ingress node learns remote locators over BGP ipv6 address 288 family[AFI=2, SAFI=1]. These locators have prefix SID attribute 289 containing SRv6 SID. This SRv6 SID is End function of advertising 290 border node and helps to tunnel traffic to border node in remote 291 domain. 293 -If locators are leaked into remote IGP and no tunneling of traffic 294 will be needed in remote domain. Hence attaching SRv6 SID on remote 295 border nodes can be avoided. 297 These procedures work for any of deployment model mentioned above. 298 Below are some important aspects for Mo6, 6toM, Mto6 299 -Loopback address are advertised in BGP label unicast session to 300 border node when advertised from MPLS domain. These are also 301 advertised in local IGP. 302 -Border nodes advertises prefix over SRv6 domain in BGP IPv4/IPv6 303 session. It attaches prefix SID attribute with SRv6 SID. This SRv6 304 SID maps to label received in prefix update. -Remote border node 305 allocates local label to advertise prefix in MPLS domain to ingress 306 node. This local label maps to received SRv6 SID in prefix sid 307 attribute of prefix. 309 3.3. 6toM and Mto6 considerations 311 For 6toM and Mto6 BGP inter domain or ODN multi domain stitching will 312 work if SRv6 edge nodes are capable of handling vpn/service label. 313 In 6toM scenario, ingress node should be able to encap vpn label and 314 then perform T.Encap function with SRv6 SID associated with prefix 315 nexthop. In Mto6 case, traffic will be received with SRv6 SID and 316 vpn label below it on egress PE. So egress SRv6 capable node should 317 be able to process vpn labels after decapsulating SRv6 SID and when 318 next header is 137 in IPv6 header. 320 Service information encoded by SRv6 PE will be in SRv6 Service SID 321 and MPLS PE will be vpn label/service label or just IP payload for 322 internet. If SRv6 PE do not support vpn label, then we need some 323 special handling to translate SRv6 service SID to vpn label and vice 324 versa at border nodes. This will be detailed in future versions 326 4. FRR handling 328 Failure within domain are taken care by existing FRR(TILFA, rLFA, LFA 329 etc) mechanisms. 331 Failure of border nodes are to be addressed in a future version of 332 the document. 334 5. Migration and co-existence 336 These procedures would be detailed in a future revision 338 6. BGP based services interworking and migration 340 SRv6-based VPN (SRv6-VPN)/EVPN service information is encoded in SRv6 341 SIDs specifically END.DT*/END.DX*/END.DT2. MPLS-based VPN service 342 information is encoded in labels. This requires special 343 consideration during Migration and Interworking. Will be discussed 344 more detail in future versions 346 7. IANA Considerations 348 None 350 8. Security Considerations 352 9. Acknowledgements 354 10. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 Authors' Addresses 363 Swadesh Agrawal 364 Cisco Systems 366 Email: swaagraw@cisco.com 368 Zafar ALI 369 Cisco Systems 371 Email: zali@cisco.com 372 Clarence Filsfils 373 Cisco Systems 375 Email: cfilsfil@cisco.com 377 Daniel Voyer 378 Bell Canada 379 Canada 381 Email: daniel.voyer@bell.ca 383 Gaurav dawra 384 LinkedIn 385 USA 387 Email: gdawra.ietf@gmail.com 389 Zhenbin Li 390 Huawei Technologies 391 China 393 Email: lizhenbin@huawei.com