Internet DRAFT - draft-xie-spring-srv6-multicast
draft-xie-spring-srv6-multicast
Network Working Group J. Xie
Internet-Draft X. Geng
Intended status: Standards Track Huawei Technologies
Expires: 10 September 2023 9 March 2023
SRv6 Multicast: Approaches and Impacts to SRv6 Architecture
draft-xie-spring-srv6-multicast-00
Abstract
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.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 10 September 2023.
Xie & Geng Expires 10 September 2023 [Page 1]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3
3. Overview of the two SRv6 Multicast Solution Approaches . . . 3
3.1. SRv6-P2MP . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. MSR6-BE . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Impacts and Consequences to SRv6 architecture . . . . . . . . 7
4.1. Stateless Principle in SRv6-Multicast . . . . . . . . . . 7
4.2. VPN SID in SRv6-Multicast . . . . . . . . . . . . . . . . 8
4.3. SRv6 OAM in SRv6-Multicast . . . . . . . . . . . . . . . 9
4.4. Deployment in SRv6 Domain with Hosts . . . . . . . . . . 9
4.5. Path Steering between SRv6-Multicast Nodes . . . . . . . 10
4.6. Encapsulation Cost . . . . . . . . . . . . . . . . . . . 10
4.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
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
Xie & Geng Expires 10 September 2023 [Page 2]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
Stateful approach [I-D.ietf-spring-sr-replication-segment].
Stateless approach [I-D.lx-msr6-rgb-segment].
2. Terms and Abbreviations
The following abbreviations are used in this document.
* SRv6: Segment Routing over IPv6 data plane as described in
[RFC8986] etc.
* SRv6-P2MP: The aforementioned stateful approach of SRv6 Multicast.
* MSR6-BE: The aforementioned stateless approach of SRv6 Multicast.
3. Overview of the two SRv6 Multicast Solution Approaches
The following sections introduce the technologies analyzed in this
document and describe some of their most important characteristics.
3.1. SRv6-P2MP
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
Xie & Geng Expires 10 September 2023 [Page 3]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
Xie & Geng Expires 10 September 2023 [Page 4]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
+-------------+ +--------------+
|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.
3.2. MSR6-BE
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.
Xie & Geng Expires 10 September 2023 [Page 5]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
Xie & Geng Expires 10 September 2023 [Page 6]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
+-------------+ +--------------+
|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.
4. Impacts and Consequences to SRv6 architecture
4.1. Stateless Principle in SRv6-Multicast
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
Xie & Geng Expires 10 September 2023 [Page 7]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
4.2. VPN SID in SRv6-Multicast
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.
Xie & Geng Expires 10 September 2023 [Page 8]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
[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.
4.3. SRv6 OAM in 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).
4.4. Deployment in SRv6 Domain with Hosts
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.
Xie & Geng Expires 10 September 2023 [Page 9]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
4.5. Path Steering between SRv6-Multicast Nodes
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.
4.6. Encapsulation Cost
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.
Xie & Geng Expires 10 September 2023 [Page 10]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
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.
4.7. Security
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.
Xie & Geng Expires 10 September 2023 [Page 11]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
* A Hop Limit value (for example, value 10) is configured as a
threshold for SRv6-multicast encapsulated customer multicast
packet only. When an SRv6 multicast node receives a packet, it
checks the upper-layer header and recongnizes the packet being a
customer multicast packet, it then drop the packet when Hop Limit
value is less or equal to the threshold, to avoid the "IPv6 node"
along the path to the downstream SRv6-multicast node to generate
an ICMPv6 error message and sent back. This is similar to the
GTSM mechanism [RFC5082] but need to be deployed on SRv6-multicast
nodes only.
* A policy is configured to enable the traceroute of the SRv6
multicast data plane. When an SRv6 multicast node receives a
packet, it checks the upper-layer header and recongnizes the
packet being a traceroute packet, it then does not apply the Hop
Limit threshold to this kind of traceroute packet. When this
policy is not enabled, the traceroute of the SRv6 multicast data
plane may not work propely due to the applying of the above one.
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.
5. Security Considerations
TBD.
6. IANA Considerations
N/A
7. Acknowledgements
TBD.
8. References
Xie & Geng Expires 10 September 2023 [Page 12]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
8.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>.
8.2. Informative References
[I-D.ietf-spring-sr-replication-segment]
Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
J. Zhang, "SR Replication Segment for Multi-point Service
Delivery", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-replication-segment-13, 2 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-replication-segment-13>.
[I-D.lx-msr6-rgb-segment]
Liu, Y., Xie, J., Geng, X., and M. Chen, "RGB (Replication
through Global Bitstring) Segment for Multicast Source
Routing over IPv6", Work in Progress, Internet-Draft,
draft-lx-msr6-rgb-segment-03, 10 July 2022,
<https://datatracker.ietf.org/doc/html/draft-lx-msr6-rgb-
segment-03>.
[I-D.mcbride-mboned-lessons-learned]
Farinacci, D., Giuliano, L., McBride, M., and N. Warnke,
"Multicast Lessons Learned from Decades of Deployment
Experience", Work in Progress, Internet-Draft, draft-
mcbride-mboned-lessons-learned-02, 22 February 2023,
<https://datatracker.ietf.org/doc/html/draft-mcbride-
mboned-lessons-learned-02>.
[I-D.xl-bess-source-segment]
Xie, J., Geng, X., Liu, Y., and M. Chen, "Source Segment
for SRv6 based Multicast VPN", Work in Progress, Internet-
Draft, draft-xl-bess-source-segment-00, 7 March 2023,
<https://datatracker.ietf.org/doc/html/draft-xl-bess-
source-segment-00>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
Xie & Geng Expires 10 September 2023 [Page 13]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
[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>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<https://www.rfc-editor.org/info/rfc5082>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
[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>.
Xie & Geng Expires 10 September 2023 [Page 14]
Internet-Draft SRv6 Multicast: Approaches and Impacts March 2023
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[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>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9259] Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
Chen, "Operations, Administration, and Maintenance (OAM)
in Segment Routing over IPv6 (SRv6)", RFC 9259,
DOI 10.17487/RFC9259, June 2022,
<https://www.rfc-editor.org/info/rfc9259>.
Authors' Addresses
Jingrong Xie
Huawei Technologies
Email: xiejingrong@huawei.com
Xuesong Geng
Huawei Technologies
Email: gengxuesong@huawei.com
Xie & Geng Expires 10 September 2023 [Page 15]
