| Internet-Draft | Label Allocation for Option B | January 2022 |
| Liu & Peng | Expires 6 July 2022 | [Page] |
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.¶
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 (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.¶
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.¶
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].¶
PE: Provider Edge¶
CE: ;Customer Edge¶
AS: Autonomous System¶
ASBR: Autonomous System Border Router¶
RD: Route Distinguisher¶
RR: Route Reflector¶
+--------------------------PE3
|
PE1-----------------------ASBR1-----------ASBR2------------------------PE2
| MPLS | | SRv6 |
|<------------------------->|<------------->|<-------------------------->|
| IBGP | EBGP | IBGP |
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.¶
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.¶
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.¶
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.¶
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 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 |
+-------------+---------------------------------------------+
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>.¶
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.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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.¶
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.¶
This document does not change the underlying security issues inherent in [RFC4364] and [I-D.ietf-bess-srv6-services].¶