SRv6 and MPLS interworking for VPN service
draft-pzm-bess-spring-interdomain-vpn-02

Abstract

This document describes a method to achieve an inter-domain connection for a VPN (Virtual Private Network) service.

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 February 15, 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.

Table of Contents

• 1. Introduction
• 2. Conventions used in this document
• 2.1. Terminology
• 2.2. Requirements Language
• 3. Theory of operation
• 3.1. SRv6 to SR-MPLS domain signaling
• 3.2. SR-MPLS to SRv6 domain signaling
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

[I-D.agrawal-spring-srv6-mpls-interworking] describes SRv6 and MPLS/SR-MPLS interworking and co-existence procedures. The document leverages the function defined in [I-D.ietf-spring-srv6-network-programming] to give guidance to the forwarding in routers.

[RFC4364] describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. When SRv6 and SR-MPLS are co-existed in the backbone, controller or a control plane, for example, using BGP, should be used to instantiate the VPN service as described in [I-D.agrawal-spring-srv6-mpls-interworking].

In case of option B inter-domain interconnection [RFC4364], only ASBR needs to do the stitching work between two ASes. Thus PEs in SRv6 and SR-MPLS domains do not have to support both SRv6 and SR-MPLS functions. This document discusses the use of BGP for achieving VPN service through option B defined in [RFC4364] across a backbone that includes SRv6 and SR-MPLS domains.

2. Conventions used in this document

2.1. Terminology

ASBR - Autonomous System Boundary Router

PE - Provider's Equipment

AS - Autonomous System

SR - Segment Routing

SRv6 - Segment Routing over IPv6 data plane

SR-MPLS - Segment Routing over MPLS data plane

SID - Segment Identifier

IMET - Inclusive Multicast Ethernet Tag

2.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Theory of operation

3.1. SRv6 to SR-MPLS domain signaling

[I-D.ietf-bess-srv6-services] defines the new TLVs for the BGP Prefix-SID Attribute that can be used to signaling of SRv6 SID for L3 and L2 services. In this document, we use L3 case as the example, for the SRv6 SID without any arguments, the procedures for L2 are the same as in L3 scenario.

We use Inclusive Multicast Ethernet Tag (IMET) routes as the example for the SRv6 SIDs with arguments.

			
             +-------------+         +-------------+
             |    AS1      |         |     AS2     |
             |             |         |             |
   CE1+----+PE1          ASBR1+---+ASBR2          PE2+----+CE2
             |             |         |             |
             |    SRV6     |         |   SR-MPLS   |
             +-------------+         +-------------+
		    Figure 1
            

For example, CE1 and CE2 are connected through a backbone that includes AS1 and AS2. AS1 supports SRv6 only, and AS2 supports SR-MPLS only. ASBR1 supports both SRv6 and SR-MPLS capabilities, but ASBR2 supports SR-MPLS capability only.

For a prefix advertised by CE1 to PE1, PE1 assigns SID with End.DT4 (or End.DT6/DT46) defined in [I-D.ietf-spring-srv6-network-programming] section 4 (e.g., End.DT4 is used while the prefix is IPv4 prefix, End.DT6 is used while the prefix is IPv6 prefix), and advertises it to ASBR1. Because ASBR2 supports SR-MPLS function only, the SRv6 SID advertised by ASBR1 cannot be executed by ASBR2.

ASBR1 uses specific execution function that is different from the function used in a single SRv6 domain or a single SR-MPLS domain. In this situation, ASBR1 assigns an MPLS label for the prefix or IMET routes received from PE1 and advertises it to ASBR2. The MPLS label has local significance that indicates this packet is associated with an SRv6 SID list which leads the packet from ASBR1 to PE1. The advertisement is the same as the format in [RFC4364] and [RFC4659] for L3VPN, and [I-D.heitz-bess-evpn-option-b] for EVPN.

When a data flow packet which has the destination to CE1 is received by ASBR1, ASBR1 recognizes the MPLS label, removes the recognized label and adds an SRH to the packet, then forwards it to PE1. Note that the SRH is needed when the packet continues to enter an outer SRv6 policy from headend ASBR1 to endpoint PE1, otherwise only an IPv6 header without SRH is encapsulated.

When the recognized label is assigned to an IMET route, and the Argument Length of the SRv6 SID Structure Sub-Sub-TLV of the IMET route is not zero, the value of the label immediately after the recognized label is assigned to the argument part of the innermost SRv6 SID of the SRH before ASRB1 forwards it to PE1.

3.2. SR-MPLS to SRv6 domain signaling

In the same example, PE2 advertises a prefix received from CE2 or an IMET route with assigned VPN label to ASBR2 according to [RFC4364], [RFC4659] and [I-D.heitz-bess-evpn-option-b], ASBR2 continues to assigns new label for the route and advertises it to ASBR1. When ASBR1 receives the UPDATE and continues to advertise the route to PE1, ASBR1 should assign an SRv6 VPN service SID for it. The SID indicates the new execution function (e.g., END.RM, it indicates that MPLS should replace the SRH) for exchanging the packet header from SRH to MPLS list. The new function format is like the defination in [I-D.ietf-spring-srv6-network-programming] section 4.

When a data flow packet, which has the destination to CE2, is received by ASBR1, ASBR1 recognizes the SRv6 SID, removes the outer IPv6 header and SRH, then adds a or a list of MPLS label in the packet, and forwards it to PE2. Note that the label stack is needed when the packet continues to enter an outer MPLS tunnel from ingress ASBR2 to egress PE2, otherwise only a single VPN label is encapsulated and the outer tunnel maybe a directly connected link.

Note that an END.RM SID may have non-zero argument length. When the SRv6 SID's argument length is not zero, the value of the argument part is translated into an extra-label in the list. for example, the extra-label is an ESI-label in IMET route cases.

4. IANA Considerations

IANA is requested to allocate a new code points for the new SRv6 Endpoint Behaviors defined in this document.

5. Security Considerations

This document introduces no new security consideration beyond those already specified in [RFC4364], [I-D.ietf-idr-bgp-prefix-sid], [I-D.ietf-spring-srv6-network-programming], [I-D.ietf-bess-srv6-services] and [I-D.agrawal-spring-srv6-mpls-interworking].

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses