BESS Working Group Z. Zhang Internet-Draft K. Kompella Updates: 9012, 4364 (if approved) Juniper Networks Intended status: Standards Track B. Decraene Expires: 10 January 2024 Orange L. Jalil Verizon 9 July 2023 VPN Inter-AS Option BC draft-zzhang-bess-vpn-option-bc-00 Abstract RFC 4364 specifies protocol and procedures for BGP/MPLS IP Virtual Private Networks (VPNs), including different options (A/B/C) of Inter-AS support. This document specifies MPLS VPN Inter-AS Option BC that combines the advantages of Option B and Option C (and that removes the disadvantages of Option B and Option C). The same concept is applicable to Ethernet Virtual Private Network (EVPN) as well. 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 10 January 2024. Copyright Notice Copyright (c) 2023 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. Zhang, et al. Expires 10 January 2024 [Page 1] Internet-Draft VPN Inter-AS Option BC July 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Option B and Option C Pros and Cons . . . . . . . . . . . 2 1.2. Option BC . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Using Multiple NLRI labels . . . . . . . . . . . . . 3 1.2.2. Using Tunnel Encapsulation Attribute . . . . . . . . 5 1.2.3. Use of Option BC in SRv6/MPLS Service Interworking Option BC . . . . . . . . . . . . . . . . . . . . . . 8 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 1.1. Option B and Option C Pros and Cons With the Inter-AS Option B, ASBRs readvertises its received VPN routes (referred to as service routes) with the next hop changed to itself and the label in the NLRI changed to a locally allocated (service) label that is bound to the in the received route, and installs corresponding label forwarding state. When it receives traffic and the locally allocated label is exposed at the top of the stack, the traffic is forwarded according to the installed forwarding state. With the Inter-AS Option C, the ASBRs are not involved in the exchange of service routes. The PEs receive service routes with the next hop unchanged, and label switch paths (LSPs) are established for each next hop. An ingress PE push the service label first, and then push the label(s) for the LSP to the egress PE. The routers along the path label switch the traffic only based on the label for the LSP to the egress PE. Zhang, et al. Expires 10 January 2024 [Page 2] Internet-Draft VPN Inter-AS Option BC July 2023 Because the ASBRs with Option B change the service routes' next hop and allocate local service labels on each hop, each AS's internal information (e.g. the loopback addresses) is hidden from outside the AS. Rich policy control could be applied on the ASBR-ASBR sessions, allowing very flexible and fine-grained route export control. As a result, Option B is very suitable for Inter-Provider scenarios. On the other hand, Option C scales much better becasue ASBRs don't need to handle service routes or maintain per-service-label forwarding state. Compared to Option B, it is more suitable for Intra-Provider multi-AS scenarios. 1.2. Option BC Option BC in this document combines the advantages of Option B and Option C. ASBRs re-advertise service routes with optional rich policy control. The service labels are not changed but the LSP towards the originating PE is advertised as part of the service routes - either as an additional label in the NLRI [RFC8277], or as a new type of tunnel in the Tunnel Encapsulation Attribute (TEA) [RFC9012] - without exposing the information about the originating PE. Consider the following topology: PE11 PE21 PE31 ----- ----- ----- (AS100) ASBR1 -- ASBR21 (AS200) ASBR22 -- ASBR3 (AS300) ----- ----- ----- PE12 PE22 PE32 PE11 and PE12 originate the following service routes respectively, where each tuple represents . * <100, sprfx1, PE11> * <100, sprfx2, PE12> 1.2.1. Using Multiple NLRI labels When ASBR1 re-advertises the routes to ASBR21, they become as following: * <201, 100, sprfx1, ASBR1> * <301, 100, sprfx2, ASBR1> Zhang, et al. Expires 10 January 2024 [Page 3] Internet-Draft VPN Inter-AS Option BC July 2023 The original service label 100 in the NLRI does not change, but a new binding label 201/301 is added respectively, and the next hop changes to ASBR1. Label 201/301 binds to PE11/PE12 respectively and ASBR1 sets up forwarding state so that when it receives a packet with label 201 (or 301), it label switches to PE11 (or PE12). Similarly, when ASBR21 re-advertises the routes to its peers in AS200, the routes become: * <202, 100, sprfx1, ASBR21> * <302, 100, sprfx2, ASBR21> Again, the inner service label does not change and the outer label 201/301 changes to 202/302 respectively. ASBR21 installs forwarding state so that when it receive packets with label 202/302, it swaps the label to 201/301 and then tunnel to ASBR21 the next hop. This continues. ASBR22 re-advertise to ASBR3 as following: * <203, 100, sprfx1, ASBR22> * <303, 100, sprfx2, ASBR22> and ASBR3 re-advertises to its AS300 peers as following: * <204, 100, sprfx1, ASBR3> * <304, 100, sprfx2, ASBR3> When PE31/PE32 sends traffic for sprfx1/sprfx2, the following label stacks are used respectively: *