Internet DRAFT - draft-ls-bess-srv6-mpls-coexisting-vpn
draft-ls-bess-srv6-mpls-coexisting-vpn
BGP Working Group Y. Liu
Internet-Draft B. Song
Intended status: Standards Track ZTE Corporation
Expires: July 11, 2021 January 7, 2021
BGP Extensions for Services in SRv6 and MPLS Coexisting Network
draft-ls-bess-srv6-mpls-coexisting-vpn-01
Abstract
This document proposes a method to achieve VPN/EVPN in a network
where SRv6 and SR-MPLS/MPLS coexist, including extensions of BGP.
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 July 11, 2021.
Copyright Notice
Copyright (c) 2021 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.
Liu & Song Expires July 11, 2021 [Page 1]
Internet-Draft Dual Stack VPN January 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. the Co-existence Scenario . . . . . . . . . . . . . . . . . . 2
3. BGP extensions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extended SRv6 Service TLVs . . . . . . . . . . . . . . . 4
3.2. Dual-Stack VPN Capability . . . . . . . . . . . . . . . . 6
4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The incremental deployment of SRv6 into existing networks require
SRv6 to interwork and co-exist with SR-MPLS/MPLS.
Currently [I-D.agrawal-spring-srv6-mpls-interworking] and
[I-D.pzm-bess-spring-interdomain-vpn] discuss about the SRv6 and MPLS
interworking method.
In the progress of upgrading some network, some of the legacy devices
that support only MPLS/SR-MPLS will coexist with the new devices
capable SRv6 for a long time. The co-existence scenario also need to
be further addressed.
This document proposes a method to achieve VPN/EVPN in a network
where SRv6 and SR-MPLS/MPLS coexist, including extensions of BGP.
2. the Co-existence Scenario
+----R1----R2----+
| | +----+CE21
| | |
CE1+----+PE1 PE2+
| | |
| | +----+CE22
+----R3----R4----+
Figure 1: Reference Topology 1
Liu & Song Expires July 11, 2021 [Page 2]
Internet-Draft Dual Stack VPN January 2021
+----R1----R2----+
| |
CE1+----+PE1 |
PE2+----+CE2
CE3+----+PE3 |
| |
+----R3----R4----+
Figure 2: Reference Topology 2
As shown in Figure 1 and Figure 2, R3 and R4 are capable of SRv6, R1
and R2 are legacy devices which only support SR-MPLS/MPLS.
In Figure 1, PE2 is connected to different services with different
SLA requirements. Different SLA requirements may correspond to
different forwarding paths, these paths may be SRv6 capable, or may
pass through the devices that only support SR-MPLS/MPLS.
In Figure 2, to reach for the same service, the underlay path from
PE1 to PE2 support SRv6 forwarding, while the path from PE3 to PE2
passes through the devices that only support SR-MPLS/MPLS.
Existing solutions include the following:
1)The egress PE allocates the MPLS label and SRv6 SID for the same
service and advertise them separately through different routes, which
have different priorities, the ingress PE then selects the route of
higher priority.
For example, in Figure 1, an end-to-end VPN IPv4 BGP peer
relationship and a IPv6 BGP peer relationship are established between
PE1 and PE2.
After PE2 receives a VPN route from its VPN instance, PE2 advertises
a copy of this route to the VPN IPv4 BGP peer and applies for an MPLS
label. PE2 then advertises another copy to the VPN IPv6 BGP peer,
with the route carrying a SRv6 SID. PE1 receives two VPN routes with
the same prefix, one with an IPv4 next hop and the other with an IPv6
next hop. The route with the IPv4 next hop recurses to the MPLS
tunnel, and the route with the IPv6 next hop recurses to the SRv6
tunnel. If routes with IPv4 next hops are of higher priority, the
MPLS tunnel is chosen, otherwise the traffic reaches the PE2 through
the SRv6 tunnel.
The disadvantage of this method is that only one route can take
effect at the same time and the method is not flexible enough. In
figure 1, if the best path from CE1 to CE21 is a MPLS tunnel while
Liu & Song Expires July 11, 2021 [Page 3]
Internet-Draft Dual Stack VPN January 2021
the expected path from CE1 to CE22 is an SRv6 tunnel, this method
cannot meet such requirements easily.
2)If the underlay path attribute corresponding to each service is
predictable, the egress PE allocates either MPLS labels or SRv6 SIDs
for each service based on the underlay path attribute. That is, the
engress PE advertises only one kind of BGP route for a particular
service prefix, either with MPLS labels or the SRv6 SIDs.
Once the path attribute of underlay is changed, for example, the
device that only supports MPLS forwarding is upgraded to support
SRv6, the configuration on PE should also be changed accordingly.
Based on the above scenarios, this document proposes a method:
The egress PE allocates MPLS label(s) and SRv6 SID(s) for the same
service and signals them within the same BGP overlay service route.
After receiving the BGP advertisement, the ingress PE should add the
prefix with the MPLS label and SRv6 SID information to the RIB.
When encapsulating packets, the ingress PE selects whether to use
MPLS label or SRv6 SID according to the attribute of the underlay
path.
If there is a route reflector in the network, it must support the
extended BGP message too.
Currently, the MPLS-based VPN/EVPN service information is encoded in
the MPLS Label field of the corresponding NLRI, and the SRv6-based
VPN/EVPN service information is encoded as SRv6 service SIDs such as
END.DT*/END.DX*/END.DT2 with BGP Prefix-SID attribute [RFC8669]
extended to carry SRv6 service SIDs information
[I-D.ietf-bess-srv6-services]
But how does the egress PE indicate in the BGP advertisement that a
service supports both MPLS and SRv6 identification is not clearly
described.
3. BGP extensions
3.1. Extended SRv6 Service TLVs
For the convenience of understanding and reading, the two methods of
notifying SRv6 SID in [I-D.ietf-bess-srv6-services] are described
briefly below.
Liu & Song Expires July 11, 2021 [Page 4]
Internet-Draft Dual Stack VPN January 2021
In the first method, SRv6 Service SIDs are encoded as a whole in the
SRv6 Services TLVs. In this case, the MPLS Label field(s) of the
corresponding NLRI is set to Implicit NULL.
The second method is called Transposition Scheme of encoding, where
the SRv6 SID Structure Sub-Sub-TLV describes the size of each part of
the SRv6 SID and also indicates the offset of variable part along
with its length in SRv6 SID value. The function and/or the argument
part of the SRv6 SID is encoded in the MPLS Label field of the NLRI
and the SID value in the SRv6 Services TLV carries only the locator
part with the SRv6 SID Structure Sub-Sub-TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length |M| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 Service Sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Extended SRv6 Service TLVs
This document introduces a M-flag in the RESERVED field of SRv6
Services TLVs as shown in figure 3, when set, it indicates that this
service supports both MPLS label and SRv6 service SID identification.
If the advertisement message carries multiple SRv6 Service TLVs at
the same time, for example, in the EVPN scenario, the M-flag of the
these TLVs must be set to the same. If not, the advertisement MUST
be discarded.
The MPLS-based VPN/EVPN service information is always encoded in the
MPLS Label field of the NLRI.
If the Transposition Scheme of encoding is needed, the egress PE MUST
allocate SRv6 service SIDs with the function and/or the argument part
same as the MPLS VPN label.
Otherwise, SRv6 SIDs and MPLS labels can be of independent values,
and SRv6 Service SIDs are encoded as a whole in the SRv6 Services
TLVs.
The allocation of SRv6 SIDs and MPLS labels for VPN/EVPN on egress
PEs is an implementation thing, and it is outside the scope of this
document.
Liu & Song Expires July 11, 2021 [Page 5]
Internet-Draft Dual Stack VPN January 2021
More processing details will be further discussed.
3.2. Dual-Stack VPN Capability
[RFC5492] defines the "Capabilities Optional Parameter". A BGP
speaker can include a Capabilities Optional Parameter in a BGP OPEN
message. The Capabilities Optional Parameter is a triple that
includes a one-octet Capability Code, a one-octet Capability length,
and a variable-length Capability Value.
This document defines a Capability Code for dual-stack VPN
capability.
If a BGP speaker has not sent the dual-stack VPN capability in its
BGP OPEN message on a particular BGP session, or if it has not
received the dual-stack VPN capability in the BGP OPEN message from
its peer on that BGP session, that BGP speaker MUST NOT send on that
session any UPDATE message that includes the extended SRv6 service
TLVs.
4. Illustration
The reference topology is show in Figure 2. PEs support both SRv6
and SR-MPLS capabilities.
Take IPv4 VPN as an example, PE2 assigns an MPLS label vpn2 and an
SRv6 service SID(eg, END.DX4) sid2 for CE2, and the function part of
the SID is vpn2.
Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277]
with the Label Value set to vpn2.
If Transposition Scheme of encoding is used, the locator part of the
SRv6 Service SID is encoded in the SRv6 L3 Service TLV with the
M-flag set to 1.
PE1 and PE3 learn through M-flag that CE2 has both MPLS and SRv6
identification, and obtain the corresponding MPLS label and SRv6 SID
carried in the BGP update messages.
When a service prefix is received on PE1, by looking at the local
forwarding table, PE1 finds that the service is related to an MPLS
label and an SRv6 SID, and the corresponding path is a segment list
consisting of SR-MPLS SIDs , such as <Label 1, Label 2>. PE1 then
encapsulates the payload packet with an MPLS label stack <Label 1,
Label 2, vpn2>.
Liu & Song Expires July 11, 2021 [Page 6]
Internet-Draft Dual Stack VPN January 2021
Similarly, PE3 finds out that the underlay path is based on SRv6 such
as <SID3, SID4>, then it encapsulates the payload packet in an outer
IPv6 header with the segment list <SID3, SID4, sid2>.
5. Operation
If the underlay between PEs support IPv6 forwarding, including SRv6
and IPv6-MPLS, it is simple to implement dual-stack VPN using the
above extensions. The PEs advertises the BGP route with an IPv6 next
hop. Once whether the forwarding path is based on SRv6/IPv6 or
IPv6-MPLS is decided, the subsequent processing is based on the
existing BGP procedure.
Another scenario is that the legacy devices only support IPv4-based
MPLS forwarding. In this case, the PEs should support IPv4/IPv6 dual
stack and using an IPv4 next hop when advertising VPN routes. If the
MPLS tunnel is chosen, the packet forwarding procedure is unchanged.
When providing SRv6-based best-effort connectivity to the egress PE,
the ingress PE encapsulates the payload in an outer IPv6 header where
the destination address is the SRv6 Service SID associated with the
related BGP route update. The reachability of SRv6 service SID
should be provided by other means, such as IGP or BGP advertisement
and the forwarding is independent of the IPv4 next hop in the BGP VPN
route.
If the BGP route received at an ingress PE is colored with an
extended color community and is expected to be steered over a SRv6
Policy, there're two options:
a) Use color-only steering method regardless of the next hop of the
BGP route and the endpoint of SR policy
[I-D.ietf-spring-segment-routing-policy] section 8.8.1.
b) Steer on an SR Policy by the matching of the BGP route's next-hop
N and color C with an SR Policy defined by the tuple endpoint N and
color C. Then the endpoint of the SRv6 Policy should be configure as
an IPv4 address.
Note that it is not stipulated in
[I-D.ietf-spring-segment-routing-policy] that the endpoint of an SRv6
Policy must also be an IPv6 address.
6. Security Considerations
TBD
Liu & Song Expires July 11, 2021 [Page 7]
Internet-Draft Dual Stack VPN January 2021
7. IANA Considerations
TBD
8. References
8.1. Normative 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", draft-ietf-bess-srv6-services-05 (work
in progress), November 2020.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-11 (work in progress), November 2020.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress),
November 2020.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>.
8.2. Informative References
[I-D.agrawal-spring-srv6-mpls-interworking]
Agrawal, S., Ali, Z., Filsfils, C., Voyer, D., and Z. Li,
"SRv6 and MPLS interworking", draft-agrawal-spring-srv6-
mpls-interworking-03 (work in progress), August 2020.
Liu & Song Expires July 11, 2021 [Page 8]
Internet-Draft Dual Stack VPN January 2021
[I-D.pzm-bess-spring-interdomain-vpn]
Zhang, Z., Peng, S., Mirsky, G., and Y. Wang, "SRv6 and
MPLS interworking for VPN service", draft-pzm-bess-spring-
interdomain-vpn-02 (work in progress), August 2020.
Authors' Addresses
Liu Yao
ZTE Corporation
Email: liu.yao71@zte.com.cn
Song Bing
ZTE Corporation
Email: song.bing@zte.com.cn
Liu & Song Expires July 11, 2021 [Page 9]
