BGP Working Group Yao. Liu Internet-Draft Bing. Song Intended status: Standards Track ZTE Corporation Expires: March 10, 2021 September 6, 2020 BGP Extensions for Services in SRv6 and MPLS Coexisting Network draft-ls-bess-srv6-mpls-coexisting-vpn-00 Abstract This document proposes a method to achieve VPN/EVPN in a network which supports both SRv6 and MPLS in a given domain, including extensions of BGP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 10, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liu & Song Expires March 10, 2021 [Page 1] Internet-Draft IGP for Service Segment September 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. the Co-existence Scenario . . . . . . . . . . . . . . . . . . 2 3. BGP extensions . . . . . . . . . . . . . . . . . . . . . . . 4 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The incremental deployment of SRv6 into existing networks require SRv6 to interwork and co-exist with SR-MPLS/MPLS. Currently [I-D.agrawal-spring-srv6-mpls-interworking] and [I-D.pzm-bess-spring-interdomain-vpn] discuss about the SRv6 and MPLS interworking method. In the progress of upgrading some network, some of the legacy devices that support only MPLS/SR-MPLS will coexist with the new devices capable SRv6 for a long time. The co-existence scenario also need to be further addressed. This document proposes a method to achieve VPN/EVPN in a network which supports both SRv6 and MPLS in a given domain, including extensions of BGP. 2. the Co-existence Scenario +----R1----R2----+ | | +----+CE21 | | | CE1+----+PE1 PE2+ | | | | | +----+CE22 +----R3----R4----+ Figure 1: Reference Topology 1 Liu & Song Expires March 10, 2021 [Page 2] Internet-Draft IGP for Service Segment September 2020 +----R1----R2----+ | | CE1+----+PE1 | PE2+----+CE2 CE3+----+PE3 | | | +----R3----R4----+ Figure 2: Reference Topology 2 As shown in Figure 1 and Figure 2, R3 and R4 are capable of SRv6, R1 and R2 are legacy devices which only support SR-MPLS/MPLS. In Figure 1, PE2 is connected to different services with different SLA requirements.Different SLA requirements may correspond to different forwarding paths, these paths may be SRv6 capable, or may pass through the devices that only support SR-MPLS/MPLS. In Figure 2, to reach for the same service, the underlay path from PE1 to PE2 support SRv6 forwarding, while the path from PE3 to PE2 passes through the devices that only support SR-MPLS/MPLS. Based on the above scenarios, this document proposes a method: The egress PE allocates MPLS label(s) and SRv6 SID(s) for the same service and signals them with the BGP overlay service route. After receiving the BGP advertisement, the ingress PE should add the prefix with the MPLS label and SRv6 SID information to the RIB. When encapsulating packets, the ingress PE selects whether to use MPLS label or SRv6 SID according to the attribute of the underlay path. If there is a route reflector in the network, it must support the extended BGP message too. Currently, the MPLS-based VPN/EVPN service information is encoded in the MPLS Label field of the corresponding NLRI, and the SRv6-based VPN/EVPN service information is encoded as SRv6 service SIDs such as END.DT*/END.DX*/END.DT2 with BGP Prefix-SID attribute [RFC8669] extended to carry SRv6 service SIDs information [I-D.ietf-bess-srv6-services] But how does the egress PE indicate in the BGP advertisement that a service supports both MPLS and SRv6 identification is not clearly described. Liu & Song Expires March 10, 2021 [Page 3] Internet-Draft IGP for Service Segment September 2020 3. BGP extensions For the convenience of understanding and reading, the two methods of notifying SRv6 SID in [I-D.ietf-bess-srv6-services] are described briefly below. In the first method, SRv6 Service SIDs are encoded as a whole in the SRv6 Services TLVs. In this case, the MPLS Label field(s) of the corresponding NLRI is set to Implicit NULL. The second method is called Transposition Scheme of encoding, where the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and to also indicate offset of variable part along with its length in SRv6 SID value. The function and/or the argument part of the SRv6 SID is encoded in the MPLS Label field of the NLRI and the SID value in the SRv6 Services TLV carries only the locator part with the SRv6 SID Structure Sub-Sub-TLV. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length |M| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SRv6 Service Sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Extended SRv6 Service TLVs This document introduces a M-flag in the RESERVED field of SRv6 Services TLVs as shown in figure 3, when set, it indicates that this service supports both MPLS label and SRv6 service SID identification. If the advertisement message carries multiple SRv6 Service TLVs at the same time, for example, in the EVPN scenario, the M-flag of the these TLVs must be set to the same. If not, the advertisement MUST be discarded. The MPLS-based VPN/EVPN service information is always encoded in the MPLS Label field of the NLRI. If the Transposition Scheme of encoding is needed, the egress PE MUST allocate SRv6 service SIDs with the function and/or the argument part same as the MPLS VPN label. Liu & Song Expires March 10, 2021 [Page 4] Internet-Draft IGP for Service Segment September 2020 Otherwise, SRv6 SIDs and MPLS labels can be of independent values, and SRv6 Service SIDs are encoded as a whole in the SRv6 Services TLVs. The allocation of SRv6 SIDs and MPLS labels for VPN/EVPN on egress PEs is an implementation thing, and it is outside the scope of this document. More processing details will be further discussed. 4. Illustration The reference topology is show in Figure 2. PEs support both SRv6 and SR-MPLS capabilities. Take IPv4 VPN as an example, PE2 assigns an MPLS label vpn2 and an SRv6 service SID(eg, END.DX4) sid2 for CE2, and the function part of the SID is vpn2. Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277] with the Label Value set to vpn2. If Transposition Scheme of encoding is used, the locator part of the SRv6 Service SID is encoded in the SRv6 L3 Service TLV with the M-flag set to 1. PE1 and PE3 learn through M-flag that CE2 has both MPLS and SRv6 identification, and obtain the corresponding MPLS label and SRv6 SID carried in the BGP update messages. When a service prefix is received on PE1, by looking at the local forwarding table, PE1 finds that the service is related to an MPLS label and an SRv6 SID, and the corresponding path is a segment list consisting of SR-MPLS SIDs , such as