BESS                                                              Y. Liu
Internet-Draft                                                   S. Peng
Intended status: Informational                                       ZTE
Expires: 6 July 2022                                      2 January 2022


           A Label/SID Allocation Method for VPN Interworking
                   draft-lp-bess-vpn-interworking-00

Abstract

   This document analyzes the SRv6-MPLS service interworking solution
   and offers an MPLS label or SRv6 SID allocation method for label/SID
   saving and better scalability purpose.

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 6 July 2022.

Copyright Notice

   Copyright (c) 2022 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 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.






Liu & Peng                 Expires 6 July 2022                  [Page 1]


Internet-Draft        Label Allocation for Option B         January 2022


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology and Acronyms  . . . . . . . . . . . . . . . .   3
   3.  Service Interworking between SRv6 and MPLS  . . . . . . . . .   3
     3.1.  Label Allocation Method . . . . . . . . . . . . . . . . .   4
       3.1.1.  Detailed Example for Service Interworking . . . . . .   5
     3.2.  Control of the Allocation Method  . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Inter-AS option B is one of the ways in which the PE routers from
   different ASes can exchange the MPLS VPN routes with each other as
   described in [RFC4364].  This method uses BGP to signal MPLS VPN
   labels between the AS boundary routers.

   [I-D.ietf-bess-srv6-services] defines procedures and messages to
   carry SRv6 Service SIDs and form VPNs in SRv6.  SRv6 Service SID
   refers to an SRv6 SID associated with one of the service-specific
   SRv6 Endpoint behaviors on the advertising PE router, and its usage
   is similar to MPLS VPN label to some extent.

   In the progress of network upgrading, some of the legacy devices(e.g,
   PEs) that only support MPLS VPN will coexist with the new devices
   capable of SRv6 VPN for a long time.  For service connectivity,
   services over the SRv6 PE need to interwork with that over MPLS PE.

   A common method for service interworking is similar to inter-AS
   option B.  ASBRs needs to translate between MPLS VPN labels and SRv6
   service SIDs, i.e, when an ASBR receives an SRv6 VPN route from the
   egress PE, it needs to allocate an MPLS VPN label for it and
   advertise the corresponding MPLS VPN route to the ASBR in the MPLS
   domain.

   This document analyzes the SRv6-MPLS service interworking solution
   and offers an MPLS label or SRv6 SID allocation method for label/SID
   saving and better scalability purpose.

2.  Conventions used in this document




Liu & Peng                 Expires 6 July 2022                  [Page 2]


Internet-Draft        Label Allocation for Option B         January 2022


2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Terminology and Acronyms

   PE: Provider Edge

   CE: ;Customer Edge

   AS: Autonomous System

   ASBR: Autonomous System Border Router

   RD: Route Distinguisher

   RR: Route Reflector

3.  Service Interworking between SRv6 and MPLS

                                                +--------------------------PE3
                                                |
    PE1-----------------------ASBR1-----------ASBR2------------------------PE2


    |          MPLS             |               |          SRv6              |
    |<------------------------->|<------------->|<-------------------------->|
    |          IBGP             |     EBGP      |          IBGP              |

          Figure 1: Reference Multi-Domain Network Topology

   As shown in Figure 1, PE1 is a legacy device that only supports MPLS-
   based services.  PE2 and PE3 support SRv6-based services.  ASBR2, as
   a node in the domain with new features, support both MPLS and SRv6.

   On PE2, SRv6 service SID SID-21 is allocated, per VPN instance, for
   VPN prefix 1 and prefix 2 in VRF1, SRv6 service SID SID-22 is
   allocated, per VPN instance, for VPN prefix 2 in VRF2.  On PE3, SRv6
   service SID SID-31 is allocated, per VPN instance, for VPN prefix 2
   in VRF1.  Route distinguisher RD1 is configured for VRF1 and RD2 for
   VRF2.

   The SRv6 VPN route carrying the corresponding service SID and RD with
   it propagates to ASBR2.





Liu & Peng                 Expires 6 July 2022                  [Page 3]


Internet-Draft        Label Allocation for Option B         January 2022


   On ASBR2, the received SRv6 service SID needs to be replaced by a new
   MPLS label, then the new MPLS VPN label propagates to ASBR1.

   On ASBR1, the received MPLS VPN label needs to be replaced by a new
   MPLS label, then the new MPLS VPN label propagates to PE1.

