idnits 2.17.1 draft-agrawal-spring-srv6-mpls-interworking-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 : ---------------------------------------------------------------------------- ** 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 (October 22, 2018) is 2012 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. -------------------------------------------------------------------------------- 2 SPRING S. Agrawal 3 Internet-Draft Z. Ali 4 Intended status: Standards Track C. Filsfils 5 Expires: April 25, 2019 Cisco Systems 6 D. Voyer 7 Bell Canada 8 G. Dawra 9 LinkedIn 10 Z. Li 11 Huawei Technologies 12 October 22, 2018 14 SRv6 and MPLS interworking 15 draft-agrawal-spring-srv6-mpls-interworking-00 17 Abstract 19 This document describes SRv6 and MPLS/SR-MPLS interworking and co- 20 existence procedures. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Interworking Procedures . . . . . . . . . . . . . . . . . . . 4 65 3. Building blocks for domain stitching . . . . . . . . . . 5 66 3.1. Stitching heterogenous domains using a Controller . . . . 5 67 3.1.1. Illustration . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Stitching heterogenous domains usin BGP inter domain 69 routing . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. 6toM and Mto6 considerations . . . . . . . . . . . . . . 7 71 4. FRR handling . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5. Migration and co-existence . . . . . . . . . . . . . . . . . 8 73 6. BGP based services interworking and migration . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Many of the deployments require SRv6 insertion in the brownfield 83 networks. The incremental deployment of SRv6 into existing networks 84 require SRv6 to interwork and co-exist with SR-MPLS/ MPLS. 86 There are various SRv6 and SR-MPLS/ MPLS interworking scenarios 87 possible. They can be classified into the following four categories. 89 o SRv6 over SR MPLS/ MPLS (6oM) 91 o SR MPLS/ MPLS over SRv6 (Mo6) 92 o SRv6 to SR-MPLS/ MPLS (6toM) 94 o SR-MPLS/ MPLS to SRv6 (Mto6) 96 These scenarios cover various cascading of SRv6/ MPLS network, e.g., 97 SR-MPLS/MPLS <-> SRv6 <-> SR-MPLS/MPLS <-> SRv6 <-> SR-MPLS/MPLS, 98 etc. The draft addresses all these possible interworking scenarios. 100 In addition, the draft also addresses migration and coexistence of 101 the SRv6 and SR-MPLS/ MPLS. Co-existence means a network that 102 supports both SRv6 and MPLS in a given domain. This may be a 103 transient state when brownfield SR-MPLS/ MPLS network upgrades to 104 SRv6 (migration) or permanent state when some devices are not capable 105 of SRv6 but supports native IPv6 and SR-MPLS/ MPLS. 107 1.1. Terminology 109 SID: A Segment Identifier which represents a specific segment in 110 segment routing domain. The SID type used in this document is IPv6 111 address (also referenced as SRv6 Segment or SRv6 SID). 113 Node k has a classic IPv6 loopback address Ak::/128. 115 A SID at node k with locator block B and function F is represented by 116 B:k:F:: 118 A SID list is represented as where S1 is the first SID 119 to visit, S2 is the second SID to visit and S3 is the last SID to 120 visit along the SR path. 122 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 124 -IPv6 header with source address SA, destination addresses DA and SRH 125 as next-header 127 -SRH with SID list with SegmentsLeft = SL 129 Note the difference between the <> and () symbols: 130 represents a SID list where S1 is the first SID and S3 is the last 131 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 132 encoded in the SRH format where the rightmost SID in the SRH is the 133 first SID and the leftmost SID in the SRH is the last SID. When 134 referring to an SR policy in a high-level use-case, it is simpler to 135 use the notation. When referring to an illustration of 136 the detailed packet behavior, the (S3, S2, S1; SL) notation is more 137 convenient. 139 domain: Without loss of the generality, domain is assumed to be 140 instantiated by a single IGP instance or a network within IGP if 141 there is clear separation of data plane. 143 2. Interworking Procedures 145 This documents refers to interworking as a stitching of SRv6 domain 146 and SR-MPLS/ MPLS domain. Special stitching procedures are performed 147 on routers which acts as border between such domains. Border routers 148 need to support both SRv6 and SR-MPLS/ MPLS. Interworking is 149 applicable when SRv6 domains are deployed and need to interop with 150 existing SR-MPLS/ MPLS backbones or access networks. 152 This draft proposes two ways to stitch heterogeneous domains: a 153 controller based solution and a BGP signaling based approach. The 154 PCE based solution is applicable to both best effort as well as 155 deployments where tight SLA guarantees are required (e.g., ODN like 156 deployments scenarios). The BGP signaling covers the best effort 157 case. Specifically, the draft proposes the following two ways to 158 stitch heterogeneous domains end to end: 160 o Stitching using a Controller: An SDN based approach like Multi- 161 Domain On Demand Nexthop (ODN) case for SLA contract end to end 162 across heterogeneous domains. Path Computation Element (PCE) can 163 act like the controller. These procedures can be used when 164 overlay prefixes have SLA requirement signaled through a color 165 community. These procedures can also be used for the best effort 166 services. 168 o Stitching using BGP Inter-Domain Routing. BGP 3107 procedures 169 advertising PE locators/Loopbacks for best effort end to end 170 connectivity. These procedures are applicable in deployments 171 where an SDN controller is not deployed. These procedures can be 172 used when overlay prefixes don't have SLA requirement 174 In summary the draft covers the following SRv6/ MPLS interworking 175 scenarios. 176 - Carrying SRv6 over SR-MPLS (controller stitches domains). 177 - Carrying SRv6 over SR-MPLS (BGP stitches domains). 178 - Carrying SR-MPLS over SRv6 (controller stitches domains). 179 - Carrying SR-MPLS over SRv6 (BGP stitches domains). 180 - SRv6 to SR-MPLS translation (controller stitches domains). 181 - SRv6 to SR-MPLS translation (BGP stitches domains). 182 - SR-MPLS to SRv6 translation (controller stitches domains). 183 - SR-MPLS to SRv6 translation (BGP stitches domains). 184 - Cascaded domains (controller stitches domains). 185 - Cascaded domains (BGP stitches domains). 187 While the number of interworking scenarios is large, the few building 188 blocks outlines in this draft address all of them. For the same 189 reasons, without the loss of generality, the building blocks are 190 illustrated using the SRv6 over SR-MPLS example of Figure 1 but the 191 procedure equally applies to the other deployment scenarios. 193 2 5 8 194 * * / \ * * 195 * * / \ * * 196 * * / \ * * 197 1 SRv6 4 MPLS 7 SRv6 10 198 * IGP1 * \ IGP2 / * IGP3 * 199 * * \ / * * 200 * * \ / * * 201 3 6 9 203 Example Network Scenario(6oM) 205 Figure 1 207 3. Building blocks for domain stitching 209 3.1. Stitching heterogenous domains using a Controller 211 This procedure provides a best-effort path as well as a path that 212 satisfies the Service Level Agreement (SLA), across multiple domains. 213 A PCE may act as an SDN controller. In that case, based on the SLA, 214 the PCE computes and programs end to end path. The PCE is also aware 215 of interworking requirement at border nodes, as each domain feeds 216 topological information to the controller through BGP LS feeds. 217 Intermediate domain of different data plane type is represented by 218 Binding SID (BSID) of head end type in SID list. The intermediate 219 domain BSID is programmed at domain entry border node with SID list 220 through domain and exit node SID as last segment. In summary, an 221 intermediate heterogenous domain is replaced by a BSID of the data 222 plane nature of headend. The procedure work for all of deployment 223 model mentioned above. 225 3.1.1. Illustration 227 The procedure is illustrated using the example of Figure 1. 229 When a service prefix (e.g., vpn or evpn) is received on head end 230 with SLA (color extended community), the head- end (Node 1) node 231 requests a PCE for a path to egress node that can satisfy the SLA. 232 This is because Node 1 does not know how to compute the traffic 233 engineered path through the multi-domain network to node 10. Node 1 234 requests SR PCE to compute a path to node 10 providing optimization 235 objective, constraints(eg: low latency). The PCE computes low 236 latency path via node 2, 5 and 8. The PCE identifies the end-to-end 237 path is not consistent data plane and kicks in interworking 238 procedures at the border node(4). It programs a policy at 4 that 239 "Stitches" domains using SRv6 End.BM BSID.The PCE installs SRv6 240 End.BM BSID at node 4 with segments are node 5, 7. SR PCE responds 241 back to node 1 with SRv6 segments via node 2, End.BM at node 4, node 242 8 and node 10. 244 The data plan operations for the above-mentioned interworking example 245 are described in the following: 247 o Node 1 performs SRv6 function T.Encaps.Red with VPN service SID 248 and SRv6 Policy (BLUE,10): 249 Packet leaving node 1 IPv6 ((A:1::, B:2:E::) (B:10::DT4, B:8:E::, 250 B:4:BM-BLUE-7:: ; SL=3)) 252 o Node 2 performs End function 253 Packet leaving node 2 IPv6 ((A:1::, B:4:BM-BLUE-7::) (B:10::DT4, 254 B:8:E::, B:4:BM-BLUE-7:: ; SL=2)) 256 o Node 4 performs End.BM function 257 Packet leaving node 4 MPLS (16005,16007,2)((A:1::, B:8:E::) 258 (B:10::DT4, B:8:E::, B:4:BM-BLUE-7-:: ; SL=1)) 260 o Node 7 performs a native ipv6 lookup on due PHP behavior for 16007 261 Packet leaving node 7 IPv6 ((A:1::, B:8:E::) (B:10::DT4, B:8:E::, 262 B:4:BM-BLUE-7:: ; SL=1)) 264 o Node 8 performs End(PSP) function 265 Packet leaving node 8 IPv6 ((A:1::, B:10::DT4)) 267 o Node 10 performs End.DT function and lookups IP in vrf and send 268 traffic to CE. 270 3.2. Stitching heterogenous domains usin BGP inter domain routing 272 For providing services across domains, edge node locators need to be 273 reachable. 275 -Locators are advertised by edge nodes in the BGP ipv6 unicast 276 address family (AFI=2,Safi=1) to border nodes. These locators are 277 also advertised in its local IGP domain. 279 -On border nodes these prefixes are like any IPv6 global prefixes. 280 These will be advertised in BGP IPv6 LU[AFI=2/SAFI=4] session using 281 3107 procedures in label core. It could be summary prefix for all 282 locators in that domain. 284 -Remote domain border router advertising locator over SRv6 domain 285 need to attach SRv6 SID in prefix SID attribute. SRv6 SID in this 286 case will be End function of advertising border node. 288 -Ingress node learns remote locators over BGP ipv6 address 289 family[AFI=2, SAFI=1]. These locators have prefix SID attribute 290 containing SRv6 SID. This SRv6 SID is End function of advertising 291 border node and helps to tunnel traffic to border node in remote 292 domain. 294 -If locators are leaked into remote IGP and no tunneling of traffic 295 will be needed in remote domain. Hence attaching SRv6 SID on remote 296 border nodes can be avoided. 298 These procedures work for any of deployment model mentioned above. 299 Below are some important aspects for Mo6, 6toM, Mto6 300 -Loopback address are advertised in BGP label unicast session to 301 border node when advertised from MPLS domain. These are also 302 advertised in local IGP. 303 -Border nodes advertises prefix over SRv6 domain in BGP IPv4/IPv6 304 session. It attaches prefix SID attribute with SRv6 SID. This SRv6 305 SID maps to label received in prefix update. -Remote border node 306 allocates local label to advertise prefix in MPLS domain to ingress 307 node. This local label maps to received SRv6 SID in prefix sid 308 attribute of prefix. 310 3.3. 6toM and Mto6 considerations 312 For 6toM and Mto6 BGP inter domain or ODN multi domain stitching will 313 work if SRv6 edge nodes are capable of handling vpn/service label. 314 In 6toM scenario, ingress node should be able to encap vpn label and 315 then perform T.Encap function with SRv6 SID associated with prefix 316 nexthop. In Mto6 case, traffic will be received with SRv6 SID and 317 vpn label below it on egress PE. So egress SRv6 capable node should 318 be able to process vpn labels after decapsulating SRv6 SID and when 319 next header is 137 in IPv6 header. 321 Service information encoded by SRv6 PE will be in SRv6 Service SID 322 and MPLS PE will be vpn label/service label or just IP payload for 323 internet. If SRv6 PE do not support vpn label, then we need some 324 special handling to translate SRv6 service SID to vpn label and vice 325 versa at border nodes. This will be detailed in future versions 327 4. FRR handling 329 Failure within domain are taken care by existing FRR(TILFA, rLFA, LFA 330 etc) mechanisms. 332 Failure of border nodes are to be addressed in a future version of 333 the document. 335 5. Migration and co-existence 337 These procedures would be detailed in a future revision 339 6. BGP based services interworking and migration 341 SRv6-based VPN (SRv6-VPN)/EVPN service information is encoded in SRv6 342 SIDs specifically END.DT*/END.DX*/END.DT2. MPLS-based VPN service 343 information is encoded in labels. This requires special 344 consideration during Migration and Interworking. Will be discussed 345 more detail in future versions 347 7. IANA Considerations 349 None 351 8. Security Considerations 353 9. Acknowledgements 355 10. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 Authors' Addresses 364 Swadesh Agrawal 365 Cisco Systems 367 Email: swaagraw@cisco.com 369 Zafar ALI 370 Cisco Systems 372 Email: zali@cisco.com 373 Clarence Filsfils 374 Cisco Systems 376 Email: cfilsfil@cisco.com 378 Daniel Voyer 379 Bell Canada 380 Canada 382 Email: daniel.voyer@bell.ca 384 Gaurav dawra 385 LinkedIn 386 USA 388 Email: gdawra.ietf@gmail.com 390 Zhenbin Li 391 Huawei Technologies 392 China 394 Email: lizhenbin@huawei.com