idnits 2.17.1 draft-ls-bess-srv6-mpls-coexisting-vpn-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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '... same. If not, the advertisement MUST...' RFC 2119 keyword, line 219: '...encoding is needed, the egress PE MUST...' RFC 2119 keyword, line 247: '...that BGP speaker MUST NOT send on that...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2021) is 1203 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) == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 339, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-05 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-14) exists of draft-agrawal-spring-srv6-mpls-interworking-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BGP Working Group Y. Liu 3 Internet-Draft B. Song 4 Intended status: Standards Track ZTE Corporation 5 Expires: July 11, 2021 January 7, 2021 7 BGP Extensions for Services in SRv6 and MPLS Coexisting Network 8 draft-ls-bess-srv6-mpls-coexisting-vpn-01 10 Abstract 12 This document proposes a method to achieve VPN/EVPN in a network 13 where SRv6 and SR-MPLS/MPLS coexist, including extensions of BGP. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 11, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. the Co-existence Scenario . . . . . . . . . . . . . . . . . . 2 51 3. BGP extensions . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Extended SRv6 Service TLVs . . . . . . . . . . . . . . . 4 53 3.2. Dual-Stack VPN Capability . . . . . . . . . . . . . . . . 6 54 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 60 8.2. Informative References . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 The incremental deployment of SRv6 into existing networks require 66 SRv6 to interwork and co-exist with SR-MPLS/MPLS. 68 Currently [I-D.agrawal-spring-srv6-mpls-interworking] and 69 [I-D.pzm-bess-spring-interdomain-vpn] discuss about the SRv6 and MPLS 70 interworking method. 72 In the progress of upgrading some network, some of the legacy devices 73 that support only MPLS/SR-MPLS will coexist with the new devices 74 capable SRv6 for a long time. The co-existence scenario also need to 75 be further addressed. 77 This document proposes a method to achieve VPN/EVPN in a network 78 where SRv6 and SR-MPLS/MPLS coexist, including extensions of BGP. 80 2. the Co-existence Scenario 82 +----R1----R2----+ 83 | | +----+CE21 84 | | | 85 CE1+----+PE1 PE2+ 86 | | | 87 | | +----+CE22 88 +----R3----R4----+ 90 Figure 1: Reference Topology 1 91 +----R1----R2----+ 92 | | 93 CE1+----+PE1 | 94 PE2+----+CE2 95 CE3+----+PE3 | 96 | | 97 +----R3----R4----+ 99 Figure 2: Reference Topology 2 101 As shown in Figure 1 and Figure 2, R3 and R4 are capable of SRv6, R1 102 and R2 are legacy devices which only support SR-MPLS/MPLS. 104 In Figure 1, PE2 is connected to different services with different 105 SLA requirements. Different SLA requirements may correspond to 106 different forwarding paths, these paths may be SRv6 capable, or may 107 pass through the devices that only support SR-MPLS/MPLS. 109 In Figure 2, to reach for the same service, the underlay path from 110 PE1 to PE2 support SRv6 forwarding, while the path from PE3 to PE2 111 passes through the devices that only support SR-MPLS/MPLS. 113 Existing solutions include the following: 115 1)The egress PE allocates the MPLS label and SRv6 SID for the same 116 service and advertise them separately through different routes, which 117 have different priorities, the ingress PE then selects the route of 118 higher priority. 120 For example, in Figure 1, an end-to-end VPN IPv4 BGP peer 121 relationship and a IPv6 BGP peer relationship are established between 122 PE1 and PE2. 124 After PE2 receives a VPN route from its VPN instance, PE2 advertises 125 a copy of this route to the VPN IPv4 BGP peer and applies for an MPLS 126 label. PE2 then advertises another copy to the VPN IPv6 BGP peer, 127 with the route carrying a SRv6 SID. PE1 receives two VPN routes with 128 the same prefix, one with an IPv4 next hop and the other with an IPv6 129 next hop. The route with the IPv4 next hop recurses to the MPLS 130 tunnel, and the route with the IPv6 next hop recurses to the SRv6 131 tunnel. If routes with IPv4 next hops are of higher priority, the 132 MPLS tunnel is chosen, otherwise the traffic reaches the PE2 through 133 the SRv6 tunnel. 135 The disadvantage of this method is that only one route can take 136 effect at the same time and the method is not flexible enough. In 137 figure 1, if the best path from CE1 to CE21 is a MPLS tunnel while 138 the expected path from CE1 to CE22 is an SRv6 tunnel, this method 139 cannot meet such requirements easily. 141 2)If the underlay path attribute corresponding to each service is 142 predictable, the egress PE allocates either MPLS labels or SRv6 SIDs 143 for each service based on the underlay path attribute. That is, the 144 engress PE advertises only one kind of BGP route for a particular 145 service prefix, either with MPLS labels or the SRv6 SIDs. 147 Once the path attribute of underlay is changed, for example, the 148 device that only supports MPLS forwarding is upgraded to support 149 SRv6, the configuration on PE should also be changed accordingly. 151 Based on the above scenarios, this document proposes a method: 153 The egress PE allocates MPLS label(s) and SRv6 SID(s) for the same 154 service and signals them within the same BGP overlay service route. 156 After receiving the BGP advertisement, the ingress PE should add the 157 prefix with the MPLS label and SRv6 SID information to the RIB. 159 When encapsulating packets, the ingress PE selects whether to use 160 MPLS label or SRv6 SID according to the attribute of the underlay 161 path. 163 If there is a route reflector in the network, it must support the 164 extended BGP message too. 166 Currently, the MPLS-based VPN/EVPN service information is encoded in 167 the MPLS Label field of the corresponding NLRI, and the SRv6-based 168 VPN/EVPN service information is encoded as SRv6 service SIDs such as 169 END.DT*/END.DX*/END.DT2 with BGP Prefix-SID attribute [RFC8669] 170 extended to carry SRv6 service SIDs information 171 [I-D.ietf-bess-srv6-services] 173 But how does the egress PE indicate in the BGP advertisement that a 174 service supports both MPLS and SRv6 identification is not clearly 175 described. 177 3. BGP extensions 179 3.1. Extended SRv6 Service TLVs 181 For the convenience of understanding and reading, the two methods of 182 notifying SRv6 SID in [I-D.ietf-bess-srv6-services] are described 183 briefly below. 185 In the first method, SRv6 Service SIDs are encoded as a whole in the 186 SRv6 Services TLVs. In this case, the MPLS Label field(s) of the 187 corresponding NLRI is set to Implicit NULL. 189 The second method is called Transposition Scheme of encoding, where 190 the SRv6 SID Structure Sub-Sub-TLV describes the size of each part of 191 the SRv6 SID and also indicates the offset of variable part along 192 with its length in SRv6 SID value. The function and/or the argument 193 part of the SRv6 SID is encoded in the MPLS Label field of the NLRI 194 and the SID value in the SRv6 Services TLV carries only the locator 195 part with the SRv6 SID Structure Sub-Sub-TLV. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | TLV Type | TLV Length |M| RESERVED | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 // SRv6 Service Sub-TLVs // 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 3: Extended SRv6 Service TLVs 207 This document introduces a M-flag in the RESERVED field of SRv6 208 Services TLVs as shown in figure 3, when set, it indicates that this 209 service supports both MPLS label and SRv6 service SID identification. 211 If the advertisement message carries multiple SRv6 Service TLVs at 212 the same time, for example, in the EVPN scenario, the M-flag of the 213 these TLVs must be set to the same. If not, the advertisement MUST 214 be discarded. 216 The MPLS-based VPN/EVPN service information is always encoded in the 217 MPLS Label field of the NLRI. 219 If the Transposition Scheme of encoding is needed, the egress PE MUST 220 allocate SRv6 service SIDs with the function and/or the argument part 221 same as the MPLS VPN label. 223 Otherwise, SRv6 SIDs and MPLS labels can be of independent values, 224 and SRv6 Service SIDs are encoded as a whole in the SRv6 Services 225 TLVs. 227 The allocation of SRv6 SIDs and MPLS labels for VPN/EVPN on egress 228 PEs is an implementation thing, and it is outside the scope of this 229 document. 231 More processing details will be further discussed. 233 3.2. Dual-Stack VPN Capability 235 [RFC5492] defines the "Capabilities Optional Parameter". A BGP 236 speaker can include a Capabilities Optional Parameter in a BGP OPEN 237 message. The Capabilities Optional Parameter is a triple that 238 includes a one-octet Capability Code, a one-octet Capability length, 239 and a variable-length Capability Value. 241 This document defines a Capability Code for dual-stack VPN 242 capability. 244 If a BGP speaker has not sent the dual-stack VPN capability in its 245 BGP OPEN message on a particular BGP session, or if it has not 246 received the dual-stack VPN capability in the BGP OPEN message from 247 its peer on that BGP session, that BGP speaker MUST NOT send on that 248 session any UPDATE message that includes the extended SRv6 service 249 TLVs. 251 4. Illustration 253 The reference topology is show in Figure 2. PEs support both SRv6 254 and SR-MPLS capabilities. 256 Take IPv4 VPN as an example, PE2 assigns an MPLS label vpn2 and an 257 SRv6 service SID(eg, END.DX4) sid2 for CE2, and the function part of 258 the SID is vpn2. 260 Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277] 261 with the Label Value set to vpn2. 263 If Transposition Scheme of encoding is used, the locator part of the 264 SRv6 Service SID is encoded in the SRv6 L3 Service TLV with the 265 M-flag set to 1. 267 PE1 and PE3 learn through M-flag that CE2 has both MPLS and SRv6 268 identification, and obtain the corresponding MPLS label and SRv6 SID 269 carried in the BGP update messages. 271 When a service prefix is received on PE1, by looking at the local 272 forwarding table, PE1 finds that the service is related to an MPLS 273 label and an SRv6 SID, and the corresponding path is a segment list 274 consisting of SR-MPLS SIDs , such as