3.1.  Label Allocation Method

   On ASBR2, MPLS VPN label can be allocated per <RD, service prefix>.

   However, there may be scalability issues.  The 128-bit encoding space
   in SRv6 is much more larger compared with the 20-bit label space in
   MPLS, which means SRv6-based VPN allows massive number of sites(with
   different prefixes) to access.  If the MPLS label is allocated per
   prefix in this case, the number of MPLS labels may be not enough.  A
   label-saving allocation solution is needed for better scalability.

   In order to save label resources, the MPLS label can be allocated per
   <SRv6-SID, next-hop> sets.

   If this method is used, on ASBR2, MPLS lalel L21 is allocated for
   SID-21 on PE2, L22 for SID-22 on PE2 and L31 for SID-31 on PE3.

   The disadvantage of this method is that once the next-hop is changed,
   the old label needs to be released and new label needs to be
   allocated, the corresponding MPLS VPN label should be withdrawed and
   re-advertised with the new one.  For example, in the FRR case, the
   primary next-hop may be down and the converged path contains the
   original backup next-hop, that may cause the oscillation of label
   allocation, especially when there're large numbers of SRv6 service
   SID on the PE.

   This document proposes that the MPLS label can be allocated per RD on
   ASBR.  And it is required that the RD of different VRF instance MUST
   be different.

   The ILM table is built based on the mapping relationship between the
   allocated label and RD, and it leads to the query of the RD context
   tables.  The RD context tables are built based on the received VPN
   routes.

   For one packet, the ASBR would query two tables to get the outgoing
   action, this behavior is similar to that in inter-AS option A in
   RFC4364, but unlike option A, there's no VRF instance configuration
   on the ASBR.






Liu & Peng                 Expires 6 July 2022                  [Page 4]


Internet-Draft        Label Allocation for Option B         January 2022


   The per-RD allocation method applies for MPLS VPN inter-AS option B
   as well, i.e., similar operation can be done on ASBR1.  The
   difference is that the encapsulating IPv6 action in the RD Entry
   Table should be replace by pushing the MPLS VPN label.

   In addition, per-RD allocation can also apply for SRv6 VPN SID on
   ASBR2 when it received VPN routes from ASBR1, and the endpoint
   behaviour can still be END.DT4/6.

3.1.1.  Detailed Example for Service Interworking

   This section provides a detailed example for service interworking
   between SRv6 and MPLS based on the per-RD label allocation method.
   The reference topology is shown in Figure 1.

   Control Plane:

   1)Egress PE2 advertises a BGP SRv6 VPN route: RD:RD1, prefix:prefix2,
   next hop: lo-PE2, service SID: SID22.

   Egress PE3 advertises a BGP SRv6 VPN route: RD:RD1, prefix:prefix2,
   next hop: lo-PE3, service SID: SID31.

   PE3 acts as the backup of PE2 for prefix2, and the route from PE3 has
   lower priority.

   These routes propagates to ASBR2.

   2)The reachability of lo-PE2 and lo-PE3 is advertised by IGP within
   the domain.

   3)ASBR2 learns <RD1,prefix1> with next hop lo-PE2 and SID22.  ASBR2
   learns <RD1,prefix1> with next hop lo-PE3 and SID31.

   ASBR2 allocates MPLS label label-21 based on RD1.

   The ILM forwarding table and RD context Table is shown in Figure 2.

   ASBR2 uses the destination address of the packet to match the
   corresponding entry and determine the outgoing action.

   The outgoing action shown in RD1 context table only provides an
   example when the SRv6 service is provided with best-effort
   connectivity, the ASBR2 encapsulates the payload in an outer IPv6
   header where the destination address is the SRv6 Service SID provided
   by the egress PE.  If SRv6 service is provided in conjunction with an
   underlay SLA from the egress PE, ASBR2 may encapsulate the payload
   packet in an outer IPv6 header with the segment list of SR policy



Liu & Peng                 Expires 6 July 2022                  [Page 5]


