Internet DRAFT - draft-lp-bess-vpn-interworking
draft-lp-bess-vpn-interworking
BESS Y. Liu
Internet-Draft S. Peng
Intended status: Informational ZTE
Expires: 22 March 2024 19 September 2023
A Label/SID Allocation Method for VPN Interworking Option B
draft-lp-bess-vpn-interworking-02
Abstract
This document analyzes the SRv6-MPLS service interworking option B
solution and proposes an MPLS label/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 22 March 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.
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 22 March 2024 [Page 1]
Internet-Draft Label Allocation for Option B September 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3
3. Service Interworking option B between SRv6 and MPLS . . . . . 3
3.1. Label Allocation Method . . . . . . . . . . . . . . . . . 4
3.1.1. Detailed Example for Service Interworking . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
[RFC9252]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 option B
solution and provides an MPLS label/SRv6 SID allocation method for
label/SID saving and better scalability purpose.
Liu & Peng Expires 22 March 2024 [Page 2]
Internet-Draft Label Allocation for Option B September 2023
2. Conventions used in this document
2.1. 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
BCP14 [[RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 option B 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.
Liu & Peng Expires 22 March 2024 [Page 3]
Internet-Draft Label Allocation for Option B September 2023
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.
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 services allow 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.
Liu & Peng Expires 22 March 2024 [Page 4]
Internet-Draft Label Allocation for Option B September 2023
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.
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 are propagated 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.
Liu & Peng Expires 22 March 2024 [Page 5]
Internet-Draft Label Allocation for Option B September 2023
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 [RFC9252]
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:
Liu & Peng Expires 22 March 2024 [Page 6]
Internet-Draft Label Allocation for Option B September 2023
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.
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
This document does not change the underlying security issues inherent
in [RFC4364] and [RFC9252].
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[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 22 March 2024 [Page 7]
Internet-Draft Label Allocation for Option B September 2023
[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>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
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 22 March 2024 [Page 8]
