Internet DRAFT - draft-zzhang-spring-service-interworking
draft-zzhang-spring-service-interworking
spring Z. Zhang
Internet-Draft Juniper Networks
Intended status: Standards Track B. Decraene
Expires: 15 March 2024 Orange
S. Zadok
Broadcom
L. Jalil
Verizon
D. Voyer
Bell Canada
12 September 2023
MPLS/SRv6 Service Interworking Option BC
draft-zzhang-spring-service-interworking-02
Abstract
Draft-bonica-spring-srv6-end-dtm specifies SRv6/MPLS transport
interworking procedures, and draft-agrawal-spring-srv6-mpls-
interworking specifies SRv6/MPLS transport and service interworking
procedures. For service interworking, the latter draft defines two
modes, similar to VPN Inter-AS Option A and Option B. This document
specifies another Option BC for service interworking which has much
better scaling property.
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 15 March 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 15 March 2024 [Page 1]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Re-advertising Service Routes from MPLS to SRv6 Domain . 3
1.2. Re-advertising Service Routes from SRv6 to MPLS Domain . 5
1.2.1. IPv4 MPLS Domain . . . . . . . . . . . . . . . . . . 6
1.3. EVPN ESI Label . . . . . . . . . . . . . . . . . . . . . 6
2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[I-D.bonica-spring-srv6-end-dtm] specifies SRv6/MPLS transport
interworking procedures, and
[I-D.agrawal-spring-srv6-mpls-interworking] specifies SRv6/MPLS
transport and service interworking procedures. For service
interworking, the latter draft defines two styles, similar to VPN
Inter-AS Option A and Option B [RFC4364].
Specifically, for Option B style interworking, an InterWorking (IW)
node does the following:
* For service routes received from MPLS domain, re-advertise to SRv6
domain with an SRv6 SID (whose bits may be transposed in NLRI and
in the Prefix SID attribute) and with nexthop set to itself. The
SID maps to the <service label, nexthop> tuple as received from
the MPLS domain. For service traffic from SRv6 domain, the
incoming SID maps to <base tunnel to nexthop, service label>
forwarding state in the MPLS domain.
* For service routes received from SRv6 domain, re-advertise to MPLS
domain with an MPLS label and with nexthop set to itself. The
label maps to the service SID (whose bits may be transposed in
Zhang, et al. Expires 15 March 2024 [Page 2]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
NLRI and in the Prefix SID attribute) as received from the SRv6
domain. For service traffic from MPLS domain, the incoming
service label maps to corresponding forwarding state in the SRv6
domain.
This is a straightforward solution that does not require service
instances on the IW node. However, it does require per-service
label/SID forwarding state on the IW node, that Inter-AS Option C
[RFC4364] VPN does not require.
For a true Option C style MPLS/SRv6 service interworking, the SRv6
service PEs must support MPLSoverUDP or MPLSoverIP, and as such there
is no "service interworking" for Option C - it's just MPLS based
services over interworked MPLS/SRv6 transport.
This document proposes an Option BC style service interworking that
does not require per-service-label/SID state on the IW nodes, and the
service PEs can be single plane - MPLS or SRv6 only.
The key behind the Option BC style interworking is that the SRv6
Service SID is encoded in two parts of a service route - in the
"label" field of the NLRI and the Prefix SID attribute. The SRv6 SID
Structure sub-sub-TLV specifies the LOC:FUNCT:ARG encoding scheme of
the Service SID, and specifies the which part of the Service SID the
"label" field of the NLRI fits into. In most cases, the ARG part is
not used, with the exception of EVPN multi-homing support with label-
based split-horizon filtering [RFC7432] [RFC9252]. This is discussed
in Section 6.1.1 of [RFC9252] and in Section 1.3 of this document.
1.1. Re-advertising Service Routes from MPLS to SRv6 Domain
When the IW node re-advertises a service route from MPLS domain to
SRv6 domain, it attaches a Prefix SID attribute but does not change
the label field of the NLRI. An SRv6 SID Structure Sub-Sub-TLV is
included in the L2/L3 SRv6 Service TLV's SRv6 SID Information sub-
TLV, specifying the LOC:FUNCT:ARG encoding scheme and which part of
the SID (in the SRv6 SID value field of the SRv6 SID Information sub-
TLV) that the label field of the NLRI fits into.
Zhang, et al. Expires 15 March 2024 [Page 3]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
Signaling of service prefix spfx2
<------------------- <---------------------
<200, spfx2, IWN, PrefixSID> <200, spfx2, PE2>
SRv6 IW MPLS
PE1 Node PE2
<IWN:hFUNCT:200::, payload> <PE2 SID, 200, payload>
-------------------> --------------------->
Traffic for service prefix spfx2
A receiving SRv6 PE sends corresponding service traffic using the
SRv6 Service SID resulting from superimposing the label value in the
NLRI(s) to the SID in SRv6 SID Information sub-TLV.
On the IW node, the higher FUNCT bits (referred to as hFUNCT) of the
Service SID in the Prefix SID attribute indicate a new End.DBS
behavior, where DBS stands for Decapsulate, Binding, and Shifting.
The hFUNCT bits also map/bind to a particular MPLS router, which is
the BGP protocol nexthop in the service route received from the MPLS
domain. Note that the MPLS router could either be an MPLS service
PE, or an ASBR implementing Inter-AS Option B.
When a service packet arrives from the SRv6 domain, the IW node
identifies an MPLS router (that advertised the service route to the
IW node) based on the hFUNCT bits. Since the hFUNCT bits identify
the End.DBS end behavior, the packet is decapsulated, the incoming
SID's certain bits are extracted as MPLS service label, and then the
packet is sent to the corresponding MPLS router with the <base tunnel
label, service label> label stack.
For example, the LOC:FUNCT:ARG encoding of the SRv6 SID that the IW
node advertises could be 64:44:20 where the numbers represent the
number of bits in each part. The 20-bit ARG part is not used except
in the case of EVPN ESI label based split-horizon filtering
(Section 1.3). The lower 20 bits of the 44-bit FUNCT part are for
the MPLS label received from the MPLS side, X number of bits of the
44-bit FUNCT part are used to identify End.DBS behavior for each MPLS
PE/ASBR - only 10 bits are needed for 1k of PEs/ASBRs on MPLS side.
The rest of FUNCT space can still be used for other purposes. The
IWS only needs to maintain IPv6 1k SIDs in the forwarding path to
switch traffic to those 1k MPLS PEs/ASBRs using the End.DBS behavior,
no matter how many service labels are advertised from those PEs/
ASBRs.
Zhang, et al. Expires 15 March 2024 [Page 4]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
If transposition is not to be used, the above procedure can still be
used with a small change. The 20-bit label field in the received
NLRI is extracted and superimposed to the lower 20-bit of the FUNCT
part of the SID value in the SRv6 SID Information Sub-TLV.
1.2. Re-advertising Service Routes from SRv6 to MPLS Domain
When the IW node re-advertises a service route from SRv6 domain to
MPLS domain, the Prefix SID attribute is removed but the label field
in the NLRI does not change. The nexthop is set to an address mapped
to the SID value in the SRv6 SID Information Sub-TLV of the L2/L3
SRv6 Service TLV in the Prefix SID attribute. If the MPLS domain is
IPv6, the address can be the SID value itself.
Signaling of service prefix spfx1
-------------------> --------------------->
<100, spfx1, PE1, Prefix SID> <100, spfx1, IWNH>
<300, IWNH, IWN>
SRv6 IW MPLS
PE1 Node PE2
<SID:100::, payload> <IWN SID, 300, 100, payload>
<------------------- <---------------------
Traffic for service prefix spfx1
In addition, the IW node advertises a underlay route for the BGP
protocol nexthop in the re-advertised service route. If BGP-LU
[RFC8277] is used, a per-prefix binding label is advertised and the
nexthop is set to the IW node itself. If IGP is used, the per-prefix
binding label is advertised as a Prefix SID with both V-flag and
L-flag set [RFC8665] [RFC8667].
When an MPLS PE (or ASBR in case of Inter-AS Option B) receives the
service route, it resolves the protocol nexthop via the underlay
route. As a result, service traffic is sent with a label stack
<underlay tunnel label used to reach the IW node, binding label for
the underlay prefix (i.e. nexthop), service label in NLRI>.
When the IW node gets service traffic from the MPLS domain, the
binding label for the underlay prefix (which is or maps to the SID in
the Prefix SID attribute of the service route from the SRv6 domain)
leads to the following processing:
* Pop the next label, which is the service label
Zhang, et al. Expires 15 March 2024 [Page 5]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
* Find the SRv6 SID that is associated with the binding label (note
that the underlay prefix is or maps to the SID in the Prefix SID
attribute), and super impose the popped service label to it
according to the Transposition offset/length in the SID Structure
sub-sub-TLV in the Prefix SID attribute.
* Send packet after encapsulating it in IPv6 with the resulting SID
If transposition is not used, the entire SRv6 SID value is encoded in
the SID Information Sub-TLV of the Prefix SID attribute. The above
procedure can still be used with a small change - the lower 20 bits
of the FUNCT part is extracted and filled into the label field of the
NLRI, and the remaining LOC:FUNCT part is treated as if it was
signaled with transposition.
1.2.1. IPv4 MPLS Domain
As described earlier, if the MPLS domain is IPv4, one IPv4 address is
needed on the IW node to map to each distinct SID value received from
the SRv6 side, and a corresponding transport route is advertised. If
that is a concern, the techniques in [I-D.zzhang-bess-vpn-option-bc]
can be used. Instead of allocating and advertising those IPv4
addresses, the IW node inserts a Tunnel Encapsulate Attribute with a
Composite Tunnel, whose tunnel egress endpoint address is set to a
loopback address on the IW node and the binding label is set to one
allocated for the SID value. Alternatively, multiple labels in the
service NLRI can be used as described in that draft's "Using Multiple
NLRI labels" section.
1.3. EVPN ESI Label
Typically, if there are separate SRv6 and MPLS domains for an EVPN
network, multihoming is likely within a domain. In case of
multihoming across domains, the following method can be used to
achieve label based split-horizon filtering across the domains.
When the IW node re-advertises the EVPN Ethernet A-D per ES Route
from MPLS domain to SRv6 domain, a Prefix SID attribute is attached,
with the SID Structure sub-sub-TLV specifying the transposition
length and offset for the ESI label, as specified in Section 6.1.1 of
[RFC9252].
When SRv6 service traffic arrives at the IW node, if the end behavior
for the SID is End.DBS and the ARG part is not 0, the IW node
extracts the ARG bits into an ESI label that is imposed before the
service label (that is extracted from the FUNCT bits) is imposed.
Zhang, et al. Expires 15 March 2024 [Page 6]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
When the IW node re-advertise the EVPN Ethernet A-D per ES Route from
SRv6 domain to MPLS domain, the Prefix SID attribute is simply
removed but the transposition information is saved locally.
When MPLS service traffic arrives at the IW node, if there is another
label after the service label, that label is also popped and
superimposed to the SRv6 Service SID that is bound to the binding
label described in Section 1.2, in addition to that the service label
is popped and superimposed to the same SRv6 Service SID.
2. Procedures
Normative procedures will be specified in future revisions of the
document.
3. Security Considerations
The Option BC interwork solution inherits the security properties of
VPN Inter-AS Option C. In particular, with the SRv6 to MPLS service
route re-advertisement, the SID value in the received Prefix SID
attribute or a mapped IPv4 address is re-advertised into the MPLS
domain. Note that this is not the case in the other direction.
On the other hand, while with Option C the PEs may exchange service
routes directly via inter-AS Route Reflectors, with Option BC the
service routes go through interwork nodes where rich policy control
may be applied.
4. IANA Considerations
This document requests the IANA to register the End.DBS behavior in
the "SRv6 Endpoint Behaviors" registry.
5. References
5.1. Normative 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>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
Zhang, et al. Expires 15 March 2024 [Page 7]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
[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>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[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>.
5.2. Informative References
[I-D.agrawal-spring-srv6-mpls-interworking]
Agrawal, S., Ali, Z., Filsfils, C., Voyer, D., Dawra, G.,
Li, Z., Hegde, S., and S. R. Sangli, "SRv6 and MPLS
interworking", Work in Progress, Internet-Draft, draft-
agrawal-spring-srv6-mpls-interworking-12, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-agrawal-
spring-srv6-mpls-interworking-12>.
[I-D.bonica-spring-srv6-end-dtm]
Hegde, S., Kaneriya, P., Bonica, R., Peng, S., Mirsky, G.,
Zhang, Z., Decraene, B., Voyer, D., and S. Agrawal, "SR-
MPLS / SRv6 Transport Interworking", Work in Progress,
Internet-Draft, draft-bonica-spring-srv6-end-dtm-10, 9
July 2023, <https://datatracker.ietf.org/doc/html/draft-
bonica-spring-srv6-end-dtm-10>.
[I-D.zzhang-bess-vpn-option-bc]
Zhang, Z. J., Kompella, K., Decraene, B., and L. Jalil,
"VPN Inter-AS Option BC", Work in Progress, Internet-
Draft, draft-zzhang-bess-vpn-option-bc-00, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-zzhang-bess-
vpn-option-bc-00>.
Zhang, et al. Expires 15 March 2024 [Page 8]
Internet-Draft MPLS/SRv6 Service Interwork September 2023
Contributors
Shraddha Hegde
Juniper Networks
Email: shraddha@juniper.net
Krzysztof Szarkowicz
Juniper Networks
Email: kszarkowicz@juniper.net
Authors' Addresses
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Shay Zadok
Broadcom
Email: shay.zadok@broadcom.com
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Zhang, et al. Expires 15 March 2024 [Page 9]