Internet-Draft        Label Allocation for Option B         January 2022


   associated with the related SLA along with the SRv6 Service SID
   associated with the route using the Segment Routing Header (SRH)
   [RFC8754].  The detailed encapsulate method is specified in
   [I-D.ietf-bess-srv6-services] and this document doesn't change that
   procedure.

         ILM table
         +=============+=============================================+
         | In label    | Action                                      |
         +=============+=============================================+
         | label-21    | pop, lookup table.RD1                       |
         +-------------+---------------------------------------------+

         RD1 context table
         +=============+=============================================+
         | Prefix      | Outgoing Action                             |
         +=============+=============================================+
         | prefix2     | Primary:                                    |
         |             |        encap IPv6 with DA=SID22, fwd to PE2 |
         |             | Backup:                                     |
         |             |        encap IPv6 with DA=SID31, fwd to PE3 |
         +-------------+---------------------------------------------+

                    Figure 2: Forwarding State on ASBR2

   4) ASBR2 advertises an MPLS VPN label to ASBR1: RD:RDa,
   prefix:prefix2, next hop: ASBR2, VPN label: label-21.

   5) ASBR1 learns <RDa,prefix2> with next hop ASBR2 and label-21.

   ASBR1 changes the next-hop to itself and allocates a new label label-
   11, then ASBR1 advertises a BGP MPLS VPN route: RD:RDb,
   prefix:prefix1, next hop: ASBR1, VPN label: label-11.

   The route propagates via RR to PE1.

   6) PE1 learns <RDa,prefix1> with next hop ASBR1 and label-11.

   7) An LSP from PE1 to ASBR1 is build via LDP, the corresponding label
   of the tunnel is label-T.

   Data Plane:

   1) PE1 performs MPLS label stack encapsulation with VPN label and
   tunnel label.

   The packet leaving PE1: <label-T,label-11;payload>.




Liu & Peng                 Expires 6 July 2022                  [Page 6]


Internet-Draft        Label Allocation for Option B         January 2022


   2) ABSR1 pop the tunnel label and swap the VPN label.

   The packet leaving ASBR1 towards ASBR2: <label-21;payload>.

   3) Based on the received label-21, ASBR2 looks up table.RD1.

   Because the destination address of the payload match prefix2, ASBR2
   encapsulates the payload in an outer IPv6 header where the
   destination address is SID21 and forward the packet to PE2.

   If PE2 fails, ASBR2 would choose the backup outgoing action and
   forwards the packet to PE3 with SID31.



3.2.  Control of the Allocation Method

   The per-RD label allocation method can be enabled by configuration on
   ASBRs.

   If many configurations are required in a large-scale network,
   controlling the allocation by protocol extensions may be taken into
   consideration.

   A new BGP Extended Communities Attribute[RFC4360] is defined for this
   purpose.

           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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |       0x03    |     TBD1      |         Allocation Type       |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                          Reserved                             |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: Label Allocation Extended Community

   The value of the high-order octet of the extended type field is 0x03,
   which indicates it is transitive.

   The value of the low-order octet of the extended type field for this
   community is TBD1, which indicates it is the label allocation
   extended community.

   Allocation Type field is used to indicate the label/SID allocation
   method, the value 0x01 indicates that the label/SID should be
   allocated based on the RD value in the NLRI.  Other values are
   reserved for future definition.



Liu & Peng                 Expires 6 July 2022                  [Page 7]


Internet-Draft        Label Allocation for Option B         January 2022


   The egress PE advertises VPN route with the label allocation extended
   community to indicate that the ASBR should allocate the incomming
   MPLS label or SID for the received route based on the allocation
   method identified in the extended community.

   An implementation SHOULD ensure that the label/SID allocation on ASBR
   doesn't conflict with each other.

4.  IANA Considerations

   IANA is requested to assign one new values from the "BGP Opaque
   Extended Community" type Registry.  It is from the transitive range.
   The new value is called "Label Allocation Extended Community"
   (0x03TBD1).  This document is the reference for the assignments.

5.  Security Considerations

   This document does not change the underlying security issues inherent
   in [RFC4364] and [I-D.ietf-bess-srv6-services].


6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

6.2.  Informative References

   [I-D.ietf-bess-srv6-services]
              Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R.,
              Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based
              Overlay Services", Work in Progress, Internet-Draft,
              draft-ietf-bess-srv6-services-08, 10 November 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              srv6-services-08>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.




Liu & Peng                 Expires 6 July 2022                  [Page 8]


Internet-Draft        Label Allocation for Option B         January 2022


   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

Authors' Addresses

   Yao Liu
   ZTE
   Nanjing
   China

   Email: liu.yao71@zte.com.cn


   Shaofu Peng
   ZTE
   Nanjing
   China

   Email: peng.shaofu@zte.com.cn






























Liu & Peng                 Expires 6 July 2022                  [Page 9]