BGP Extensions for Services in SRv6 and MPLS Coexisting Network
draft-ls-bess-srv6-mpls-coexisting-vpn-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Yao Liu , Bing Song | ||
| Last updated | 2020-09-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ls-bess-srv6-mpls-coexisting-vpn-00
BGP Working Group Yao. Liu
Internet-Draft Bing. Song
Intended status: Standards Track ZTE Corporation
Expires: March 10, 2021 September 6, 2020
BGP Extensions for Services in SRv6 and MPLS Coexisting Network
draft-ls-bess-srv6-mpls-coexisting-vpn-00
Abstract
This document proposes a method to achieve VPN/EVPN in a network
which supports both SRv6 and MPLS in a given domain, 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 March 10, 2021.
Copyright Notice
Copyright (c) 2020 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 March 10, 2021 [Page 1]
Internet-Draft IGP for Service Segment September 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. the Co-existence Scenario . . . . . . . . . . . . . . . . . . 2
3. BGP extensions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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
which supports both SRv6 and MPLS in a given domain, 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 March 10, 2021 [Page 2]
Internet-Draft IGP for Service Segment September 2020
+----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.
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 with the 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.
Liu & Song Expires March 10, 2021 [Page 3]
Internet-Draft IGP for Service Segment September 2020
3. BGP extensions
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.
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 sizes of the parts
of the SRv6 SID and to also indicate 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.
Liu & Song Expires March 10, 2021 [Page 4]
Internet-Draft IGP for Service Segment September 2020
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.
More processing details will be further discussed.
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>.
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. Security Considerations
TBD
Liu & Song Expires March 10, 2021 [Page 5]
Internet-Draft IGP for Service Segment September 2020
6. IANA Considerations
TBD
7. References
7.1. Normative References
[I-D.ietf-bess-srv6-services]
Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang,
S., and J. Rabadan, "SRv6 BGP based Overlay services",
draft-ietf-bess-srv6-services-04 (work in progress), July
2020.
[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>.
7.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.
[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 March 10, 2021 [Page 6]