idnits 2.17.1 draft-lp-bess-vpn-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 11 instances of too long lines in the document, the longest one being 6 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 (2 January 2022) is 838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Y. Liu 3 Internet-Draft S. Peng 4 Intended status: Informational ZTE 5 Expires: 6 July 2022 2 January 2022 7 A Label/SID Allocation Method for VPN Interworking 8 draft-lp-bess-vpn-interworking-00 10 Abstract 12 This document analyzes the SRv6-MPLS service interworking solution 13 and offers an MPLS label or SRv6 SID allocation method for label/SID 14 saving and better scalability purpose. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 6 July 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 2 51 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 53 3. Service Interworking between SRv6 and MPLS . . . . . . . . . 3 54 3.1. Label Allocation Method . . . . . . . . . . . . . . . . . 4 55 3.1.1. Detailed Example for Service Interworking . . . . . . 5 56 3.2. Control of the Allocation Method . . . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 61 6.2. Informative References . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 Inter-AS option B is one of the ways in which the PE routers from 67 different ASes can exchange the MPLS VPN routes with each other as 68 described in [RFC4364]. This method uses BGP to signal MPLS VPN 69 labels between the AS boundary routers. 71 [I-D.ietf-bess-srv6-services] defines procedures and messages to 72 carry SRv6 Service SIDs and form VPNs in SRv6. SRv6 Service SID 73 refers to an SRv6 SID associated with one of the service-specific 74 SRv6 Endpoint behaviors on the advertising PE router, and its usage 75 is similar to MPLS VPN label to some extent. 77 In the progress of network upgrading, some of the legacy devices(e.g, 78 PEs) that only support MPLS VPN will coexist with the new devices 79 capable of SRv6 VPN for a long time. For service connectivity, 80 services over the SRv6 PE need to interwork with that over MPLS PE. 82 A common method for service interworking is similar to inter-AS 83 option B. ASBRs needs to translate between MPLS VPN labels and SRv6 84 service SIDs, i.e, when an ASBR receives an SRv6 VPN route from the 85 egress PE, it needs to allocate an MPLS VPN label for it and 86 advertise the corresponding MPLS VPN route to the ASBR in the MPLS 87 domain. 89 This document analyzes the SRv6-MPLS service interworking solution 90 and offers an MPLS label or SRv6 SID allocation method for label/SID 91 saving and better scalability purpose. 93 2. Conventions used in this document 94 2.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2.2. Terminology and Acronyms 102 PE: Provider Edge 104 CE: ;Customer Edge 106 AS: Autonomous System 108 ASBR: Autonomous System Border Router 110 RD: Route Distinguisher 112 RR: Route Reflector 114 3. Service Interworking between SRv6 and MPLS 116 +--------------------------PE3 117 | 118 PE1-----------------------ASBR1-----------ASBR2------------------------PE2 120 | MPLS | | SRv6 | 121 |<------------------------->|<------------->|<-------------------------->| 122 | IBGP | EBGP | IBGP | 124 Figure 1: Reference Multi-Domain Network Topology 126 As shown in Figure 1, PE1 is a legacy device that only supports MPLS- 127 based services. PE2 and PE3 support SRv6-based services. ASBR2, as 128 a node in the domain with new features, support both MPLS and SRv6. 130 On PE2, SRv6 service SID SID-21 is allocated, per VPN instance, for 131 VPN prefix 1 and prefix 2 in VRF1, SRv6 service SID SID-22 is 132 allocated, per VPN instance, for VPN prefix 2 in VRF2. On PE3, SRv6 133 service SID SID-31 is allocated, per VPN instance, for VPN prefix 2 134 in VRF1. Route distinguisher RD1 is configured for VRF1 and RD2 for 135 VRF2. 137 The SRv6 VPN route carrying the corresponding service SID and RD with 138 it propagates to ASBR2. 140 On ASBR2, the received SRv6 service SID needs to be replaced by a new 141 MPLS label, then the new MPLS VPN label propagates to ASBR1. 143 On ASBR1, the received MPLS VPN label needs to be replaced by a new 144 MPLS label, then the new MPLS VPN label propagates to PE1. 146 3.1. Label Allocation Method 148 On ASBR2, MPLS VPN label can be allocated per . 150 However, there may be scalability issues. The 128-bit encoding space 151 in SRv6 is much more larger compared with the 20-bit label space in 152 MPLS, which means SRv6-based VPN allows massive number of sites(with 153 different prefixes) to access. If the MPLS label is allocated per 154 prefix in this case, the number of MPLS labels may be not enough. A 155 label-saving allocation solution is needed for better scalability. 157 In order to save label resources, the MPLS label can be allocated per 158 sets. 160 If this method is used, on ASBR2, MPLS lalel L21 is allocated for 161 SID-21 on PE2, L22 for SID-22 on PE2 and L31 for SID-31 on PE3. 163 The disadvantage of this method is that once the next-hop is changed, 164 the old label needs to be released and new label needs to be 165 allocated, the corresponding MPLS VPN label should be withdrawed and 166 re-advertised with the new one. For example, in the FRR case, the 167 primary next-hop may be down and the converged path contains the 168 original backup next-hop, that may cause the oscillation of label 169 allocation, especially when there're large numbers of SRv6 service 170 SID on the PE. 172 This document proposes that the MPLS label can be allocated per RD on 173 ASBR. And it is required that the RD of different VRF instance MUST 174 be different. 176 The ILM table is built based on the mapping relationship between the 177 allocated label and RD, and it leads to the query of the RD context 178 tables. The RD context tables are built based on the received VPN 179 routes. 181 For one packet, the ASBR would query two tables to get the outgoing 182 action, this behavior is similar to that in inter-AS option A in 183 RFC4364, but unlike option A, there's no VRF instance configuration 184 on the ASBR. 186 The per-RD allocation method applies for MPLS VPN inter-AS option B 187 as well, i.e., similar operation can be done on ASBR1. The 188 difference is that the encapsulating IPv6 action in the RD Entry 189 Table should be replace by pushing the MPLS VPN label. 191 In addition, per-RD allocation can also apply for SRv6 VPN SID on 192 ASBR2 when it received VPN routes from ASBR1, and the endpoint 193 behaviour can still be END.DT4/6. 195 3.1.1. Detailed Example for Service Interworking 197 This section provides a detailed example for service interworking 198 between SRv6 and MPLS based on the per-RD label allocation method. 199 The reference topology is shown in Figure 1. 201 Control Plane: 203 1)Egress PE2 advertises a BGP SRv6 VPN route: RD:RD1, prefix:prefix2, 204 next hop: lo-PE2, service SID: SID22. 206 Egress PE3 advertises a BGP SRv6 VPN route: RD:RD1, prefix:prefix2, 207 next hop: lo-PE3, service SID: SID31. 209 PE3 acts as the backup of PE2 for prefix2, and the route from PE3 has 210 lower priority. 212 These routes propagates to ASBR2. 214 2)The reachability of lo-PE2 and lo-PE3 is advertised by IGP within 215 the domain. 217 3)ASBR2 learns with next hop lo-PE2 and SID22. ASBR2 218 learns with next hop lo-PE3 and SID31. 220 ASBR2 allocates MPLS label label-21 based on RD1. 222 The ILM forwarding table and RD context Table is shown in Figure 2. 224 ASBR2 uses the destination address of the packet to match the 225 corresponding entry and determine the outgoing action. 227 The outgoing action shown in RD1 context table only provides an 228 example when the SRv6 service is provided with best-effort 229 connectivity, the ASBR2 encapsulates the payload in an outer IPv6 230 header where the destination address is the SRv6 Service SID provided 231 by the egress PE. If SRv6 service is provided in conjunction with an 232 underlay SLA from the egress PE, ASBR2 may encapsulate the payload 233 packet in an outer IPv6 header with the segment list of SR policy 234 associated with the related SLA along with the SRv6 Service SID 235 associated with the route using the Segment Routing Header (SRH) 236 [RFC8754]. The detailed encapsulate method is specified in 237 [I-D.ietf-bess-srv6-services] and this document doesn't change that 238 procedure. 240 ILM table 241 +=============+=============================================+ 242 | In label | Action | 243 +=============+=============================================+ 244 | label-21 | pop, lookup table.RD1 | 245 +-------------+---------------------------------------------+ 247 RD1 context table 248 +=============+=============================================+ 249 | Prefix | Outgoing Action | 250 +=============+=============================================+ 251 | prefix2 | Primary: | 252 | | encap IPv6 with DA=SID22, fwd to PE2 | 253 | | Backup: | 254 | | encap IPv6 with DA=SID31, fwd to PE3 | 255 +-------------+---------------------------------------------+ 257 Figure 2: Forwarding State on ASBR2 259 4) ASBR2 advertises an MPLS VPN label to ASBR1: RD:RDa, 260 prefix:prefix2, next hop: ASBR2, VPN label: label-21. 262 5) ASBR1 learns with next hop ASBR2 and label-21. 264 ASBR1 changes the next-hop to itself and allocates a new label label- 265 11, then ASBR1 advertises a BGP MPLS VPN route: RD:RDb, 266 prefix:prefix1, next hop: ASBR1, VPN label: label-11. 268 The route propagates via RR to PE1. 270 6) PE1 learns with next hop ASBR1 and label-11. 272 7) An LSP from PE1 to ASBR1 is build via LDP, the corresponding label 273 of the tunnel is label-T. 275 Data Plane: 277 1) PE1 performs MPLS label stack encapsulation with VPN label and 278 tunnel label. 280 The packet leaving PE1: . 282 2) ABSR1 pop the tunnel label and swap the VPN label. 284 The packet leaving ASBR1 towards ASBR2: . 286 3) Based on the received label-21, ASBR2 looks up table.RD1. 288 Because the destination address of the payload match prefix2, ASBR2 289 encapsulates the payload in an outer IPv6 header where the 290 destination address is SID21 and forward the packet to PE2. 292 If PE2 fails, ASBR2 would choose the backup outgoing action and 293 forwards the packet to PE3 with SID31. 295 3.2. Control of the Allocation Method 297 The per-RD label allocation method can be enabled by configuration on 298 ASBRs. 300 If many configurations are required in a large-scale network, 301 controlling the allocation by protocol extensions may be taken into 302 consideration. 304 A new BGP Extended Communities Attribute[RFC4360] is defined for this 305 purpose. 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | 0x03 | TBD1 | Allocation Type | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Reserved | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 3: Label Allocation Extended Community 317 The value of the high-order octet of the extended type field is 0x03, 318 which indicates it is transitive. 320 The value of the low-order octet of the extended type field for this 321 community is TBD1, which indicates it is the label allocation 322 extended community. 324 Allocation Type field is used to indicate the label/SID allocation 325 method, the value 0x01 indicates that the label/SID should be 326 allocated based on the RD value in the NLRI. Other values are 327 reserved for future definition. 329 The egress PE advertises VPN route with the label allocation extended 330 community to indicate that the ASBR should allocate the incomming 331 MPLS label or SID for the received route based on the allocation 332 method identified in the extended community. 334 An implementation SHOULD ensure that the label/SID allocation on ASBR 335 doesn't conflict with each other. 337 4. IANA Considerations 339 IANA is requested to assign one new values from the "BGP Opaque 340 Extended Community" type Registry. It is from the transitive range. 341 The new value is called "Label Allocation Extended Community" 342 (0x03TBD1). This document is the reference for the assignments. 344 5. Security Considerations 346 This document does not change the underlying security issues inherent 347 in [RFC4364] and [I-D.ietf-bess-srv6-services]. 349 6. References 351 6.1. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 359 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 360 February 2006, . 362 6.2. Informative References 364 [I-D.ietf-bess-srv6-services] 365 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 366 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 367 Overlay Services", Work in Progress, Internet-Draft, 368 draft-ietf-bess-srv6-services-08, 10 November 2021, 369 . 372 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 373 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 374 2006, . 376 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 377 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 378 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 379 . 381 Authors' Addresses 383 Yao Liu 384 ZTE 385 Nanjing 386 China 388 Email: liu.yao71@zte.com.cn 390 Shaofu Peng 391 ZTE 392 Nanjing 393 China 395 Email: peng.shaofu@zte.com.cn