| Internet-Draft | SRv6 Multicast: Approaches and Impacts | March 2023 |
| Xie & Geng | Expires 10 September 2023 | [Page] |
Multicast was not originally supported with SR, as indicated in [RFC8402]: Segment Routing is defined for unicast.¶
However, with the wide development and deployment of SR and SRv6 technology, there have been proposals to develop SR-based multicast solutions, showing the interests to develop multicast solutions that facilitate incremental deployment based on SR and SRv6.¶
This document examines two typical SRv6 multicast approaches and considers a number of different aspects to provide a framework for understanding. The purpose is to help the working group and IETF community to understand and thus evaluate these possible impacts.¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 10 September 2023.¶
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.¶
As observed in [I-D.mcbride-mboned-lessons-learned], multicast was not originally supported with MPLS and that is a lesson learned in and of itself. The same lesson seems to be learned once again in SR more recently as the [RFC8402] indicates: Segment Routing is defined for unicast.¶
However, with the wide development and deployment of SR technology, there have been proposals to develop SR-based multicast solutions, showing the interests to develop multicast solutions that facilitate incremental deployment based on SR. The lesson we learned seemes to be that, multicast should be simple by adapting appropriately as much as possible to the unicast technology a network has built on.¶
Particularly note, SR is applicable to both MPLS and IPv6 data planes, named SR-MPLS and SRv6 seprately. SR-MPLS does not introduce any new behavior or any change in the way the MPLS data plane works. SRv6, however, does introduce new behaviors defined for FIB Entry and appropriate IPv6 extention headers. It had led to a new paradigm of SRv6 architecture named SRv6 Network Programming (SRv6-NP) [RFC8986] and a suit of SRv6-specific standards like SRv6-VPN [RFC9252], SRv6-OAM [RFC9259], which are quite different from the MPLS data plane and SR-MPLS source routing concept in [RFC8402].¶
With these observations, this document focus on SRv6 based multicast solutions. It provides a framework for understanding the impacts and possible consequences more or less related to the SRv6 architecture by reviewing the following two typical SRv6 multicast solution approaches raised in IETF.¶
The following abbreviations are used in this document.¶
The following sections introduce the technologies analyzed in this document and describe some of their most important characteristics.¶
SRv6-P2MP defines an SRv6 SID "End.Replicate".¶
The behavior associated with this type of SRv6 SID is named End.Replicate, and is provided with pseudo code like [RFC8986]. The basic behavior is this: When an IPv6 packet is received from an upstream SRv6 node with the destination address (active SID) being the End.Replicate SID, the SRv6 node replicate the packet and send each copy of the packet to a downstream SRv6 node according to the "State" that has already built and associated with the End.Replicate SID.¶
This kind of behavior, replicating a unicast packet and sending each packet to a downstream node, is different from what has been supported in MPLS and PIM, and need a new forwarding procedure to be implemented (especially in hardware) based on SRv6. Such kind of forwarding through a local state that is already built and associated with End.Replicate SID is considered to be practical.¶
When the copy of the packet is sent to the downstream SRv6 node, the destination address is changed to the End.Replicate SID of the downstream SRv6 node. This action include a behavior that "change the DA en route" but without a routing header.¶
To overcome the problem of "state explosion", SRv6-P2MP follows the the principle defined in MVPN [RFC6513] to allow multiple MVPN instances to use a single P2MP Path by populating and sticking the End.Replicate SID of SRv6 nodes along the P2MP Path. Each MVPN instance has an SRv6 VPN SID in the packet and SRv6-P2MP designs to use SRH to carry the SRv6 VPN SID in multicast.¶
SRv6-P2MP is motivated to be an SRv6 multicast solution, where the deployment of the solution is intended to be an SRv6 network or SRv6 domain. The End.Replicate SID is an IPv6 address allocated from SRv6 Locator and thus re-use the operation mode of an SRv6 network. The security mechanism depends on the SRv6 domain and thus re-use the security mode of an SRv6 network.¶
The following diagram shows the whole progression of a customer multicast packet through an SRv6 network using SRv6-P2MP.¶
+-------------+ +--------------+
|S=PE1.Lopback| |S=PE1.Lopback |
|D=P2.End.Rep | |D=PE2.End.Rep |
+-------------+ +--------------+
|SRH[VPN SID] | |SRH[VPN SID] |
+==========+ +=============+ +==============+ +==========+
|(C-MC Pkt)| >> | (C-MC Pkt) | >> | (C-MC Pkt) | >> |(C-MC Pkt)|
+==========+ +=============+ +==============+ +==========+
CE1-----------PE1------[P1]------P2----------------PE2------------CE2
/
/
/ +--------------+
| |S=PE1.Lopback |
| |D=PE3.End.Rep |
| +--------------+
| |SRH[VPN SID] |
\ +==============+ +==========+
\ >> | (C-MC Pkt) | >> |(C-MC Pkt)|
\ +==============+ +==========+
+------[P3]-------PE3------------CE3
S=PE1.Lopback: Loopback address of PE1 node.
D=PE2.End.Rep: Destination address in IPv6 header.
SRH[VPN SID]: VPN SID in IPv6 Segment Routing Header.
(C-MC Pkt): Customer MultiCast packet.
¶
MSR6-BE defines an SRv6 SID "End.RGB".¶
The behavior associated with this type of SRv6 SID is named End.RGB, and is provided with pseudo code like [RFC8986]. The basic behavior is this: When an IPv6 packet is received from an upstream SRv6 node with the destination address (active SID) being the End.RGB SID, the SRv6 node replicate the packet and send each copy of the packet to a downstream SRv6 node according to the "BitString" that is carried in an IPv6 destination options header.¶
This kind of behavior, replicating a unicast packet and sending each packet to a downstream node, is different from what has been supported in MPLS and PIM, and need a new forwarding procedure to be implemented (especially in hardware) based on SRv6 and IPv6 extension header. Such kind of forwarding through parsing the BitString is already defined in IETF [RFC8279] and [RFC8296], and has proven to be practical by multiple implemenations.¶
When the copy of the packet is sent to the downstream SRv6 node, the destination address is changed to the End.RGB SID of the downstream SRv6 node. This action include a behavior that "change the DA en route" but without a routing header.¶
To overcome the problem of "state explosion", MSR6-BE follows the the principle defined in BIER-MVPN [RFC8556] to allow multiple MVPN instances to use a single BitString forwarding paradigm. Each MVPN instance has an SRv6 VPN SID in the packet and MSR6-BE designs to use the source address of an IPv6 header to carry the SRv6 VPN SID in multicast.¶
MSR6-BE is motivated to be an SRv6 multicast solution, where the deployment of the solution is intended to be an SRv6 network or SRv6 domain. The End.RGB SID is an IPv6 address allocated from SRv6 Locator and thus re-use the operation mode of an SRv6 network. The security mechanism depends on the SRv6 domain and thus re-use the security mode of an SRv6 network.¶
The following diagram shows the whole progression of a customer multicast packet through an SRv6 network using MSR6-BE.¶
+-------------+ +--------------+
|S=PE1.Src.DT | |S=PE1.Src.DT |
|D=P2.End.RGB | |D=PE2.End.RGB |
+-------------+ +--------------+
|[BitStr=0110]| |[BitStr=0010] |
+==========+ +=============+ +==============+ +==========+
|(C-MC Pkt)| >> | (C-MC Pkt) | >> | (C-MC Pkt) | >> |(C-MC Pkt)|
+==========+ +=============+ +==============+ +==========+
CE1-----------PE1------[P1]------P2----------------PE2------------CE2
(BFIR) /(BFR) (BFER, BFR-id=2)
/
/ +--------------+
| |S=PE1.Src.DT |
| |D=PE3.End.RGB |
| +--------------+
| |[BitStr=0100] |
\ +==============+ +==========+
\ >> | (C-MC Pkt) | >> |(C-MC Pkt)|
\ +==============+ +==========+
+------[P3]-------PE3------------CE3
(BFER, BFR-id=3)
S=PE1.Src.DT: Source address in IPv6 header as Upstream-assigned VPN SID.
D=PE2.End.RGB: Destination address in IPv6 header.
[BitStr=0110]: BitString value in IPv6 Destination Options Header.
(C-MC Pkt): Customer MultiCast packet.
¶
As the Segment Routing(SR) [RFC8402] states that: SR supports per-flow explicit routing while maintaining per-flow state only at the ingress nodes to the SR domain. Stateless principle is a solid impression to understand the advantage of Segment Routing and therefore it is accepted as the evolution of traditional MPLS. The "stateless" characteristic is often understood as not need to maintain per-flow state on nodes other than edge nodes of a network domain. Traditional MPLS technology like LSP or P2MP LSP that are explicitly built through hop-by-hop signaling, as a contrast, is often recorgnized as "stateful", especially when they are used for per-flow unicast or multicast delivery.¶
The "stateful" technologies are widely recorgnized as not scaling well. In MVPN [RFC6513], the "aggregation" of carrying multiple multicast flows in a single P2MP tunnel is defined. There are two levels of aggregation: carry multiple flows of a VPN, and carry multiple flows of multiple VPNs, in an aggregated P2MP tunnel. Stateful approach like mLDP in MVPN may tend to use the first level of aggregation but still keep it compatible to the second level. Stateless approach like BIER in MVPN [RFC8556] tend to use the second level as base.¶
Because of this stateless principle implied in SR, and the practice in MVPN architecture toward a scaling capability, the SRv6-P2MP solution considers the "aggregation" capability in its design to avoid "state explosion" when scaling.¶
MSR6-BE, on the other hand, was determined to reuse the IETF work of stateless multicast solution and combine it with SRv6 technology.¶
It may be useful to bring the following as background to understand why MSR6-BE had not gain amount of attention by spring. Early in the explorating of MSR6-BE, both BIER and SRv6 technology are not mature, and it may be considered to be more of BIER and less of SRv6. However after the BIER had become an IETF standard and BIER WG decided not to work on a solution to combine BIER and SRv6, it seems to be a work that need to be discussed priorly in SRv6 view.¶
As mentioned above, "aggregation" of multicast services of multiple VPNs is architecturely needed not only in SR but also in MVPN. Technically, in order to support the "aggregation" between multiple MVPN instances, an VPN identifier is needed to identify the VPN a packet belongs to.¶
Under MPLS data plane, upstream-assigned MPLS Label is widely adopted as the VPN identifier in a packet when encapsulating the packet with a P2MP tunnel [RFC6513]. This is different than unicast because multicast has multiple egress routers and therefore there is no single "downstream-assigned" MPLS label to be valid on multiple egress routers.¶
Under SRv6 data plane, however, there is no easy way to inherit the MPLS concept and get an "Upstream-assigned SRv6 SID". In fact, even in unicast, SRv6 VPN SID [RFC9252] is very different than SR-MPLS VPN SID.¶
For multicast, no matter the End.Replicate or the End.RGB SID, the destination address in a packet is changed en route until it reach multiple egress SRv6 nodes. Because of these multiple egress SRv6 nodes have different SRv6 Locator, so there is no way to encode a single SRv6 VPN SID to be an active SID of multiple SRv6 nodes simultaneously.¶
[I-D.xl-bess-source-segment] provide a way to use source address in IPv6 header to distinguish an MVPN instance, and different source address will be used for different MVPN instance. Further, the source address used in IPv6 header is allocated from SRv6 locator as an SRv6 SID, and the behavior of such an IPv6 address to be an active SID is also defined. The concept is very similar to the "Upstream-assigned SRv6 SID" and may provide an alternative for further discussion about SRv6 multicast.¶
As indicated in [RFC8986], SRv6 smoothly inherits the Upper-layer processing of IPv6. It also inherits the standard IPv6 ICMPv6 protocol as its Ping/Trace tool in [RFC9259]. However, the ICMPv6 protocol may no longer be available for the detecting of data-plane failures in SRv6 multicast solutions, because the DA is changing en route in SRv6 multicast and therefore ICMPv6 checksum is no longer valid when a packet is received in the Leaf of a P2MP tree.¶
A possible way to solve the problem, the SRv6 multicast may need to re-consider the OAM paradigm that have widely used in MPLS era, see [RFC8029]. That is to say, it may need to limit its usage as a "P2MP tunnel" or "IPv6 encapsulation" technology, and built the OAM tool based on the tunnel. For example, the Echo request in Ping/Trace may be like this: (SRv6-Multicast tunnel encapsulation)(IPv6 header with destination address ::FFFF:127.0.0.1)(UDP)(Echo Request Msg Body).¶
The SR architecture, especially SRv6, tends to extends its capability from routers inside a network to hosts that is managered together with the network. [RFC8754] gives many examples of deployment of SRv6 in a domain with hosts working as SRv6 nodes.¶
Through the discussion in the Spring list, the SRv6-P2MP proposal does want to be effective in the case of such an SRv6 domain with hosts.¶
The MSR6-BE proposal also considers to be effective in the case of such an SRv6 domain with hosts.¶
However, the first challenge is that, UDP checksum is mandatory for IPv6 [RFC8200] and it has been the default behavior for usual Operaton-System (OS) available, but the checksum will be invalid in SRv6 multicast solutions, no matter SRv6-P2MP or MSR6-BE, because of the "DA change en route" behavior they both have. That means that, an application may need to use IPv6 UDP datagrams with Zero UDP checksum per the [RFC6936].¶
Second thing is about OAM tool on hosts. As described in previous section, the ICMPv6 protocol in the Ping/Trace tool of a host is no longer available because of the "DA change en route" behavior, and thus the hosts may need to development new tools to support the "SRv6 domain with Hosts" scenario.¶
As [RFC8402] implies, the art of SR is stateless Path Steering. In SRv6-Multicast, it is also considered to use Stateless Path Steering between upstream and downstream nodes.¶
In MSR6-BE proposal, the main extension to IPv6 is the BIER option defined in Destination Options Header (DOH). When the Path steering between upstream and downstream nodes is desired, the SRH containing the SID list could be inserted before the DOH.¶
In SRv6-P2MP proposal, however, insertion of an the SRH containing the SID list may cause 2 SRHs in an IPv6 packet because the VPN SID is designed to be carried in an SRH already. This will break the restriction of [RFC8200], and thus an encapsulation method like H.Encaps or H.Encaps.Red have to be used when an VPN SID is already carried. But when an VPN SID is not carried in an SRH of a packet, the insertion of SRH is possible as it will not cause a packet with 2 SRHs.¶
One may argue that, in the above situation of SRv6-P2MP, a new IPv6 header and SRH encapsulating could always be used to the received packet instead of insertion of a new SRH. However, this will make the burden of encapsulation cost higher beyond that is normally accepted in multicast solution. The document also hints that "Head node MAY optimize below encap and the encap of packet in a single encap" and shows that the encapsulation cost is a practical consideration.¶
Encapsulation cost is also considered in MSR6-BE. When a penultimate node receives an MSR6-BE packet (a packet with IPv6 header and BIER option contained in DOH), it can use the "PSP" mechanism [RFC8986] to delete the DOH before it sends each copy of the packet to its downstream node (the ultimate node). With this PSP mechanism applying to DOH, the encapsulation cost is reduced.¶
It may also be useful to understand that, the SRv6 is more solid a base of MSR6-BE than BIER, because the IPv6 header with SRv6 SIDs in both destination address and source address is still in a packet while the DOH carrying the BIER option is no longer in the packet when traveling by applying the aforementioned PSP.¶
In a case when multicast feature is enabled and deployed only on edge nodes but not on any intermediate nodes, both the MSR6-BE and SRv6-P2MP will become an SRv6-based Ingress-Replication. MSR6-BE will be less costly in encapsulation because it still uses IPv6 header but do not need IPv6 extension header (thus BitString) by applying the aforementioned PSP, while SRv6-P2MP will need an extra SRH to carry the VPN identifier.¶
When a packet is replicated and sent by the SRv6 multicast node to multiple downstream nodes (for example, 100 downstream nodes), and all the downstream nodes found that the Hop Limit of the packet is 1, these nodes may send an ICMPv6 error messages back to the originator of the SRv6 multicast packet simultaneously. This is a potential security risk that SRv6 multicast may cause and it is very different from SRv6 unicast. Such kind of difference between multicast and unicast had been considered when the IP Multicast was designed early in the [RFC1112]: "An ICMP error message (Destination Unreachable, Time Exceeded, Parameter Problem, Source Quench, or Redirect) is never generated in response to a datagram destined to an IP host group."¶
It is expected that such situation can be avoided in SRv6 multicast, but the necessary change is better to happen only on "SRv6 multicast nodes" and normal "IPv6 nodes" do not need to change either in hardware or in software.¶
On the other hand, the Ping/Trace tool as described above may want to be useful in the network. This may require that, the SRv6-multicast node can differentiate the two cases by checking the upper-layer header when encountering the Hop Limit threshold.¶
For example, the following policy may be considered on every SRv6 multicast node.¶
As a further review, to apply the ping tool to detect the data plane failure in SRv6-P2MP, an Ingress node who initializes the ping request may have to expect all the egress nodes to response. In a case when the number of egress nodes is large, the simultaneous responses from numerous egress nodes may impact the Ingress node greatly and become a security concern.¶
On the other hand, to apply the ping or trace tool to detect the data plane failure in MSR6-BE, an Ingress node who initializes the ping/trace request can specify a portion of the egress nodes, and thus may relieve the impact and the security concern.¶
TBD.¶
N/A¶
TBD.¶