idnits 2.17.1 draft-hu-bess-srv6-vpn-bypass-sid-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.dawra-idr-srv6-vpn' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC8214' is defined on line 373, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-dawra-idr-srv6-vpn-04 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Hu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track July 02, 2018 5 Expires: January 3, 2019 7 Enhance IPv6-Segment-Routing-based EVPN VPWS All Active Usage 8 draft-hu-bess-srv6-vpn-bypass-sid-00 10 Abstract 12 This document describes the extensions to enhance SRv6 EVPN VPWS all- 13 active Reliability. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. SRv6 VPN Bypass SID Attribute . . . . . . . . . . . . . . . . 3 57 2.1. End.DX2L: Endpoint with decapsulation and Layer-2 cross- 58 connect to local access . . . . . . . . . . . . . . . . . 4 59 2.2. End.DT2UL: Endpoint with decapsulation and unicast Local 60 MAC L2 table lookup . . . . . . . . . . . . . . . . . . . 5 61 3. Control Plane Processing . . . . . . . . . . . . . . . . . . 6 62 4. Data Packets Processing . . . . . . . . . . . . . . . . . . . 7 63 5. EVPN Multipoint to Multipoint (MP2MP) services . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 In SRv6 EVPN VPWS all-active scenario, a router or switch (CE1) is 74 dual-homed to enterprise site (PE1 and PE2). SRv6 EVPN VPWS service 75 is run between enterprise sites (PE1, PE2, and CPE). When one PE 76 fails, services can be rapidly switched to the other PE, minimizing 77 the impact on services. 79 As shown in Figure 1, deploy fast reroute(FRR) service on PE1 and 80 PE2. When the AC(attachment circuit) link on PE1 fails, PE1 receives 81 downlink traffic and can bypass it to the PE2 device for forwarding. 82 PE2 is also the same. If the AC side links on PE1 and PE2 fail 83 together, a brief traffic loop between PE1 and PE2 occurs. The 84 traffic loop will waste the forwarding resources of the equipment and 85 cause performance pressure. The length of the traffic loop depends 86 on the convergence of the control plane. That is, PE1 withdraws the 87 per-EVI Ethernet A-D route advertised to PE2. The FRR backup path on 88 PE2 is destroyed. PE2 does not send traffic to PE1. In order to 89 solve the above problem, this document defines a sub type of the SRv6 90 VPN SID attribute [draft-dawra-idr-srv6-vpn], to be included with 91 per-EVI Ethernet A-D routes. 93 +-----+ 94 | CE2 | 95 +-----+ 96 | 97 +-----+ 98 |EVPL1| Local/Remote Ethernet Tag ID->100/200 99 -------------------| PE3 | 100 | +-----+ 101 | / \ 102 | / \ 103 SRv6 EVPN VPWS / \ 104 | / \ 105 | / \ 106 | +-----+SRv6 Bypass +-----+ 107 --------- | PE1 | Tunnel | PE2 | 108 L/R Ethernet Tag ID->200/100 |EVPL1|-------------|EVPL1| L/R Ethernet Tag ID->200/100 109 +-----+ +-----+ 110 \ / 111 \ / 112 ESI1 ESI1 113 \ Trunk / 114 +\-----/+ 115 | \ / | 116 +---+---+ 117 | 118 +-----+ 119 | CE1 | 120 +-----+ 122 Figure 1: Basic networking of the SRv6 EVPN VPWS all-active scenario 124 2. SRv6 VPN Bypass SID Attribute 126 The SRv6 VPN Bypass SID is a sub type of the SRv6 VPN SID. The SRv6 127 VPN SID has been defined in draft-dawra-idr-srv6-vpn as follows: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Type | Length | RESERVED | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | SRv6 SID information(Variable) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 SRv6 SID information is encoded as follows: 139 +---------------------------------------+ 140 | SID Type (1 Octet) | 141 +---------------------------------------+ 142 | SRv6 SID (16 octet) | 143 +---------------------------------------+ 144 Figure 2: SRv6 VPN Bypass SID Attribute 146 Because the SID Type values 1 and 2 have already been defined, the 147 SID Type of the SRv6 VPN Bypass SID is a value to be defined that is 148 different from 1, 2. Current Type of SID defined as: 150 o Type-3(Type value is TBD) - corresponds to the equivalent 151 functionality provided by a MPLS Label1 for EVPN Route-Types as 152 defined in [RFC7432]. Some functions which MAY be encoded are 153 End.DX2L, End.DT2UL etc. 155 We define hereafter a set of new functions that can be associated 156 with a SID. As in draft-filsfils-spring-srv6-network-programming, a 157 function is locally defined on the node where it is executed and may 158 range from simply moving forward in the segment list to any complex 159 user-defined behavior. 161 End.DX2L Endpoint with decapsulation and Layer-2 cross-connect to 162 local access 164 End.DT2UL Endpoint with decapsulation and unicast Local MAC L2 table 165 lookup 167 2.1. End.DX2L: Endpoint with decapsulation and Layer-2 cross-connect to 168 local access 170 The "Endpoint with decapsulation and Layer-2 cross-connect to local 171 access OIF" function (End.DX2L for short) is a variant of the 172 endpoint function. 174 When N receives a packet destined to S and S is a local End.DX2L SID, 175 N does: 177 1. IF NH=SRH and SL > 0 179 2. drop the packet ;; Ref1 181 3. ELSE IF ENH = 59 ;; Ref2 183 4. pop the (outer) IPv6 header and its extension headers 185 5. forward the resulting frame via local access OIF associated to the 186 SID 188 6. ELSE 190 7. drop the packet 192 Ref1: An End.DX2L SID must always be the last SID, or it can be the 193 Destination Address of an IPv6 packet with no SRH header. 195 Ref2: We conveniently reuse the next-header value 59 allocated to 196 IPv6 No Next Header [RFC8200]. When the SID corresponds to function 197 End.DX2L and the Next-Header value is 59, we know that an Ethernet 198 frame is in the payload without any further header. 200 An End.DX2L function could be customized to expect a specific VLAN 201 format and rewrite the egress VLAN header before forwarding on the 202 outgoing interface. 204 One of the applications of the End.DX2L function is the L2VPN use- 205 case. 207 2.2. End.DT2UL: Endpoint with decapsulation and unicast Local MAC L2 208 table lookup 210 The " Endpoint with decapsulation and unicast Local MAC L2 table 211 lookup " function (End.DT2UL for short) is a variant of the endpoint 212 function. 214 When N receives a packet destined to S and S is a local End.DT2UL 215 SID, N does: 217 1. IF NH=SRH and SL > 0 219 2. drop the packet ;; Ref1 221 3. ELSE IF ENH = 59 ;; Ref2 223 4. pop the (outer) IPv6 header and its extension headers 224 5. learn the exposed inner MAC SA in L2 table T ;; Ref3 226 6. lookup the exposed inner MAC DA in L2 table T(Local) 228 7. forward via the matched T entry else to all L2OIF in T(Local) 230 8. ELSE 232 9. drop the packet 234 Ref1: An End.DT2UL SID must always be the last SID, or it can be the 235 Destination Address of an IPv6 packet with no SRH header. 237 End.DT2UL and the Next-Header value is 59, we know that an Ethernet 238 frame is in the payload without any further header. 240 Ref3: In EVPN, the learning of the exposed inner MAC SA is done via 241 control plane. 243 The End.DT2UL is used for EVPN Bridging unicast Local use cases. 245 3. Control Plane Processing 247 As shown in Figure 1: 249 1. PE1 advertises per-EVI Ethernet A-D routes to PE2 and PE3. The 250 route carries the SRv6 VPN SID (SID Type=2, End.DX2) sid1 and SRv6 251 VPN Bypass SID sid11 allocated by the EVPL1 service on PE1. 253 2. The PE2 device receives the per-EVI Ethernet A-D route advertised 254 by PE1 and finds that it is the same as the Local/Remote Ethernet Tag 255 ID and ESI1 of its own EVPL1. PE2 considers it to be a dual-homing 256 relationship with PE1. PE2 uses the SRv6 VPN Bypass SID to establish 257 an SRv6 bypass path to PE1. The tunnel is marked as sid11. The SRv6 258 VPN Bypass SID takes effect when its EVPL Local/Remote Ethernet Tag 259 ID and ESI are the same as the per-EVI Ethernet A-D route received. 261 3. The EVPL1 Local/Remote Ethernet Tag ID of the PE3 device matches 262 PE1. PE3 uses the SRv6 VPN SID to establish an EVPN VPWS service to 263 PE1. The service is marked as sid1. PE3's EVPL1 Local/Remote 264 Ethernet Tag ID and ESI are different from the per-EVI Ethernet A-D 265 routes received. PE3 should ignore this attribute. 267 4. In the same way, PE2 advertises per-EVI Ethernet A-D routes to 268 PE1 and PE3. The routes carry the SRv6 VPN SID sid2 and SRv6 VPN 269 Bypass SID sid22 allocated by EVPL1 services on PE2. 271 5. Finally, the primary path from PE1 to CE1 is the local AC port 272 and the bypass path is the SRv6 tunnel labeled by sid22. The primary 273 path from PE2 to CE1 is the local AC port and the bypass path is the 274 SRv6 tunnel labeled by sid11. Paths from PE3 to PE1 and PE2 are 275 marked as sid1 and sid2. 277 4. Data Packets Processing 279 This section will describe the processes of the downlink Layer 2 280 packet forwarding cases. 282 As shown in Figure 1: 284 1. After receiving a Layer 2 packet sent by the CE2, PE3 285 encapsulates the packet with the EVPL1 sid1 as the destination IPv6 286 of the SRH header, and forwards the packet to PE1. 288 2. After receiving a Layer 2 packet sent by the PE3, PE1 parses the 289 EVPL1 sid1 of the SRH header and forwards it according to the 290 function End.DX2 of sid1. When the primary path from PE1 to CE1 291 fails, PE1 encapsulates the packet with the EVPL1 bypass sid22 as the 292 destination IPv6 of the SRH header, and forwards the packet to PE2. 294 3. After receiving a Layer 2 packet sent by the PE1, PE2 parses the 295 EVPL1 bypass sid22 of the SRH header and forwards it according to the 296 function End.DX2L of sid22. When the primary path from PE2 to CE1 297 fails, PE2 discards the packet and successfully breaks the loop. 299 4. As above, if PE2 receives a Layer 2 packet from PE3, EVPL1 bypass 300 sid11 can also break the loop. 302 5. EVPN Multipoint to Multipoint (MP2MP) services 304 In SRv6 EVPN Multipoint to Multipoint (MP2MP) all-active scenario, 305 function End.DT2UL of SRv6 VPN Bypass SID Attribute also has a 306 similar effect. When the AC side links on PE1 and PE2 fail together, 307 downlink Layer 2 unicast packet will not traffic loop. 309 6. IANA Considerations 311 TBD. 313 7. Security Considerations 315 TBD. 317 8. Acknowledgements 319 The authors of this document would like to thank xxx for their 320 comments and review of this document. 322 9. Contributors 324 The following individuals gave significant contributions to this 325 document: 327 Bingshe Liu 329 Huawei Technologies 331 liubingshe@huawei.com 333 Haibo Wang 335 Huawei Technologies 337 rainsword.wang@huawei.com 339 10. References 341 [I-D.dawra-idr-srv6-vpn] 342 Dawra, G., Filsfils, C., Dukes, D., Brissette, P., 343 Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., 344 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 345 Decraene, B., Matsushima, S., and S. Zhuang, "BGP 346 Signaling of IPv6-Segment-Routing-based VPN Networks", 347 draft-dawra-idr-srv6-vpn-04 (work in progress), June 2018. 349 [I-D.filsfils-spring-srv6-network-programming] 350 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 351 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 352 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 353 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 354 M. Sharif, "SRv6 Network Programming", draft-filsfils- 355 spring-srv6-network-programming-04 (work in progress), 356 March 2018. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 364 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 365 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 366 2015, . 368 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 369 (IPv6) Specification", STD 86, RFC 8200, 370 DOI 10.17487/RFC8200, July 2017, 371 . 373 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 374 Rabadan, "Virtual Private Wire Service Support in Ethernet 375 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 376 . 378 Author's Address 380 Chongyang Hu 381 Huawei Technologies 382 Huawei Bld., No.156 Beiqing Rd. 383 Beijing 100095 384 China 386 Email: huchongyang@huawei.com